please decrypt your manuals

[Doru Georgescu]

--- On Sun, 4/18/10, Keisial <keisial at gmail.com> wrote:

> From: Keisial <keisial at gmail.com>
> Subject: Re: please decrypt your manuals
> To: "Doru Georgescu" <headset001 at yahoo.com>, openssh-unix-dev at mindrot.org
> Date: Sunday, April 18, 2010, 5:00 PM
> 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.

I said that I am not sure about /etc/ssh/ssh_known_hosts. The sshd_config manual does mention ~/.ssh/known_hosts, as I said. 

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

I suppose that the server encrypts the token using his private host key, and sends this message to the client, who unencrypts it using the server's public host key and recognizes the token. 

All is very fine, but on what side are you? Do you claim that the ssh manuals fully specify the /etc/ssh/ssh_host_key.pub, the /etc/ssh/ssh_known_hosts and the ~/.ssh/known_hosts files mentioned in the SSH_KNOWN_HOSTS FILE FORMAT section of the sshd manual, or not? By full specification I mean: do they say where do those files reside, on the server, or on the client, on the authorized machine, or on the authorizing machine? Well? 

Doru