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.2 |
The 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 password: |
With 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.
Other SSH tools, scp and sftp,
work in a similar way as the insecure rcp and
ftp, respectively. See the Official Red Hat Linux Customization Guide for
instructions and examples for using these and other SSH commands.
