openssh unix dev - Mar 2010 - please decrypt your manuals

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. For example, man sshd
SSH_KNOWN_HOSTS FILE FORMAT 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.

II. a general presentation of ssh workings is missing, and makes the decryption
of those manuals even more difficult. i suppose, but i am not sure that:

both encrypt their messages with the encryption keys in: 
/etc/ssh/ssh_host_[rd]sa_key
/etc/ssh/ssh_host_[rd]sa_key.pub

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. this happens in two ways: 

1. server side: 
      a. the client provides an authentication key: 
         + public part in //server/~/.ssh/authorized_keys 
            with chmod 700 .ssh; chmod 600 authorized_keys 
         + private part in //client/~/.ssh/id_rsa 

      the authentication key is created with: 
      ssh-keygen -t rsa
      ll gives: 
      -rw-------    1 dave     dave          526 Nov  3 01:21 id_rsa
      -rw-r--r--    1 dave     dave          330 Nov  3 01:21 id_rsa.pub
      and can be copied with (just a direct copy from //client/~/.ssh/id_rsa.pub
to //server/~/.ssh/authorized_keys, or append to preserve other keys):
      ssh-copy-id username at host 

      b. the client provides its password 

2. client side: 
      the client verifies that it has the server's public encryption key: 
      a. with a stupid question to the unknowing human at the client's
console
      b. verifying the server's public encryption key against the lists of
servers' public encryption keys in:
         //client/etc/ssh/ssh_known_hosts and //client/~/.ssh/known_hosts 
      you can copy and paste the key from //server/etc/ssh/ssh_host_rsa_key.pub
to //client/~/.ssh/known_hosts, minus username at server at the end, plus
username at server at the beginning, with blanks as separators. ssh-keygen -H to
hash names.


//server/etc/ssh/ssh_known_hosts and //server/~/.ssh/known_hosts are not used
habitually, because other authentication means are preferred.

see mans ssh, sshd, ssh_config, sshd_config 


These few lines took me three frustating days of hard work, instead of two easy
hours of learning, and I am still not sure I guessed rightly. I believe that
this attitude makes Linux lose market in favour of Windows servers. I hope that
the author of sshd manual will correct his writing. Please verify my
"discoveries" above and publish them somewhere.


Less important: 
I still don't know if the encryption keys can be regenerated, and I am not
sure that every line sent from client to server is authenticated, as it should.
Also, I was surprised to see that I can not limit the number of tries for
passwords. That config option is about logging of tries, not limiting them.

OpenSSH documentation might assume strong familiarity with UNIX
systems. I'm not sure that this is a bad thing.


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.

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.

> II. a general presentation of ssh workings is missing,
This is completely out of scope for OpenSSH IMO. OpenSSH is one of
many implementations of the protocol.

How SSH works, in general, is very well described in the SSH RFCs.
Please read RFC 4250 through 4254 for more info, at least RFC 4251.

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

> These few lines took me three frustating days of hard work, instead
> of two easy hours of learning, and I am still not sure I guessed
> rightly. I believe that this attitude makes Linux lose market in
> favour of Windows servers.
OpenSSH has nothing to do with Linux, really.

And OpenSSH could not care less about the market of Linux.

Finally, OpenSSH runs also on Windows.

That said, I agree with you that open source requires ownership of
one's problems. If you want to solve a problem with open source tools
then you really need to understand the problem, and then the solution
will be easy to find. Or you can hire a consultant to help.

I find that Windows servers often do not even allow me to find out
what the problem actually is, so even though I am fairly experienced
with computers all my methods fail, because I get no data that I can
try to use to find a solution. I can of course hire Microsoft, then
they will gladly send someone to help me, maybe even without
explaining what the problem was.

> I hope that the author of sshd manual will correct his writing.
That's really not very nice. I hope that YOU will correct the
writing - if you think you can do it better! Please do! It would be
fantastic to have even better documentation.

Remember that the OpenSSH project is not the work of one single
author, but the work of many people working together. It is very easy
to get involved - just send an improvement of current state to the
mailing list.

> Please verify my "discoveries" above and publish them somewhere.
Please ask specific questions. Noone will explain every single detail
of OpenSSH to you - but I think many will be happy to give quick
answers to straightforward questions.

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

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

> Also, I was surprised to see that I can not limit the number of
> tries for passwords. That config option is about logging of tries,
> not limiting them. 
sshd is not likely the only service in your system which accepts
password authentication, so it is clearly not the appropriate entity
to implement your security policy. Something else, more appropriate,
would be PAM, but there are also other possibilities.

In any case, I strongly recommend against using passwords for
authentication at all. Create keys for your users instead.


Kind regards

//Peter

>> 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.
>> II. a general presentation of ssh workings is missing,
> This is completely out of scope for OpenSSH IMO. OpenSSH is one of
> many implementations of the protocol.
> How SSH works, in general, is very well described in the SSH RFCs.
> Please read RFC 4250 through 4254 for more info, at least RFC 4251.
I referred to a short scheme about how ssh files are actually used and managed
by the user. I tried to begin the creation of such a scheme in my paragraph II,
which is no longer here ... ;-).
>> 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.
>> These few lines took me three frustating days of hard work, instead
>> of two easy hours of learning, and I am still not sure I guessed
>> rightly. I believe that this attitude makes Linux lose market in
>> favour of Windows servers.
> OpenSSH has nothing to do with Linux, really.
> And OpenSSH could not care less about the market of Linux.
> Finally, OpenSSH runs also on Windows.
I thought about ssh as a part of Linux, but ssh manuals are part of the ssh
product, and I expected its developers to care about the quality of their
product.

