Event Sequence of an SSH Connection
A certain series of events helps protect the integrity of an SSH communication between two hosts.
First, a secure transport layer is created so that the client knows that it is communicating with the correct server. Then, the communication is encrypted between the client and server using a symmetric cipher.
Next, with a secure connection to the server in place, the client authenticates itself to the server without worrying that the authentication information may be compromised. OpenSSH on Red Hat Linux uses DSA or RSA keys and version 2.0 of the SSH protocol for authentication by default.
Finally, with the client authenticated to the server, several different services can be safely and securely used through the connection, such as an interactive shell session, X11 applications, and tunneled TCP/IP ports.
The entire connection process occurs with very little extra work required on the local system. In fact, in many respects, SSH works well because it is familiar to users who are accustomed to less secure connection methods.
In the following example, user1 on the client system is initiating an SSH connection to a server. The server's IP address is 10.0.0.2, but its domain name could be used instead. The login name of user1 on the server is user2. The ssh command is written as follows
[user1@machine1 user1]$ ssh user2@10.0.0.2The OpenSSH client will request the user's private key passphrase to decrypt the private key, which is used to perform authentication. However, the private key passphrase is not sent across the now secure connection between the client and server. Instead, the passphrase is used to unlock the id_dsa file and generate a signature, which it then sends to the server. If the server has a copy of the user's public key which can be used to verify the signature, the user is authenticated.
In this example, the user is using a DSA key (RSA keys, among many others, can also be used) and sees the following prompt
Enter passphrase for DSA key '/home/user1/.ssh/id_dsa'If the public key authentication fails for whatever reason (perhaps the passphrase is entered incorrectly or the authentication information does not already exist on the server), another type of authentication is usually attempted. In our example, the OpenSSH server allows user1 to be authenticated using user2's password because the signature sent did not match a public key stored by user2
user2@machine2's passwordWith a correctly entered password, the user is given a shell prompt. Of course, user2 must already have an account on the 10.0.0.2 machine for password authentication to work.
Last login/ Mon Apr 15 13/27/43 2001 from machine1
[user2@machine2 user2]$At this point, the user can interact with the shell in the same way as they might do with telnet or rsh, except that the communication is encrypted.
