please decrypt your manuals

[Keisial]

Doru Georgescu wrote:
>> 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."



> 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).



>> AFAIK the files are used only by the server. The client
>> will receive
>> that public key from the handshake.
>> 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.

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

- C present a password / signs another token with public key to
authenticate with the server.

A third party wouldn't be able to inject in the ciphered S->C stream.
And the server does provide its public for authentication. You may see
it more easily in HTTPS terms, which is based on the same protocol
ideas, where the server provides a certificate (which in that case
contain the domain name) and that certificate is also signed by a
trusted authority. In this case there's no trusted CA, the user performs
the validation by itself checking that the fingerprint matches the
expected one.


>> There's no authentication on who holds the "client" end of
>> the tunnel,
>> that's why the first step after establishing the tunnel is
>> to ask the
>> user username + password or using a username + public key
>> authentication
>> (user public key usually stored in ~/.ssh/authorized_keys,
>> see
>> AuthorizedKeysFile of sshd_config).
>>     
> The client is authenticated to the server, it either supplies a password, or it has a special authentication key, whose public part is memorized in //server/~/.ssh/authorized_keys. Maybe it uses this algorithm: http://en.wikipedia.org/wiki/Rsa#Signing_messages. 
>   
Yes, that's more or less right. RSA is one of the algorithms it can use
for the public keys.

> However, again, the server is not authenticated to the client. 
>
> Doru 
>   

It is. It proves that it is the server which you wanted to connect to.