I bought it and I think the book is crap. It may be one of the few books on
the subject but I found it very confusing and unclear in many parts of the
book. I really wonder if the author knew the subject before she started
writing about it - either that or she has a hard time making her ideas
clear. I think reading the man pages would be a better idea and it would
save you money.
David
"Carl J. Nobile" wrote:
> 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
> ------------------------------------------------------------------------
