please decrypt your manuals

[Doru Georgescu]

> >>> I. most of ssh manual and all sshd manual
> present server and client
> >>> as one machine, called host. All files
> mentioned are placed on one
> >>> machine. This is incorrect, and makes the
> explanation unclear.
> >>>       
> >   
> >> I understand your point, but I don't think the
> documentation is
> >> incorrect. Every system is potentially both a
> server and a client,
> >> and there is only one set of manual pages.
> >>     
> > Please, help me understand what do you mean by "I
> understand your point", and "I don't think the documentation
> is incorrect". You mean, the manual shows good humour by
> explaining how to connect safely, using keys, from one
> computer to itself? I refer to man sshd, where the
> SSH_KNOWN_HOSTS FILE FORMAT section suggests to copy keys
> from /etc/ssh/ssh_host_key.pub into
> /etc/ssh/ssh_known_hosts, as if those files are on the same
> machine. 
> >
> >   
> >> Although I think wording in OpenSSH man pages is
> already pretty good,
> >> I'm sure that patches which improve wording even
> further will be most
> >> welcome.
> >>     
> > I timidly propose to specify, for each file, the
> machine on which it lives, this way:
> //client/etc/ssh/ssh_host_key.pub and
> //server/etc/ssh/ssh_known_hosts. The fact that ssh and sshd
> are always installed together, and files for both client and
> server are present on each machine, only increases the
> manual reader's confusion. 
> >   
> 
> a) Your proposed format only makes it more confusing.
> b) You copy /etc/ssh/ssh_host_key.pub from the server to
> /etc/ssh/ssh_known_hosts on the client (or
> ~/.ssh/known_hosts the ~
> character meaning your home directory).

You certainly are right, and I apologize for my mistake. I should have written: //server/etc/ssh/ssh_host_rsa_key.pub and //client/etc/ssh/ssh_known_hosts. Of course, one can say: /etc/ssh/ssh_host_rsa_key.pub on server and /etc/ssh/ssh_known_hosts on client. 

> 
> Not mentioning the place you would change, also makes it
> more difficult
> to review.
> I think you refer to the line that says "Bits, 
> exponent,  and  modulus 
> are  taken  directly  from  the 
> RSA  host  key;  they  can  be 
> obtained, for example, from
>    
>    /etc/ssh/ssh_host_key.pub."
> I think that could be expanded by adding "from the server
> machine",
> although the previous phrase already concretises it, since
> to add the
> RSA host key for host foo, you need to copy that file from
> machine foo.

Yes, every file mentioned in the sshd manual should be fully specified, that is, it should be always very clear if it lives on the server or on the client. 

The manual does not mention any machine foo. Maybe it tells you to copy that key from the server to the server, from the server to the client, from the client to the server, or from the client to the client. Or combinations of the above. Please show me clearly, step by step, how do you use the content of the sshd manual to conclude that /etc/ssh/ssh_host_key.pub is on the server. You can assume that I know about public-key cryptography from Wikipedia, and I know some Unix, but you can't assume that I know how did OpenSSH decide to protect itself against man-in-the-middle attacks before I read the manual. Also, I'm a user who only wants to use keys instead of passwords for authentication, for safety reasons, therefore I have no time to read RFC, code etc. Also, you may concede that the manual should be readable at 3 am, without requiring complicated logic over two RFC's and several manual pages only to find out on what machine is /etc/ssh/ssh_host_key.pub
 mentioned in the SSH_KNOWN_HOSTS FILE FORMAT paragraph of the sshd manual. 

> 
> 
> 
> 
> >>> both encrypt their messages with the
> encryption keys in: 
> >>> both can memorize known hosts' public
> encryption keys in
> >>> /etc/ssh/ssh_known_hosts and
> ~/.ssh/known_hosts 
> >>> only the server is protected through
> authentication.
> >>>       
> >   
> >> Check out the RFCs, then go back to the OpenSSH
> manual to learn more
> >> about how specifically OpenSSH maps SSH onto UNIX
> systems.
> >>     
> > Are you sure that those RFC's explain whether
> /etc/ssh/ssh_known_hosts is used by the client or by the
> server? I didn't find this name in those RFC's, but maybe I
> can deduce somehow what ssh_known_hosts is doing if I read
> them. 
> >   
> 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. 

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. 

> 
> 
> >>> Less important: 
> >>> I still don't know if the encryption keys can
> be regenerated,
> >>>       
> >   
> >> Which encryption keys? There can be many keys
> involved already in
> >> SSH, and further keys introduced by the OpenSSH
> implementation.
> >> Please have a look at the protocol description,
> and ask a more
> >> specific question.
> >>     
> > I was referring to the keys memorized in the
> /etc/ssh/ssh_host_dsa_key.pub and
> /etc/ssh/ssh_host_rsa_key.pub files. I suspect that they
> contain public keys used by both ssh client and server to
> encrypt their messages under protocol 2.
> >   
> 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? 

> 
> 
> >>> and I am not sure that every line sent from
> client to server is
> >>> authenticated, as it should.
> >>>       
> >   
> >> Again, have a look at the protocol, to learn more
> about the format of
> >> bytes between client and server. All data uses
> encryption and message
> >> authentication.
> >>     
> > But there is no way to authenticate messages from
> server to client! This should be in RFC, anyway.
> >   
> 
> 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. 

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

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

Doru