Can I access dos with ssh through cygwin? 
>> I hope that the author of sshd manual will correct his writing.
> That's really not very nice. I hope that YOU will correct the
> writing - if you think you can do it better! Please do! It would be
> fantastic to have even better documentation.
I started to propose small improvements. If we work out where do those files
actually reside, I hope we will pass through the few lines in my paragaph II,
sometimes.
> Remember that the OpenSSH project is not the work of one single
> author, but the work of many people working together. It is very easy
> to get involved - just send an improvement of current state to the
mailing list.

I should improve my paragraph II, of course. I hope I will find help for this. 
>> 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.
>> 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.
>> Also, I was surprised to see that I can not limit the number of
>> tries for passwords. That config option is about logging of tries,
>> not limiting them. 
> sshd is not likely the only service in your system which accepts
> password authentication, so it is clearly not the appropriate entity
> to implement your security policy. Something else, more appropriate,
> would be PAM, but there are also other possibilities.
> In any case, I strongly recommend against using passwords for
> authentication at all. Create keys for your users instead.
Right, thanks for this. I'll use the keys ... :) 
> Kind regards
> //Peter
Thanks, maybe I'll untie this node. 

Doru

Doru Georgescu wrote:
> I. most of ssh manual and all sshd manual present server and client
> as one machine, called host.
Well, that is certainly one possibility.  A single host may be
operating both as a client and as a server *to itself* and that is
perfectly okay.  The documentation is very generically and very
precisely correct by not making assumptions and simply explaining
things dryly.
> All files mentioned are placed on one machine. This is incorrect,
> and makes the explanation unclear.
But it isn't incorrect.  A single host may be either a client or a
server or both.  The choice is completely controlled by how it is
configured.  The administrator may configure it ether one way or the
other way or both ways.

The documentation is very generically and very precisely correct by
not making assumptions and simply explaining things dryly.
> For example, man sshd SSH_KNOWN_HOSTS FILE FORMAT 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.
I do not see that in my copy of the manual.  I do see an explanation
of where the bits come from.  But I don't see a suggestion that a
human do this copying.  In fact I see an admonition that you would not
want to "type them in by hand" but would instead "generate them
by a
script or by taking /etc/ssh/ssh_host_key.pub and adding the host
names at the front."  By "host names" it is clearly talking about
multiple hosts, in the plural, and cannot be referring to a single
host.

