please decrypt your manuals

[Peter Stuge]

Doru Georgescu wrote:
> 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 very first line of my sshd(8) man page reads:

NAME
     sshd — OpenSSH SSH daemon

And after the list of flags there's:

DESCRIPTION
     sshd (OpenSSH Daemon) is the daemon program for ssh(1).

And in the next paragraph:

     sshd listens for connections from clients.


This must be clear enough indication that sshd is the server program.
So anything you read in the sshd man page must be in the context of
the server program. If you read "daemon" on the first line and you're
not yet sure of exactly what that means, then naturally the rest of
the documentation will be of limited use to you. If you do want to
learn about daemons and clients, then maybe allocate some time at an
opportunity which is not 3am, and study how the system works.

If you don't care about daemons and clients, then the sshd man page
is of no use.


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

The man page sshd(8) documents the server part of OpenSSH. In the
FILES section it is therefore clear that these files are relevant
only for the server. Under FILES, there's this paragraph which I
think is really clear:

--8<--
     /etc/ssh/ssh_host_key.pub
     /etc/ssh/ssh_host_dsa_key.pub
     /etc/ssh/ssh_host_rsa_key.pub
             These three files contain the public parts of the host keys.
             These files should be world-readable but writable only by root.
             Their contents should match the respective private parts.  These
             files are not really used for anything; they are provided for the
             convenience of the user so their contents can be copied to known
             hosts files.  These files are created using ssh-keygen(1).
-->8--

So the file is a *host* key. Further, the instructions on permissions
for these files is very strong indication that they are not intended
for users to write.


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

Remember that there are two concepts in this discussion. First of all
there's the SSH protocol, which is well documented in RFCs. Then
there is OpenSSH, an implementation of the protocol.

There are many security features already at the protocol level which
make SSH an excellent choice for any secure communication. There are
also some security features within OpenSSH that may or may not be
unique, compared to other SSH implementations. It is still not
completely clear to me which of the two entities you are talking
about. As I already wrote, the SSH protocol uses message
authentication for all communication.


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

I'm not sure you stated this very clearly, which could certainly be
reason for the kind of replies that you get. It's important to ask
the right thing. It can be difficult to do so, there are great essays
on the subject.

Anyway, if your role is as a user then you shouldn't start with the
sshd man page. Instead, start with the ssh man page. It explains what
files OpenSSH uses for public key authentication:

--8<--
     ~/.ssh/authorized_keys
             Lists the public keys (RSA/DSA) that can be used for logging in
             as this user.  The format of this file is described in the
             sshd(8) manual page.  This file is not highly sensitive, but the
             recommended permissions are read/write for the user, and not
             accessible by others.
..
     ~/.ssh/identity
     ~/.ssh/id_dsa
     ~/.ssh/id_rsa
             Contains the private key for authentication.  These files contain
             sensitive data and should be readable by the user but not acces‐
             sible by others (read/write/execute).  ssh will simply ignore a
             private key file if it is accessible by others.  It is possible
             to specify a passphrase when generating the key which will be
             used to encrypt the sensitive part of this file using 3DES.

     ~/.ssh/identity.pub
     ~/.ssh/id_dsa.pub
     ~/.ssh/id_rsa.pub
             Contains the public key for authentication.  These files are not
             sensitive and can (but need not) be readable by anyone.
-->8--


Now you know that you need to create an authorized_keys file. In
fact, the first paragraph, on authorized_keys, should maybe not be in
here at all since only the server looks at that file - but at least
it has the reference to the sshd man page so that people can go there
to get all the details on the file.

In the sshd man page it says that you should copy your public key and
into authorized_keys, and edit it to suit. Editing it is actually
optional.


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

If nothing else is mentioned, you must assume that this file belongs
to the server, since it's described in the sshd manual page. If this
kind of logic does not come very naturally to you then there isn't
much we can do to help. :\


> > Are you sure that those RFC's explain whether
> > /etc/ssh/ssh_known_hosts is used by the client or by the
> > server?

Not at all. This suggests that you are (again?) confusing the
protocol SSH with the implementation OpenSSH.

The documentation relating to these two things will not neccessarily
overlap very much, if at all. It's better for each entity to document
it's own scope accurately, than for everyone to try to document
everything.


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

You need to first read the OpenSSH manual page for ssh and then sshd
to learn what /etc/ssh/ssh_known_hosts is used for.


> The manual does not fully specify the files it refers,

Did you read all of the manual? It's really good to do so, but you
should find a better time than 3am, if you are usually tired by then.


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

Are you looking at the IgnoreUserKnownHosts directive? That also
explains circumstances when the file is used, giving you further
things to look up, and learn about.


> So the client uses another key for the encryption of the messages
> it receives?

As I wrote there are many keys involved in the SSH protocol. Now you
are discussing something completely unrelated to OpenSSH and manuals
in OpenSSH. I don't think it's too off-topic for the list, but please
remember to keep the distinction between the protocol and the
implementation.

Really, to get the details of the SSH protocol, you should look at
the RFCs. They are not too dense, and should be digestable in a day
or two if you want to read them from start to end.


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

This assumption is incorrect. Look at the protocol RFCs to learn all
about how SSH client and server authenticate each other.

In short, the client verifies the host key. Once the host key is
considered to be approved (by the user in case of OpenSSH) the client
will then continue to try to authenticate the user to the server.
Once authentication is complete, the message authentication protects
against any MITM attack.

MITM is easy if the TCP session can be rerouted, but it's not
possible to perform undetected MITM attack without access to the
server host key.


> The client is authenticated to the server,

No. The user authenticates to a server. The client is never
authenticated.


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

As you can see in both ssh and sshd man pages, as well as the RFC,
the key that can be used for public key authentication of a user can
be either RSA, DSA, or any local key type supported as a local
extension of the SSH protocol. (key type blabla at mydomain.com)


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

Yes, it is. The client receives the server's host key, and OpenSSH
let's the user decide if to go ahead with communication with this
host, or not.


Really, look at RFC 4251 and 4252. You may not even need to go into
the details of 4252 to answer your questions.


//Peter