please decrypt your manuals

Doru Georgescu headset001 at
Mon Apr 19 18:55:14 EST 2010

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.

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. 

<< This is logical enough, unfortunately the SSH_KNOWN_HOSTS FILE FORMAT section of the sshd manual says that the public host key from /etc/ssh/ (on the server, I guess) can be copied to /etc/ssh/ssh_known_hosts or ~/.ssh/known_hosts (on the client, I guess). Anyway, I don't believe that both files are supposed to be on the same machine, while both files are listed in the list of files. 

> Please show me clearly, step by step, how do you use the content of
> the sshd manual to conclude that /etc/ssh/ 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:

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

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.

<< This works for /etc/ssh/, which is listed in the sshd manual only, but not for /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts, which are listed in both ssh and sshd manuals. How do you know that /etc/ssh/ssh_known_hosts mentioned in the SSH_KNOWN_HOSTS FILE FORMAT section of the sshd manual is actually on the client, as I suspect. But you may answer that one does not expect to read about this server authentication procedure under the SSH_KNOWN_HOSTS FILE FORMAT title, anyway ... :-) In case this is a general authentication procedure, then still some files are on the authenticated machine and others on the authenticating machine. I hope that the English language survives this formulation. 

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

<< I'm talking about the manuals only. While of course they deal with the OpenSSH implementation only, I believe that they should also contain some minimal information from RFC's, to provide a meaningful presentation. For example, the terminology could be well defined. That is, unique words for every basic concept, and some logical connections between basic concepts. A presentation of keys used, similar with the presentation of the files used, should not hurt anybody. 

<< Anyway, let us just limit ourselves to the issue of the location of the /etc/ssh/ (on the server, I guess) and /etc/ssh/ssh_known_hosts or ~/.ssh/known_hosts (on the client, I guess), which are mentioned in the SSH_KNOWN_HOSTS FILE FORMAT section of the sshd 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.

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:

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

             Contains the public key for authentication.  These files are not
             sensitive and can (but need not) be readable by anyone.

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.

<< Excepting where it lives. And the first hint, that /etc/ssh/ is on the server, is no longer acceptable. The list of files in a manual lists files mentioned in the manual, not the files directly used by the manual's software. 

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

> find out on what machine is /etc/ssh/
> 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. :\

<< You can help a lot by supporting my proposition to specify the location of files referred in the manuals. 

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

<< Maybe the manuals are supposed, for every basic concept they use, to either explain it a little bit, or refer to some RFC section. I support the first solution, because a few words can save a lot of effort. 

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

<< I know what it does, I don't know what file the SSH_KNOWN_HOSTS FILE FORMAT of the sshd manual is referring to, the one on the server or the one on the client. 

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

<< Well, if you failed to show me where does /etc/ssh/ssh_known_hosts live, I won't rely too much on the manual. 

> 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

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.

<< Bad manual. It should say that it does not make any sense before you read RFC's. It should make sense even if one does not read RFC's. It should define some basic terms and explain some simple procedures, like using /etc/ssh/ssh_known_hosts to perform authentication. 

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

<< Thank you for this. The client verifies the public host key of the server. This sentence would look great in the manual. 

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.

<< that is the server's private host key, found in /etc/ssh/ssh_host_key and the other two similar files. 

> The client is authenticated to the server,

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

<< Right, the client user, not the client machine authenticates to the server. This sentence would also make the manual too clear. 

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


If you can't show me step by step reasoning, inside the sshd manual, or at least inside all the ssh manuals (which would be a treat), to prove that the /etc/ssh/ssh_known_hosts, the /.ssh/known_hosts and the /etc/ssh/ files referred under the SSH_KNOWN_HOSTS FILE FORMAT section of the sshd manual, are fully specified and you still claim that the manual is correct, then the problem we face is no longer technical but social or psychological, and I decline my competence, while I maintain my curiosity: Why would you do that? 



More information about the openssh-unix-dev mailing list