please decrypt your manuals

[Doru Georgescu]

> >> It's used by the client to maintain a list of
> trusted hosts
> >> keys. It's
> >> like ~/.ssh/known_hosts, but set by the
> administrator.
> >>     
> > Where is this specified in the manual. I respect your
> opinion, but this is not the subject of the post. The manual
> does not fully specify the files it refers, this is the
> subject of the post. 
> >   
> 
> "Host  keys  are stored  in
> ~/.ssh/known_hosts in the user's home
> directory.  Additionally, the file
> /etc/ssh/ssh_known_hosts is
> automatically checked for known hosts."

Yes, but is it on the server or on the client? You may remember that the subject of this thread is the location of the /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files referred under the SSH_KNOWN_HOSTS FILE FORMAT title in the sshd manual. I'm not sure that this location is specified in the sshd manual, directly or indirectly. 

> > Plus, are you sure that the server never uses
> /etc/ssh/ssh_known_hosts? It uses ~/.ssh/known_hosts,
> according to sshd_config manual. If I guessed rightly,
> because that manual also does not fully specify the files it
> refers. 
> >   
> 
> That only applies to ssh v1 RhostsRSAAuthentication. You
> shouldn't use
> that (but it's a good point, anyway).

You know this from the manuals? :-) 

> >> AFAIK the files are used only by the server. The
> client
> >> will receive
> >> that public key from the handshake.

You mean, client? Maybe the manual should say this. 

> >> You can regenerate them. Your users will get big
> warnings
> >> that someone
> >> may be trying to pose as your machine, so I
> recommend to
> >> properly
> >> publicise the change, or not to change them.
> >>     
> > So the client uses another key for the encryption of
> the messages it receives? 
> >   
> 
> They don't use the public key for message encryption. See
> below.
> 
> 
> 
> >> With ssh you open a secure tunnel between two
> ends.
> >> Anything passed
> >> through it is secure. You authenticate that the
> server is
> >> not a deceiver
> >> by checking that the provided key matches the one
> you have
> >> associated
> >> with that host, which you would have supposedly
> verified by
> >> some
> >> unspecified secure mean.
> >>     
> > This procedure ensures that only the server can
> decrypt messages from the client, but still the client can
> receive messages from anybody in the middle and it can not
> tell if they come from the server or from the
> man-in-the-middle. So the server is not authenticated to the
> client. It goes one way only, as you see, the server does
> not supply any password or authentication key. I guess this
> is less important, because the client only displays messages
> from the server, it does not run commands from the server. 
> 
> I'm not the most qualified one to explain this but... here
> I go. Anyone
> is welcome to fix me should I say something wrong.
> 
> - C connects to S
> - They perform a Diffie-Hellman key exchange, and establish
> a private
> communication using a ephimeral key and a symmetrical
> cipher.
> 
> From this point on, they know they are talking to someone
> other and the
> connection cannot be read, or modified in any way.

They may be talking with a man in the middle. 

> 
> - S signs a token with its private key, so that C can
> verify that it is
> really the server it wants to talk to.
> 

Maybe the S's host key is used for authentication of S in front of C. 

Indeed (ssh man): 

     /etc/ssh/ssh_host_key
     /etc/ssh/ssh_host_dsa_key
     /etc/ssh/ssh_host_rsa_key
             These three files contain the private parts of the host keys and are used
             for host-based authentication. 

So S is authenticated in front of C with a token, and this authentication is based on the human in front of C's console recognizing the hash (fingerprint) of the S's public host key. 

Thank you for your help. In case I got it right. 

Please support my proposal to have the ssh manuals fully specify the location of files they refer.