Hi,
Get Anne Carasik's book UNIX Secure Shell, McGraw Hill,
ISBN:0-07-134933-2
It's a great book, buy it, you'll become the SSH expert in you company.
Carl
On 30-Mar-00 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.
------------------------------------------------------------------------
E-Mail: Carl J. Nobile <[EMAIL PROTECTED]>
Date: 31-Mar-00 Phone: 315-453-2912 Ex. 5336
Time: 08:59:14 Fax: 315-453-3052
Software Engineering Group -- AppliedTheory Corp.
224 Harrison Street, 6th Floor, Syracuse, NY 13202
------------------------------------------------------------------------
