I am not sure that this is apropos for this conversation, but another
scenario that I run into is the fact that I run ssh on my
gateway/router/firewall machine and also port forwarding ssh to intranet
machines. So depending on the port I use, I ssh into different boxes
behind the firewall. SSH seems to give me a warning since it always appears
that I am ssh'ing into the same machine but it has different public keys
(different intranet machines) depending on the port.
Kenn Herman
----- Original Message -----
From: Niels M�ller <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, August 26, 1999 8:12 AM
Subject: Making host authentication more convenient
> During the CCC meeting, I talked a lot with some of the kth-krb
> people. Of course, we spent some time debating the superiority of
> kerberos vs ssh. And it seems quite clear that the biggest Problem
> with ssh, as it is used today, is the lousy host authentication. That
> is, the "Unknown host key, continue anyway?" question that one answers
> yes to all too often. More precisely, a common scenario is as
> follows:
>
> I have some home-system where I keep most of the files and stuff I
> need. I visit some place with net-connectivity and ssh installed (the
> guest-system). I have not had any previous contact with the
> guest-system, but I have some level of trust in its security (it may
> be operated by a friend, conference organizer, whatever). I want to
> use this system to securely log in to my home system.
>
> With Kerberos, I'm told, I would run the kauth program, type my
> password, and get a (time-limited) ticket that provides _mutual_
> authentication between me and my home system.
>
> With typical ssh usage, I just connect, store the hostkey the first
> time, and have no real protection at all against MITM attacks. Which
> is not really acceptable.
>
> One simple and reasonably practical solution is the use of
> fingerprints: I make a hard-copy of the fingerprint of my home system
> and keep in my wallet. And I make sure to verify the fingerprint of
> the received hostkey before I trust it. Note that I really need only
> one fingerprint; once I have the authentic hostkey of my home system, I
> can download my known_hosts file from there, or use some kind of
> certificates. This would work, and I'll implement support for it in lsh
> some day, but it still seems a little low-tech and cumbersome.
>
> It would be convenient to be able to use a short password to
> authenticate the home system (which one of the things kauth provides).
> So how to do that? There are several possibilities.
>
> One is to simply use kauth to get a ticket, and somehow use it for
> _mutual_ authentication during ssh keyexchange. If you are already
> running kerberos, I guess this is what you would want to do. For
> someone not running kerberos (e.g. me), it seems inconvenient to
> kerberize the home system just to use ssh from guest-systems, in
> particular as that would require sysadm work.
>
> And I also think kerberos is overkill when you want to authenticate
> one single message (in this case, a public hostkey).
>
> Another option is to provide a mechanism to download a hostkey from a
> system, authenticating it using a small shared secret (i.e. a
> password). You probably can't use your ordinary unix password, as I
> suspect that all such protocols would require the server to know the
> cleartext password.
>
> Or one could integrate that mechanism into the ssh-protocol, as a
> separate key-exchange algorithm, that you would use when you don't
> have the remote system's hostkey in the known_hosts file.
>
> I have to think more about this, but I'd appreciate some feedback. Are
> these approaches reasonable, and is any one of them preferable over
> the others? Do you know of any existing protocols that could be used
> to solve the problem?
>
> /Niels
>
