[svlug] Configuring Server - SSH Trouble + Security Considerations

Seth David Schoen schoen at loyalty.org
Thu Oct 26 12:04:35 PDT 2006


Don Marti writes:

> Yes, tricky problem.  Requiring a key prevents
> the simplest form of the problem of using the same
> password on two systems, but you can't keep a user
> from putting the same key on two systems.
> 
> Is there a way for you, the administrator of the
> server, to tell ssh hopping, like this:
> 
>   ssh -At lron.example.edu ssh xenu.linuxmafia.com
> 
> from risky private key copying?

It might be possible to use trusted computing to this end (although I'm
not completely sure exactly what "this end" is).

An interesting alternative would be to redesign the ssh protocol so that
authentication public keys inherently name a particular host to which
they're meant to be used to authenticate (so that the key that
authenticates you to foo.net is inherently, irrevocably different from
the key that authenticates you to bar.net).  However, I can't think of a
noninteractive cryptographic protocol that achieves this result in a way
that the user can't circumvent (by using information from the foo.net
key to derive the bar.net key automatically).

Perhaps you could say that the hash of the public key has to have a partial
collision with the hash of the hostname.  In that case you have to spend
a certain amount of time generating and then discarding keys until you
find one that is appropriate to use to authenticate to that host.  For
example, if I wanted to authenticate to foo.net I might have to run

echo -n foo.net | sha1sum | cut -c1-3

and not that the output is "bc9"; then it could be a rule that foo.net
would only accept the subset of ssh public keys that also yield "bc9"
when you run them through sha1sum | cut -c1-3.  (It takes a relatively
long time to generate such a key, however.)

schoen at sescenties:~$ time ssh-keygen -f blah -t dsa; cat blah.pub | sha1sum | cut -c1-3
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in blah.
Your public key has been saved in blah.pub.
The key fingerprint is:
2d:d0:a0:dd:4f:04:03:92:66:4d:84:22:bd:76:d1:73 schoen at sescenties

real    0m3.864s
user    0m2.749s
sys     0m0.007s
ebc
schoen at sescenties:~$ 

Actually, the fact that there is already a standard key fingerprint
mechanism means that the use of sha1sum here is probably redundant.  In
the example, it took 2.75 seconds to generate a key with the partial
hash "ebc", which ex hypothesi would not be allowed by the host
"foo.net".  It turns out that it would be allowed by the hosts
"emilia.net", "eumenides.net", "franco.net", "it.net", among others,
though.

If it takes 2.75 seconds to generate one of these, then it would take
an average of over three hours to generate a suitable one for a given
host.  However, it would be relatively unlikely that users who used only
a few hosts would end up reusing keys.  (The birthday paradox suggests
that they might eventually have a good chance of finding two hosts that
would _accept_ the same key, but that doesn't mean that they would
notice or choose to _use_ the same key with that particular pair of
hosts.)

Perhaps there is a more elegant cryptographic solution.

P.S.  There is a flaw in my current implementation, which is that I hash
the entirety of blah.pub (including the user-controlled comment string
at the end) instead of just the key itself.  This is easy to fix if you
just arrange to calculate the hash only over the part that represents
the actual key.

-- 
Seth David Schoen <schoen at loyalty.org> | This is a new focus for the security
     http://www.loyalty.org/~schoen/   | community. The actual user of the PC
     http://vitanuova.loyalty.org/     | [...] is the enemy.
                                       |          -- David Aucsmith, IDF 1999




More information about the svlug mailing list