[sf-lug] passwordless ssh logon

Rick Moen rick at linuxmafia.com
Sat Dec 22 02:01:25 PST 2007

Quoting Alex Kleider (a_kleider at yahoo.com):

> It was my understanding that each side of a connection (i.e. in this
> case both the client _and_ the server) needs its own pair of pub/priv
> keys:

To do public-key-authenticated login from host "home" to host "remote", 
I just need (1) my private key (of a keypair) in "home's" ~/.ssh/identity 
file, and (2) my public key (of the same keypair) in "remote's" 
~/.ssh/authorized_keys file.[1]

My local ssh client on "home" knows to look in the former place, and 
the ssh daemon on "remote" knows to look in the latter.

As a user doing day-to-day SSH sessions between machines, that's the
only keypair you deal directly with.  Separately and aside from that,
the Internet hosts themselves have their own keypairs to identify the
machines themselves.  You'll see an indication of the two machines
attempting to autnenticate themselves the first time you connect to a
remote machine:  You'll be shown a hash (a kind of checksum) of the 
machine's public host key, basically to give you a chance to say "Er, 
that's not the hash I expected; it's an imposter machine", or to say
"Yeah, I'm feeling lucky; I'll accept that hash as genuine".  The latter
adds it to your ~/.ssh/known_hosts file.

 > the client sends it's public key to the server to use to encrypt
> server to client messages which can only be decrypted by the client's
> private key; and the server sends it's public key to the client to use
> to encrypt client to server messages which only the server can decrypt
> because only it has the relevant private key. Am I on the right track?

No.  Don't forget, the keypair is used only for _authentication_ of you
being the person you claim to be, during login.  The actual session of
data transmission gets conducted not using public keys at all, but
rather using regular symmetric crypto, such as 3DES or Blowfish.

[1] I'm cheating, here, for simplicity.  Those were the filenames used
for the SSH1 ciphers, which included RSA public keys.  When Tatu Ylonen 
created the SSH2 protocols, an (mostly) new family of protocols had to
be accomodated, including DSA public keys, which were somewhat
incompatible with the old ones and had to be stored in files with
different filenames, e.g., id_dsa and authorized_keys2.  I banished that
complication to a footnote to reduce confusion.  ;->

More information about the sf-lug mailing list