But...  I think most users of ssh can use it for many years and never
even know about the files in /etc/ssh/*.  It isn't necessary in the
normal course of operation for them to know about them.  I wouldn't
recommend that a user copy files /etc/ssh/ssh_host_rsa_key.pub to
their ~/known_hosts file.  How would they actually do that?  They
would likely want to use ssh for that and that would be a
bootstrapping problem.  Better to check the hash fingerprint of the
key in that case.
> II. a general presentation of ssh workings is missing, and makes the
> decryption of those manuals even more difficult. i suppose, but i am
> not sure that:
> 
> both encrypt their messages with the encryption keys in: 
> /etc/ssh/ssh_host_[rd]sa_key
> /etc/ssh/ssh_host_[rd]sa_key.pub
On one level I don't think this matters to a user.  Users don't need
to know this in order to use ssh securely.  As an alternate example,
people drive cars.  People drive cars over bridges.  Documenting how
the bridge is constructed is definitely of interest to public safety
but most drivers do not need to know how to construct a bridge in
order to drive over one safely.  Therefore I would leave this
documentation for other resources.
> both can memorize known hosts' public encryption keys in
> /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts
Checking the key's fingerprint is more commonly the check method of
choice.
> only the server is protected through authentication. this happens in
> two ways:
> 
> 1. server side: 
>       a. the client provides an authentication key: 
>          + public part in //server/~/.ssh/authorized_keys 
>             with chmod 700 .ssh; chmod 600 authorized_keys 
It isn't necessary that the file not be readable, just not writable by
other than the owner.  Your use of 700 and 600 is too restrictive.
>          + private part in //client/~/.ssh/id_rsa 
There is a problem with using //client/etc/ssh/... and
//server/etc/ssh/... types of paths in the documentation to mean
that files reside on the client and server however.  The "//"
characters are special at the front of a path name.  Apollo Domain
systems, later OSF/1, and currently Cygwin all use it to indicate that
the next part is a hostname.  Because of this POSIX has standardized
that when "//" occurs at the leading part of a path name that the
result is implementation defined.  (Or maybe undefined, I didn't look
it up now to be certain.)

Therefore it would be very confusing to use it here to indicate that
some files exist on the client side of the ssh connection and another
file on the server side of the ssh connection when, depending upon the
system the user happens to be running on, the syntax on that machine
might actually indicate something completely different from what you
are trying to indicate.  It is possible that on a user's system that
//client/etc/... might be an actual working live path to a real system!
They might end up trying it literally and getting files from some
other system other than the one you intended.  Therefore you shouldn't
use it as an example meaning something completely different.  Even
though it doesn't work that way on most systems we avoid it out of
neighborly politeness and respect for the standard.
>       the authentication key is created with: 
>       ssh-keygen -t rsa
>       ll gives: 
>       -rw-------    1 dave     dave          526 Nov  3 01:21 id_rsa
>       -rw-r--r--    1 dave     dave          330 Nov  3 01:21 id_rsa.pub
>       and can be copied with (just a direct copy from
>       //client/~/.ssh/id_rsa.pub to //server/~/.ssh/authorized_keys,
>       or append to preserve other keys):
>       ssh-copy-id username at host 
The ssh man page already says:

  The user creates his/her key pair by running ssh-keygen(1).  ...
  The user should then copy the public key to ~/.ssh/authorized_keys
  in his/her home directory on the remote machine.

A few more reinforcing "on the server host" and "on the client
host"
sprinkled through the docs may be beneficial though.
>       b. the client provides its password 
> 
> 2. client side: 
I think the client side should be described first.  Since that is
where most users will start.  Otherwise before the cart is where the
horse is put.
>       b. verifying the server's public encryption key against the
>       lists of servers' public encryption keys in:
>          //client/etc/ssh/ssh_known_hosts and //client/~/.ssh/known_hosts 
>       you can copy and paste the key from
>       //server/etc/ssh/ssh_host_rsa_key.pub to
>       //client/~/.ssh/known_hosts, minus username at server at the end,
>       plus username at server at the beginning, with blanks as
>       separators. ssh-keygen -H to hash names.
I think that is very confusing.  I don't think it would survive most
humans trying to execute those instructions.

Better for most people is to verify the key fingerprint and let the
software handle manipulating the known hosts information for you.  I
know many ssh users who have used it (securely) for years and have
never known about /etc/ssh/ssh_host*.pub keys.  I wouldn't start a
user there.  But of course if at a site with many systems locally then
maintaining a site ssh_known_hosts by the site administrator makes
sense.  But again that isn't usually where people would start when
learning about ssh.  Site administrators are expected to have a
familiarity with the operating system.
> These few lines took me three frustating days of hard work, instead
> of two easy hours of learning, and I am still not sure I guessed
> rightly.
The format of man pages makes them good reference documents but not so
good user manuals.  This has long been argued.  HOWTO documents,
tutorials, user manuals, and FAQs really are better served in a format
more specific to their needs.  There are many ssh HOWTOs and tutorials
in the world.  I think what you are realy wanting is to have ssh
include the best of them with the ssh suite instead of having them be
independent works available elsewhere.  The problem is that someone
would actually need to do the work and it would be a lot of work.

There are a lot of good Getting Started style user manuals and HOWTOs
that are available on the web.  I would start there when trying to
learn how to use ssh.  They are a lot easier than the man pages.  And
if you try to change the man pages into a Gentle Introduction to ssh
then they lose their value as man pages.
> I believe that this attitude makes Linux lose market in favour of
> Windows servers.
OpenSSH really doesn't relate to Linux market share.  Natively OpenSSH
is part of OpenBSD which doesn't make use of Linux.  GNU/Linux based
systems use OpenSSH from OpenBSD as a port.  (And we are very
appreciative of it!)  Plus ssh runs on all kinds of operating system
platforms including MS-Windows.  Someone trying to use ssh on
MS-Windows could be just as frustrated and issue the same statement
there too!
> I still don't know if the encryption keys can be regenerated, and I
> am not sure that every line sent from client to server is
> authenticated, as it should. Also, I was surprised to see that I can
> not limit the number of tries for passwords. That config option is
> about logging of tries, not limiting them.
When I think of encryption keys in conjuction with ssh connections I
think of the session key used to encrypt the communication between the
two hosts.  This is handled automatically by ssh.  You don't need to
manually re-key the connection.  However you may do so with a newline
followed by "~R".  Terminal escape characters are documented in the
ssh(1) manual where it says:

     ~R      Request rekeying of the connection (only useful for SSH protocol
             version 2 and if the peer supports it).

The RekeyLimit is documented in the ssh_config(5) manual and says:

     RekeyLimit
             Specifies the maximum amount of data that may be transmitted
             before the session key is renegotiated.  The argument is the num-
             ber of bytes, with an optional suffix of ?K?, ?M?, or ?G? to
             indicate Kilobytes, Megabytes, or Gigabytes, respectively.  The
             default is between ?1G? and ?4G?, depending on the cipher.  This
             option applies to protocol version 2 only.

But you are probably thinking about keys used for user authentication.
You can change those keys too.  Of course if you do then the previous
credentials are no longer valid and the new ones would need to be
installed.  I do this every so often as a matter of routine when I
move from one system to another during system upgrades.

Or you may be talking about host keys used for host identification.
Host keys can certainly be changed too but doing so will appear to
users the same as if the host were being attacked with a man in the
middle attack.  Therefore this type of change must be communicated
such that the user can expect it and manually deal with the change.
That would mean removing the old host key and verifying the
fingerprint of the new host.  Fortunately changing host keys isn't
often needed and so this isn't something routinely seen.

Bob

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

2010/4/7 Doru Georgescu <headset001 at yahoo.com>:
> I want to connect two computers, using openssh. One computer will be the
client, there I sit in front of the console and do "ssh
the_other_computer". The other computer will be the server. I want to
connect using keys instead of a password, for improved security.
> So:
> I open the sshd manual and see that it refers to many files. Some of these
files are on the server, others are on the client. Of course, there are files
with the same name both on server and client. But the manual does not say when
it refers to files on server, and when it refers to files on client. Therefore,
the manual is incorrect, because it does not convey the information it is
supposed to convey.
Or you have some basic lack of understanding client/server software...

You have missunderstood how files are used in Unix. In fact many files
are used by both client software and
server software. The files /etc/services  and /etc/protocols are of
this kind. If you write "man sshd" all configuration files
should be stated, for the server, in the manual page and likewise "man
ssh" should give all relevant files for the client.
NOTE! Some of them *could* be the same! It is up to the programmer!
> Now tell me what don't you understand in the above two paragraphs,
because I certainly can tell what can't I understand in the large number of
answers which I received on this list: why do none of them answer to what I
said, and why do you everybody change the subject while still post in my thread?
You can't write in a thread like this and say that the manuals are
wrong, when you don't know the definition of
client/server software, *and* refereing to machines as clients or
server or operating systems as clients or server,
without getting a lot of comments.

Cordially yours,
GH
>
> Doru
>
>
> --- On Mon, 4/5/10, Goran Hasse <gorhas at gmail.com> wrote:
>
>> From: Goran Hasse <gorhas at gmail.com>
>> Subject: Re: please decrypt your manuals
>> To: "Doru Georgescu" <headset001 at yahoo.com>
>> Date: Monday, April 5, 2010, 8:50 AM
>> Dear Doru,
>>
>> You should know that in the Unix environment it is *very*
>> common to
>> connect from one machine to "itself". If for instance a
>> system have
>> several interface (many IP addresses) this could be the
>> only way to
>> access some services.
>>
>> In fact, there is no sutch terms as server/client machines.
>> Software
>> can be server (they have a "listen" system call), and
>> software could be
>> clients (they have a "connect" system call).
>>
>> You should know that if you want to discuss those matters,
>> the ssh
>> mail list is *not* the place to do it.
>>
>> Cordially Yours,
>>
>> GH
>>
>> --
>> gorhas at gmail.com
>> Mob: 070-5530148
>>
>
>
>
>


-- 
gorhas at gmail.com
Mob: 070-5530148

> > I. most of ssh manual and all sshd manual present
> server and client
> > as one machine, called host.
> 
> Well, that is certainly one possibility.? A single
> host may be
> operating both as a client and as a server *to itself* and
> that is
> perfectly okay.? The documentation is very generically
> and very
> precisely correct by not making assumptions and simply
> explaining
> things dryly.
This "possibility" is a degenerated case, and the manual does not
deliver the information it should. It is like teaching Pythagoras' theorem
for the case of a triangle with one side zero. I am sure that you do not need to
be a good computer programmer to understand this.
> 
> > All files mentioned are placed on one machine. This is
> incorrect,
> > and makes the explanation unclear.
> 
> But it isn't incorrect.? A single host may be either a
> client or a
> server or both.? The choice is completely controlled
> by how it is
> configured.? The administrator may configure it ether
> one way or the
> other way or both ways.
> 
> The documentation is very generically and very precisely
> correct by
> not making assumptions and simply explaining things dryly.
The manual is incorrect by not delivering the information it should. It presents
a degenerated case which is useless for the normal user.
> 
> > For example, man sshd SSH_KNOWN_HOSTS FILE FORMAT
> 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.
> 
> I do not see that in my copy of the manual.? I do see
> an explanation
> of where the bits come from.? But I don't see a
> suggestion that a
> human do this copying.? In fact I see an admonition
> that you would not
> want to "type them in by hand" but would instead "generate
> them by a
> script or by taking /etc/ssh/ssh_host_key.pub and adding
> the host
> names at the front."? By "host names" it is clearly
> talking about
> multiple hosts, in the plural, and cannot be referring to a
> single
> host.
In that case, the manual should distinguish between those multiple hosts. 

I am not going to discuss with you who is supposed to "take" and
"add" that data, a human or a robot.
> 
> But...? I think most users of ssh can use it for many
> years and never
> even know about the files in /etc/ssh/*.? It isn't
> necessary in the
> normal course of operation for them to know about
> them.? I wouldn't
> recommend that a user copy files
> /etc/ssh/ssh_host_rsa_key.pub to
> their ~/known_hosts file.? How would they actually do
> that?? 
Sorry, but that's how it works. 

They
> would likely want to use ssh for that and that would be a
> bootstrapping problem.? 
I use public transportation. Anyway, it is more difficult for someone to put
together a SMS and a ssh connection for a man in the middle attack, rather than
to wait for you to established a connection unprotected against such an attack.

Better to check the hash
> fingerprint of the
> key in that case.
> 
I prefer to reserve that choice. I hope you don't propose that the paragraph
I discuss in the sshd manual to be removed.
> > II. a general presentation of ssh workings is missing,
> and makes the
> > decryption of those manuals even more difficult. i
> suppose, but i am
> > not sure that:
> > 
> > both encrypt their messages with the encryption keys
> in: 
> > /etc/ssh/ssh_host_[rd]sa_key
> > /etc/ssh/ssh_host_[rd]sa_key.pub
> 
> On one level I don't think this matters to a user.?
> Users don't need
> to know this in order to use ssh securely.? As an
> alternate example,
> people drive cars.? People drive cars over
> bridges.? Documenting how
> the bridge is constructed is definitely of interest to
> public safety
> but most drivers do not need to know how to construct a
> bridge in
> order to drive over one safely.? Therefore I would
> leave this
> documentation for other resources.
Then, you should delete those files from the manual. They are used a lot there.
What is the point with mentioning them, if they are not explained a little bit
and if they are not actually necessary?
> 
> > both can memorize known hosts' public encryption keys
> in
> > /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts
> 
> Checking the key's fingerprint is more commonly the check
> method of
> choice.
That is your choice. I have been already advised on this mail list to use keys
instead of passwords and I also agree with this.
> 
> > only the server is protected through authentication.
> this happens in
> > two ways:
> > 
> > 1. server side: 
> >? ? ???a. the client provides
> an authentication key: 
> >? ? ? ? ? + public part in
> //server/~/.ssh/authorized_keys 
> >? ? ? ? ?
> ???with chmod 700 .ssh; chmod 600
> authorized_keys 
> 
> It isn't necessary that the file not be readable, just not
> writable by
> other than the owner.? Your use of 700 and 600 is too
> restrictive.
OK. 
> 
> >? ? ? ? ? + private part in
> //client/~/.ssh/id_rsa 
> 
> There is a problem with using //client/etc/ssh/... and
> //server/etc/ssh/... types of paths in the documentation to
> mean
> that files reside on the client and server however.?
> The "//"
> characters are special at the front of a path name.?
> Apollo Domain
> systems, later OSF/1, and currently Cygwin all use it to
> indicate that
> the next part is a hostname.? Because of this POSIX
> has standardized
> that when "//" occurs at the leading part of a path name
> that the
> result is implementation defined.? (Or maybe
> undefined, I didn't look
> it up now to be certain.)
> 
> Therefore it would be very confusing to use it here to
> indicate that
> some files exist on the client side of the ssh connection
> and another
> file on the server side of the ssh connection when,
> depending upon the
> system the user happens to be running on, the syntax on
> that machine
> might actually indicate something completely different from
> what you
> are trying to indicate.? It is possible that on a
> user's system that
> //client/etc/... might be an actual working live path to a
> real system!
> They might end up trying it literally and getting files
> from some
> other system other than the one you intended.?
> Therefore you shouldn't
> use it as an example meaning something completely
> different.? Even
> though it doesn't work that way on most systems we avoid it
> out of
> neighborly politeness and respect for the standard.
OK, so use plain English: ~/.ssh/id_rsa on client. The issue is, do you agree
that the manuals should fully specify the files they refer, that is, including
the machine on which they live, or not?
> 
> >? ? ???the authentication key
> is created with: 
> >? ? ???ssh-keygen -t rsa
> >? ? ???ll gives: 
> >? ? ???-rw-------? ?
> 1 dave? ???dave? ? ?
> ? ? 526 Nov? 3 01:21 id_rsa
> >? ? ???-rw-r--r--? ?
> 1 dave? ???dave? ? ?
> ? ? 330 Nov? 3 01:21 id_rsa.pub
> >? ? ???and can be copied with
> (just a direct copy from
> >? ?
> ???//client/~/.ssh/id_rsa.pub to
> //server/~/.ssh/authorized_keys,
> >? ? ???or append to preserve
> other keys):
> 
> >? ? ???ssh-copy-id
> username at host 
> 
> The ssh man page already says:
> 
> ? The user creates his/her key pair by running
> ssh-keygen(1).? ...
> ? The user should then copy the public key to
> ~/.ssh/authorized_keys
> ? in his/her home directory on the remote machine.
> 
> A few more reinforcing "on the server host" and "on the
> client host"
> sprinkled through the docs may be beneficial though.
That only appears in one place in the ssh manual, and every file in the sshd
manual can be found on both the server and client, and some files are actually
used by both the ssh server and the ssh client software on one machine, such
that the reader can not know about what functionality is the manual actually
speaking and about what file precisely: the one on the server, or the one on the
client?
> 
> >? ? ???b. the client provides
> its password 
> > 
> > 2. client side: 
> 
> I think the client side should be described first.?
> Since that is
> where most users will start.? Otherwise before the
> cart is where the
> horse is put.
As a programmer, I saw that the server is running first, and that the server is
protected by authentication, so I started with the server. However, if this
change makes it to the manual, I wholeheartedly agree with it.
> 
> >? ? ???b. verifying the
> server's public encryption key against the
> >? ? ???lists of servers'
> public encryption keys in:
> >? ? ? ? ?
> //client/etc/ssh/ssh_known_hosts and
> //client/~/.ssh/known_hosts 
> >? ? ???you can copy and paste
> the key from
> >? ?
> ???//server/etc/ssh/ssh_host_rsa_key.pub to
> >? ?
> ???//client/~/.ssh/known_hosts, minus
> username at server at the end,
> >? ? ???plus username at server at
> the beginning, with blanks as
> >? ? ???separators. ssh-keygen
> -H to hash names.
> 
> I think that is very confusing.? I don't think it
> would survive most
> humans trying to execute those instructions.
It should be put into plain English. This is a sketchy note. 
> 
> Better for most people is to verify the key fingerprint and
> let the
> software handle manipulating the known hosts information
> for you.? I
> know many ssh users who have used it (securely) for years
> and have
> never known about /etc/ssh/ssh_host*.pub keys.? I
> wouldn't start a
> user there.? But of course if at a site with many
> systems locally then
> maintaining a site ssh_known_hosts by the site
> administrator makes
> sense.? 
You caught me. 

But again that isn't usually where people
> would start when
> learning about ssh.? Site administrators are expected
> to have a
> familiarity with the operating system.
Still, the manual should make sense. And I am neither a site administrator nor a
dumb user. I am a user who wants to use ssh a bit more securely. And some site
administrators are also beginners, and they should also read a sane manual.
> 
> > These few lines took me three frustating days of hard
> work, instead
> > of two easy hours of learning, and I am still not sure
> I guessed
> > rightly.
> 
> The format of man pages makes them good reference documents
> but not so
> good user manuals.? This has long been argued.?
> HOWTO documents,
> tutorials, user manuals, and FAQs really are better served
> in a format
> more specific to their needs.? There are many ssh
> HOWTOs and tutorials
> in the world.? I think what you are realy wanting is
> to have ssh
> include the best of them with the ssh suite instead of
> having them be
> independent works available elsewhere.? The problem is
> that someone
> would actually need to do the work and it would be a lot of
> work.
> 
> There are a lot of good Getting Started style user manuals
> and HOWTOs
> that are available on the web.? I would start there
> when trying to
> learn how to use ssh.? They are a lot easier than the
> man pages.? And
> if you try to change the man pages into a Gentle
> Introduction to ssh
> then they lose their value as man pages.
No sir, the manual is incorrect. In fact, it is illogically presented. There is
a difference between being concise, organized as a reference, and being
incoherent. I only concentrated on file specification because it is so glaringly
obvious.
> 
> > I believe that this attitude makes Linux lose market
> in favour of
> > Windows servers.
> 
> OpenSSH really doesn't relate to Linux market share.?
> Natively OpenSSH
> is part of OpenBSD which doesn't make use of Linux.?
> GNU/Linux based
> systems use OpenSSH from OpenBSD as a port.? (And we
> are very
> appreciative of it!)? Plus ssh runs on all kinds of
> operating system
> platforms including MS-Windows.? Someone trying to use
> ssh on
> MS-Windows could be just as frustrated and issue the same
> statement
> there too!
Right, I did not know this, but still the manual is part of the OpenSSH project.
And, by the way, Cygwin is more a virtual Unix on Windows, then Windows.
> 
> > I still don't know if the encryption keys can be
> regenerated, and I
> > am not sure that every line sent from client to server
> is
> > authenticated, as it should. Also, I was surprised to
> see that I can
> > not limit the number of tries for passwords. That
> config option is
> > about logging of tries, not limiting them.
> 
> When I think of encryption keys in conjuction with ssh
> connections I
> think of the session key used to encrypt the communication
> between the
> two hosts.? 
Yes, me too. Do the server ssh and client ssh software on one machine use the
same key?

This is handled automatically by
> ssh.? You don't need to
> manually re-key the connection.? However you may do so
> with a newline
> followed by "~R".? Terminal escape characters are
> documented in the
> ssh(1) manual where it says:
> 
> ? ???~R? ? ? Request
> rekeying of the connection (only useful for SSH protocol
> ? ? ? ? ?
> ???version 2 and if the peer supports it).
> 
> The RekeyLimit is documented in the ssh_config(5) manual
> and says:
> 
> ? ???RekeyLimit
> ? ? ? ? ?
> ???Specifies the maximum amount of data that
> may be transmitted
> ? ? ? ? ? ???before
> the session key is renegotiated.? The argument is the
> num-
> ? ? ? ? ? ???ber of
> bytes, with an optional suffix of ?K?, ?M?, or
> ?G? to
> ? ? ? ? ?
> ???indicate Kilobytes, Megabytes, or
> Gigabytes, respectively.? The
> ? ? ? ? ?
> ???default is between ?1G? and ?4G?,
> depending on the cipher.? This
> ? ? ? ? ? ???option
> applies to protocol version 2 only.
So they are dynamically generated all the time. 
But 
/etc/ssh/ssh_host_[rd]sa_key
/etc/ssh/ssh_host_[rd]sa_key.pub
are rather constant, so you lost me here. 
> 
> But you are probably thinking about keys used for user
> authentication.
> You can change those keys too.? Of course if you do
> then the previous
> credentials are no longer valid and the new ones would need
> to be
> installed.? I do this every so often as a matter of
> routine when I
> move from one system to another during system upgrades.
Not clear why. 
> 
> Or you may be talking about host keys used for host
> identification.
Probably these are in /etc/ssh/ssh_host_[rd]sa_key
/etc/ssh/ssh_host_[rd]sa_key.pub. 

Please show me where are these keys explained in the manuals. There should be a
list of used keys, like the list of used files.
> Host keys can certainly be changed too but doing so will
> appear to
> users the same as if the host were being attacked with a
> man in the
> middle attack.? Therefore this type of change must be
> communicated
> such that the user can expect it and manually deal with the
> change.
> That would mean removing the old host key and verifying
> the
> fingerprint of the new host.? Fortunately changing
> host keys isn't
> often needed and so this isn't something routinely seen.
> 
> Bob
>
Thank you for your answer. You certainly are more logical than the manuals.
Please support my proposal to fully specify the location of files referred in
the sshd manual.

Doru

> In fact, there is no sutch terms as server/client machines.
> Software
> can be server (they have a "listen" system call), and
> software could be
> clients (they have a "connect" system call).
The ssh manual says: 
"on the remote machine and contain a line con?
     taining the name of the client machine "

By the way, the manual should use terms consistently, for example server for
remote and client for client. Please.

Doru

> >> 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."
Yes, but is it on the server or on the client? You may remember that the subject
of this thread is the location of the /etc/ssh/ssh_known_hosts and
~/.ssh/known_hosts files referred under the SSH_KNOWN_HOSTS FILE FORMAT title in
the sshd manual. I'm not sure that this location is specified in the sshd
manual, directly or indirectly.
> > 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).
You know this from the manuals? :-) 
> >> AFAIK the files are used only by the server. The
> client
> >> will receive
> >> that public key from the handshake.
You mean, client? Maybe the manual should say this. 
> >> 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.
They may be talking with a man in the middle. 
> 
> - S signs a token with its private key, so that C can
> verify that it is
> really the server it wants to talk to.
> 
Maybe the S's host key is used for authentication of S in front of C. 

Indeed (ssh man): 

     /etc/ssh/ssh_host_key
     /etc/ssh/ssh_host_dsa_key
     /etc/ssh/ssh_host_rsa_key
             These three files contain the private parts of the host keys and
are used
             for host-based authentication. 

So S is authenticated in front of C with a token, and this authentication is
based on the human in front of C's console recognizing the hash
(fingerprint) of the S's public host key.

Thank you for your help. In case I got it right. 

Please support my proposal to have the ssh manuals fully specify the location of
files they refer.

> Please support my proposal to have the ssh manuals fully specify the
> location of files they refer.
You are welcome to submit a patch to our bug tracking system:
https://bugzilla.mindrot.org/

Once you have come up with something concrete then we can discuss it.

-d

On Wed, Apr 07, 2010 at 09:24:57PM +0200, Peter Stuge
wrote:
> 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.
And if user authentication is done with public keys then a man in the
middle attack isn't possible even if the attacker knows the private part
of the host key. At least not unless the server or the client has been
compromised in other ways, e.g. if it is using a broken random number
generator.

----------------

If the attacker knows the server's private host key, and all public keys,
then it could impersonate the server in front of the client. Why not?

Doru

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/ssh_host_key.pub (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/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.

<< This works for /etc/ssh/ssh_host_key.pub, 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/ssh_host_key.pub (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:

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

<< Excepting where it lives. And the first hint, that
/etc/ssh/ssh_host_key.pub 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
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. :\

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

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

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

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


//Peter

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/ssh_host_key.pub 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?

Doru

--- On Sun, 4/18/10, Damien Miller <djm at mindrot.org> wrote:
> From: Damien Miller <djm at mindrot.org>
> Subject: Re: please decrypt your manuals
> To: "Doru Georgescu" <headset001 at yahoo.com>
> Cc: "Keisial" <keisial at gmail.com>, "OpenSSH"
<openssh-unix-dev at mindrot.org>
> Date: Sunday, April 18, 2010, 8:27 AM
> > Please support my proposal to
> have the ssh manuals fully specify the
> > location of files they refer.
> 
> You are welcome to submit a patch to our bug tracking
> system:
> https://bugzilla.mindrot.org/
> 
> Once you have come up with something concrete then we can
> discuss it.
> 
> -d
> 

I propose to add to every file mentioned in the ssh manuals the specification of
whether it lives on the server machine or on the client machine, or whether it
is used by the server software or by the client software, as it is the case. If
all files in a manual are on one machine, this can be said in one place in that
manual. If most files in a manual are on one machine, this can be again said in
one place, and only those files residing on the other machine should be
specified individually. If one file is used by both the server and the client,
than this should be mentioned in the file explanation in the list of files, in
all manuals where that respective file appears in the list of files, to avoid
confusion. Also to avoid confusion, a few words explaining how do the client and
the server use that specific file, should be added.

I can submit a patch only with the cooperation and support of the people on this
list.

Doru

--- On Mon, 4/19/10, Doru Georgescu <headset001 at yahoo.com> wrote:
> From: Doru Georgescu <headset001 at yahoo.com>
> Subject: please decrypt your manuals
> To: "OpenSSH" <openssh-unix-dev at mindrot.org>
> Date: Monday, April 19, 2010, 4:55 AM
> Doru Georgescu wrote:
> 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.
> Really, look at RFC 4251 and 4252. You may not even need to
> go into
> the details of 4252 to answer your questions.
> 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.
I believe that we can reach the conclusion that you consider the ssh manuals as
a support for ssh developers, while I consider that the ssh manuals should be a
support for the users of ssh. From your point of view, the ssh manuals should
contain sketches of ideas that a ssh developer would need to remember, while I
expect a coherent and self sufficient (but not complete) functional description
of ssh. As a user, I need to use it, so I expect to see its functions described
in the manual. As a developer, you need to remember some name of a configuration
option in the sshd_config file.

It looks strange to see such an important application like ssh without a
user's manual, but I understand that the developers are not motivated to
write it, so this is an economical problem, not a technical one.

Thank you all for your support, which I fully appreciate, and it did help me
very much.
> << Right, the client user, not the client machine
> authenticates to the server. This sentence would also make
> the manual too clear. 
Maybe it should be: the "client user account" is authenticated to the
server.

Doru 
> //Peter

> And if user authentication is done with public keys then a man in the
> middle attack isn't possible even if the attacker knows the private
> part of the host key.[...]
On Mon, Apr 19, 2010 at 12:06:33AM -0700, Doru Georgescu
wrote:
> If the attacker knows the server's private host key, and all public
> keys, then it could impersonate the server in front of the client. Why
> not?
It can impersonate the server, but not perform a man in the middle
attack. Simplified, it's because it can't forge the Diffie-Hellman
exchange which affects the session ID which is signed by the user's key.
See the RFCs (4252 and 4253 I think) for a detailed explanation how it
works.

Of course, this is probably mostly of interest in theory since a
compromised private server key may be an indication that the entire
server is compromised.

   Andreas

---------------

The attacker does not have some private decryption key? Anyway, this is too
involved for me now, but thank you anyway.

Doru

--- On Tue, 4/20/10, Lars Nooden <lars.curator at gmail.com> wrote:
> From: Lars Nooden <lars.curator at gmail.com>
> Subject: Re: please decrypt your manuals
> To: "Doru Georgescu" <headset001 at yahoo.com>
> Cc: "OpenSSH" <openssh-unix-dev at mindrot.org>
> Date: Tuesday, April 20, 2010, 3:48 AM
> On Tue, 20 Apr 2010, Doru Georgescu
> wrote:
> > I believe that ...
> 
> Let's not have speculation.
> 
It has been said several times in this thread that the manual is good enough for
those who already know ssh. And it is. This is not speculation.
> The scope for openssh manual pages is to address the
> components specific to the openssh suite.
I won't argue on that. 
> The manuals are not remedial tutorials to cover the basics
> of system administration.  There are already whole
> websites dedicated to that level of training even if it
> might no longer be available at college.
The manuals are not many things. 
> You can submit a patch to the manuals or the source code if
> you have the skill to make changes and make a diff of your
> changes.  What happens to that patch after being
> submitted is a whole different matter. (*)
Precisely because ssh is the work of a community, it is largely meaningless for
me to write a manual alone, without tight cooperation with that community. The
manual should transmit information from developers to users. For this to happen,
a language (symbols, terminology, structure, logical implication rules) should
be developed. The very idea that I can do this alone, outside the
developers' community, is absurd. Of course such a manual would be rejected,
because it would not make any sense to the developers.

Plus, I completely lack the resources for such a work. 

Doru 
> 
> /Lars
> 
> * FOSS projects are under no obligation to accept or
> integrate patches from random e-yobs regardless of how many
> Microsoft partners tell you otherwise at their
> pseudo-conferences, -seminars or other marketing
> functions.  Either the patch fits with the projects
> goals and quality guidelines or it does not.  If it
> does not, either the idea it is illustrating fits with the
> project goals or does not.
>

I include my current knowledge of ssh. 

The //server/ and //client/ notations are wrong, I kept them for convenience
only.
I use the word "machine" instead of "host" in a few places.
This is wrong. Please get over it.
Some file permissions are restricted too much, but still functional. This is not
important right now.
The information is very incomplete, but it covers most used authentication
techniques.

Please tell me if you agree with it. 

ssh is the client 
sshd is the server 

Communication is fully encrypted and authenticated in both directions. 

The encryption keys are regenerated during communication (~R in man ssh,
RekeyLimit in man ssh_config).

The authenticated machine's (usually the server) host authentication keys
are used to authenticate it in front of other machines or user accounts. These
keys are memorized on the authenticated machine:
/etc/ssh/ssh_host_[rd]sa_key
/etc/ssh/ssh_host_[rd]sa_key.pub
ssh-keygen - authentication key generation and management 

The authenticating machine or user account (usually the client) can memorize
known machines' public host keys in /etc/ssh/ssh_known_hosts and
~/.ssh/known_hosts.

Authentication of the server machine in front of the client user account: 

    the client verifies that the server's public host key is known: 

    a. with a stupid question to the unknowing human at the client's console
    b. verifying the server's public host key against the lists of
servers' public host keys in:
        //client/etc/ssh/ssh_known_hosts and //client/~/.ssh/known_hosts 

     you can copy and paste the key from //server/etc/ssh/ssh_host_rsa_key.pub
to //client/~/.ssh/known_hosts, minus username at server at the end, plus
username at server at the beginning, with blanks as separators. ssh-keygen -H to
hash names.

Authentication of the client user account in front of the server machine: 

    a. the client provides its password 

    b. the client provides an authentication key: 
        + private part in //client/~/.ssh/id_rsa 
        + public part in //server/~/.ssh/authorized_keys 
           with chmod 700 .ssh; chmod 600 authorized_keys 

     the authentication key is created on the client with: 
     ssh-keygen -t rsa
     ll gives: 
     -rw-------    1 dave     dave          526 Nov  3 01:21 id_rsa
     -rw-r--r--    1 dave     dave          330 Nov  3 01:21 id_rsa.pub
     and can be copied from the client with (just a direct copy from
//client/~/.ssh/id_rsa.pub to //server/~/.ssh/authorized_keys, or append to
preserve other keys):
     ssh-copy-id username at server 


see mans ssh, sshd, ssh_config, sshd_config

> As you already pointed out - others also lack resources.
//Peter

This is inefficient from the point of view of the project. 

Developers work outside a well written documentation, which should define what
they are supposed to do.

Developers work without a good reference at hand, defining what was already
done. One of them did not know that ~/.ssh/known_hosts can be used by the server
under version 2 of the protocol. It is not his fault.

It is easy for a developer to document his work incrementally, while he knows
what he did. A newcomer has to read the code. How would you feel to have to read
the code of Linux, or at least bash, before you use it?

For some out this world reason, developers provided a long list of absurd
arguments in favour of the idea that the manual is very good as it is. The
effort spent by them and by me with this sterile argumentation would have made
the manual to be well organized at a high level already.

ssh developers prefer to have 105 code and 15 manual instead of 100 code and 100
manual. In the end, some documentation still has to be written, to provide
efficient transmission of information about the functionality of ssh. It is
extremely costly to transmit it verbally, on an individual basis, or by the
means of reading the code. In the meantime, we all waste the meager resources we
have.

Doru

Doru Georgescu wrote:
> How would you feel to have to read the code of Linux, or at least
> bash, before you use it?
The fact that I am invited to do so is why I love open source.


//Peter