I just wrote up a howto on setting up hostbased (rsh-style +
rsa key verification) authentication that should be added to the FAQ
presently. Try checking the FAQ again:
http://www.employees.org/~satch/ssh/faq
--
Gregor Mosheh
[EMAIL PROTECTED]
Systems Admin, Humboldt Internet
707.825.4638
On Thu, 30 Mar 2000, asosin wrote:
> Does anyone understand how the Client to Server authentication is
> performed ?
>
> Below I have included all the information I was able to gather from the
> Internet and the MAN pages Unix, however it still does not sound correct.
> If someone knows how it works, please add in some comments to clear up my
> confusion.
>
>
> Here is where my confusion is:
> a). In # 4 the MAN page said that the Server send it's Public key and the
> Clients Public key to the Client.
> However what is there to prevent a fake Server from sending that same
> Public key and the Clients
> Public key to the client ? If someone has an account on that Server then
> they can easily get the Client and Server Public key, even if someone is
> using a sniffer they can get this information since it doesn't appear to be
> encrypted in #4.
> b). In # 6 the client then generates a random 256 bit number which is
> encrypted using the Clients
> Public key and the Server Public key. If that is the case how is the
> Server suppose to decrypt the random
> number since it would only know the Server Private key and not the Clients
> Private key ? The idea of using RSA is
> that if you encrypt something with a public key, then you are suppose to be
> able to decrypt it using a private key or vice versa.
>
> If you know the answer please reply, or type out the steps in a easy to
> understand format.
>
> ------------------------------------------------
> 1. First on the client side, a user types: ssh
> servername.ca
> In Unix\Linux the client computer reads the ~user/.ssh/config and the
> /etc/ssh/ssh_config files.
> (Each client has a 1024 bit key to identify itself, and each server key is
> 768 bits, and this RSA key is
> regenerated by the Server every hour it is used or when the daemon starts
> and kept in memory not on HD.)
>
> 2. The client that wants to establish a connection does this using port
> 22, but first the Server checks whether the connection came from an
> authorized IP#, and if so then it responds to the client with a "Version
> Identification string."
>
> 3. The client then sends it's own "Version" back to the Server and if
> either side fails then the connection is terminated.
>
> 4. The Server then uses the RSA Cipher algorithm and sends the following
> info to the client:
> Server Public Key + Client Public Key (Stored in the Server's
> ssh_known_hosts file.)
>
> /etc/ssh_known_hosts Everyone = Read, and Root = Write
> - contains the clients public key.
>
> /etc/ssh_host_key Everyone = No access, and Root = Write
> - contains Server Private RSA key.
>
> /etc/ssh_host_key.pub Everyone = Read
> - contains the Server Public RSA key.
>
> /etc/ssh_random_seed Everyone = No access, and Root = Write
> - contains the session 256 bit random number.
>
> Note that the Client Public key is already on the Server since it was
> placed there during the very first
> connection to the Server.
>
> 5. Now the client check the Server Public Key it received against the one
> in it's own list
> of ssh_known_hosts, and if it's a match then we know it's the same
> Server. (Prevents Spoofing ?)
> Also during this transfer the sshd of the Server included a 64bit of random
> data, a "cookie" which the client must then include in its reply to the
> Server.
>
> 6. The client then generates a 256 bit random number "Session key" and
> encrypts it using the client public key and the Server public key. This
> encrypted number is then send to the server which only the Server can
> decrypt using it's private key, and the cookie is also included in the
> reply so the Server knows it is still talking to the same computer.
>
> 7. Now both sides use this random number as a session key to encrypt all
> the communication during
> the connection. The rest of the session is encrypted using the default
> cypher IDEA.
>
> 8. In the final step the client tries to authenticate itself using password
> authentication. The .rhosts
> authentication is disabled by default on the Server, since it is insecure.
> The Server can be
> configured using command line options which will override the config file.
>
