Re: [Otpasswd-talk] Using OTP to kind of fix MITM.

[Hannes Beinert]

On Tue, Dec 22, 2009 at 11:01, Tomasz bla Fortuna <address@hidden> wrote:
> Dnia Tue, 22 Dec 2009 10:31:54 -0600 Hannes Beinert <address@hidden> 
> napisał(a):
>
>> Would decreasing the font size work?
>
> In LaTeX - yes. But still the 'main' passcard printing method is just
> an ASCII output which just counts characters. (In fact this text-only
> output is used by LaTeX and only wrapped in something more).

Yeah, I take your point.  You know, it might not be a bad idea to
print one additional "passcard page" for every set of passcards which
displays the hostname, randomart and SSH host keys.  I think that
properly authenticating the host is too important, and it's worthwhile
making it as easy as possible for the user.  And it does seem awfully
cumbersome to squeeze it into the existing passcard page.

>> > We can put whole fingerprint at the end of each passcard; still I've
>> > got no idea how to retrieve it from ssh in a program. This
>> > fingerprint can also be send via OOB.
>>
>> I really like the idea of having the option of sending it via OOB.
>>
>> The two options for retrieving the host key(s) that I can think of are
>> to (1) directly access the keyfiles in /etc or /etc/ssh, or (2) to
>> establish an initial session with sshd, which would reveal at least
>> one of the keys.
>>
>> The problem with the first option is that one would have to be
>> somewhat aware of the conventions for the sshd configuration on the
>> host.  IOW, one would either have to know where the (hopefully)
>> world-readable host keys are stored, or one would need to know the
>> location of the sshd_config and parse it for the "hostkey" value, and
>> also understand what it defaults to.  This sounds really painful to
>> me.  In the case of the second option, the server would need to be
>> running at the time of the query -- presumably at the point where the
>> passcards are being printed -- and I'm unsure how many of the hostkeys
>> would be revealed by this.  I can research this, if you like.
>
> True. That's kind of pain. If we'd have to do it like this - checking
> key location, calling some program I'd create external sh script to
> the work (which can be distribution dependent) and call it to get the
> fingerprint... This can be also a pain taking into account that
> otpasswd will have to be SUID to work with global database. I'd like to
> implement this by 1.0, but for now there're still some things to do. ;)

I think there's a pattern developing, here, for a generalized plug-in
script facility.  :-)

I looked around on the web a little, and I couldn't find any other
methods for obtaining the SSH hostkeys than the two options above.  I
confess that I really don't like the idea of trying to
reverse-engineer the SSH server installation, and I just don't see a
clean way of finding the public hostkey files.  And, even if one does
find the location, I could envision some errant admin read-protecting
them.

OTOH, the idea of requiring the sshd to be active when we need the
hostkeys, and to require the daemon to listen on a loopback port is
also a bit annoying.  However, this does seem to be a somewhat
reasonable approach.  For OpenSSH, scanning the sshd would be as easy
as:

     $ ssh-keyscan -t rsa1,rsa,dsa "localhost $(hostname)" > temp
     $ ssh-keygen -l -f temp

For other servers, it would obviously be different, although
ssh-keyscan would work against other servers, too, and a version of
this tool could be included in the otpasswd distro to use as a backup
in the event ssh-keyscan isn't installed.

In fact, if otpasswd is changed to use LDAP, and if it is adapted to
be used on a different host than the one for which the passcodes/cards
are generated, then the idea of scanning the server becomes very
convenient, and ssh-keyscan would be very useful.

The question is what one should do if the server isn't running at the
time of passcard generation.  I think I would probably approach this
as follows:

     (1) Retrieve the hostkeys from a cache which is maintained
          from previous hostkey retrievals.  A timestamp would
          need to be kept on each key.

     (2) If the key is too old -- keeping in mind that hostkeys do
          not typically change often -- then ask the user if s/he
          wants to specify them on-the-fly.  Alternatively just
          provide commandline options for this.

     (3) Else, just don't generate an SSH hostkey passcard page
          and issue an information error that the server was down.

> This script could be generating whole back of passcard.

That's a good idea.

Hannes.