The essence of SSH is its security. Public and private keys play an important role in this security. On first contact, the client and the server exchange public keys, the so-called host key. This host key proves the identity of the server to which a client is connecting. When connecting, the server sends its public key to the client. If this is the first time the client is connecting to this host, it replies with the message shown in Listing 18-1.
Listing 18-1. Establishing an SSH Session with an Unknown Host
The authenticity of host 'localhost' (127.0.0.1)' can't be established. RSA key fingerprint is 79:20:76:ed:93:7e:aa:d7:01:25:e5:d7:de:0b:76:87. Are you sure you want to continue connecting (yes/no)? yes
Only if the client trusts that this is really the intended host should the client answer yes to this request. As a result, the host is added to the file .ssh/known_hosts in the home directory of the user who initiated the SSH session. The next time the client connects to the same host, the client checks this known_hosts file to see whether the host is already known. This check is based on the public key fingerprint of the host, which is a unique number that is related to the public key of the host. Only if this number matches the name and public key of the server that the client is connecting to is the connection established. If both pieces of data don't match, it is likely that the host the client is connecting to is not the intended host; therefore, the connection will be refused.
Once you have established the identity of the server you want to connect to, you establish a secured channel between the client and server. To establish this secured channel, you use a session key. This is an encryption key that is the same on both the server and the client; it encrypts all the data sent between the two machines. The session key is negotiated between the client and the server based on their public keys. This negotiation, amongst others, determines the protocol that should be used. Session keys can use 3DES, Blowfish, or IDEA, for example.
After establishing this secured channel, the user on the client is asked for its credentials. If nothing is configured, this will be a prompt where the user is asked to enter a username and password. This, however, is not the only way it can be done, as you'll see in the "Using Key-Based Authentication" section. Alternatively, the user can authenticate with a public/private key pair, thus proving that the user really is the user who he says he is.
All this may sound pretty complicated. The nice part is that the user won't notice anything. The user just has to enter a username and password—that's all. If you want to go beyond simple password-based authentication, however, it is useful to understand what is happening.
Was this article helpful?