please decrypt your manuals
Keisial
keisial at gmail.com
Mon Apr 19 07:00:18 EST 2010
Doru Georgescu wrote:
>>> 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? :-)
>
Yes. sshd_config(5)
> IgnoreUserKnownHosts
> Specifies whether sshd(8) should ignore the user's
> ~/.ssh/known_hosts during RhostsRSAAuthentication or
> HostbasedAuthentication.
> The default is ``no''.
> RhostsRSAAuthentication
> Specifies whether rhosts or /etc/hosts.equiv
> authentication together with successful RSA host authentication is
> allowed. The
> default is ``no''. This option applies to protocol
> version 1 only.
And seems I was wrong since I missed:
> HostbasedAuthentication
> Specifies whether rhosts or /etc/hosts.equiv
> authentication together with successful public key client host
> authentication is
> allowed (host-based authentication). This option is
> similar to RhostsRSAAuthentication and applies to protocol version
> 2 only.
> The default is ``no''.
>>> 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.
>
Right. That's why I said "someone", not "the server".
>> - 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.
>
Yes?
The server says: I am server owning this private key Foo, and I prove it
by signing this token. The human is used to confirm it is really the server.
More information about the openssh-unix-dev
mailing list