please decrypt your manuals

[Keisial]

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

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.




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


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


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

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