Encryption

The public key encryption used in SSH authentication makes use of two keys: a public key and a private key. The public key is used to encrypt data, while the private key decrypts it. Each host or user has their own public and private keys. The public key is distributed to other hosts, who can then use it to encrypt authentication data that only the host's private key can decrypt. For example, when a host sends data to a user on another system, the host encrypts the authentication data with a public key, which it previously received from that user. The data can be decrypted only by the user's corresponding private key. The public key can safely be sent in the open from one host to another, allowing it to be installed safely on different hosts. You can think of the process as taking place between a client and a server. When the client sends data to the server, it first encrypts the data using the server's public key. The server can then decrypt the data using its own private key.

It is recommended that SSH transmissions be authenticated with public-private keys controlled by passphrases. Unlike PGP, SSH uses public-key encryption for the authentication process only. Once authenticated, participants agree on a common cipher to use to encrypt transmission. Authentication will verify the identity of the participants. Each user who intends to use SSH to access a remote account first needs to create the public and private keys along with a passphrase to use for the authentication process. A user then sends their public key to the remote account they want to access and installs the public key on that account. When the user attempts to access the remote account, that account can then use the user's public key to authenticate that the user is who they claim to be. The process assumes that the remote account has set up its own SSH private and public key. For the user to access the remote account, they will have to know the remote account's SSH passphrase. SSH is often used in situations where a user has two or more accounts located on different systems and wants to be able to securely access them from each other. In that case, the user already has access to each account and can install SSH on each, giving each its own private and public keys along with their passphrases.

Authentication

The mechanics of authentication in SSH version 1 and version 2 differ slightly. However, the procedure on the part of users is the same. Essentially, a user creates both public and private keys. For this, you use the ssh-keygen command. The user's public key then has to be distributed to those users that the original user wants access to. Often this is an account a user has on another host. A passphrase further protects access. The original user will need to know the other user's passphrase to access it.

SSH Version 1 uses RSA authentication. When a remote user tries to log in to an account, that account is checked to see if it has the remote user's public key. That public key is then used to encrypt a challenge (usually a random number) that can be decrypted only by the remote user's private key. When the remote user receives the encrypted challenge, that user decrypts the challenge with its private key. SSH Version 2 can use either RSA or DSA authentication. The remote user will first encrypt a session identifier using its private key, signing it. The encrypted session identifier is then decrypted by the account using the remote user's public key. The session identifier has been previously set up by SSH for that session.

SSH authentication is first carried out with the host, and then with users. Each host has its own host keys, public and private keys used for authentication. Once the host is authenticated, the user is queried. Each user has their own public and private keys. Users on an SSH server who want to receive connections from remote users will have to keep a list of those remote user's public keys. Similarly, an SSH host will maintain a list of public keys for other SSH hosts.

Creating SSH Keys with ssh-keygen

You create your public and private keys using the ssh-keygen command. You need to specify the kind of encryption you want to use. You can use either DSA or RSA encryption. Specify the type using the -t option and the encryption name in lowercase (dsa or rsa). In the following example, the user creates a key with the RSA encryption:

ssh-keygen -t rsa

The ssh-keygen command prompts you for a passphrase, which it will use as a kind of password to protect your private key. The passphrase should be several words long. You are also prompted to enter a filename for the keys. If you do not enter one, SSH will use its defaults. The public key will be given the extension .pub. The ssh-keygen command generates the public key and places it in your .ssh/id_dsa.pub or .ssh/id_dsa.pub file depending on the type of key you specified; it places the private key in the corresponding .ssh/id_dsa or .ssh/id_rsa.pub file.

If you need to change your passphrase, you can do so with the ssh-keygen command and the -p option. Each user will have their own SSH configuration directory, called .ssh, located in their own home directory. The public and private keys, as well as SSH configuration files, are placed here. If you build from the source code, the make install operation will automatically run ssh-keygen. Table 18-2 lists the SSH configuration files.

Authorized Keys

A public key is used to authenticate a user and its host. You use the public key on a remote system to allow that user access. The public key is placed in the remote user account's .ssh/authorized_keys file. Recall that the public key is held in the .ssh/id_dsa.pub file. If a user wants to log in remotely from a local account to an account on a remote system, they would first place their public key in the .ssh/authorized_keys file in the account on the remote system they want to access. If the user larisa on turtle.mytrek.com wants to access the aleina account on rabbit.mytrek.com, larisa's public key from /home/larisa/.ssh/id_dsa.pub first must be placed in aleina's authorized_keys file, /home/aleina/.ssh/authorized_keys. larisa could send the key or have it copied over. A simple cat operation can append a key to the authorized key file. In the next example, the user adds the public key for aleina in the larisa.pub file to the authorized key file. The larisa.pub file is a copy of the /home/larisa/.ssh/id_dsa.pub file that the user received earlier.

cat larisa.pub >>  .ssh/authorized_keys

Loading Keys

If you regularly make connections to a variety of remote hosts, you can use the ssh-agent command to place private keys in memory where they can be accessed quickly to decrypt received transmissions. The ssh-agent command is intended for use at the beginning of a login session. For GNOME, you can use the openssh-askpass-gnome utility, invoked by ssh-add, which allows you to enter a password when you log in to GNOME. GNOME will automatically supply that password whenever you use an SSH client.

Although the ssh-agent command enables you to use private keys in memory, you also must specifically load your private keys into memory using the ssh-add command. ssh-add with no arguments loads your private key from your .ssh/id_dsa or .ssh/id_rsa.pub file. You are prompted for your passphrase for this private key. To remove the key from memory, use ssh-add with the -d option. If you have several private keys, you can load them all into memory. ssh-add with the -l option lists those currently loaded.

ssh

With ssh, you can remotely log in from a local client to a remote system on your network operating as the SSH server. The term local client here refers to one outside the network, such as your home computer, and the term remote refers to a host system on the network to which you are connecting. In effect, you connect from your local system to the remote network host. It is designed to replace rlogin, which performs remote logins, and rsh, which executes remote commands. With ssh, you can log in from a local site to a remote host on your network and then send commands to be executed on that host. ssh is also capable of supporting X Window System connections. This feature is automatically enabled if you make an ssh connection from an X Window System environment, such as GNOME or KDE. A connection is set up for you between the local X server and the remote X server. The remote host sets up a dummy X server and sends any X Window System data through it to your local system to be processed by your own local X server.

The ssh login operation function is much like the rlogin command. You enter the ssh command with the address of the remote host, followed by a -l option and the login name (username) of the remote account you are logging into. The following example logs into the aleina user account on the rabbit.mytrek.com host:

ssh rabbit.mytrek.com -l aleina

You can also use the username in an address format with ssh, as in

ssh aleian@rabbit.mytrek.com

The following listing shows how the user george accesses the cecelia account on turtle.mytrek.com:

[george@turtle george]$ ssh turtle.mytrek.com -l cecelia
cecelia@turtle.mytrek.com's password:
Last login: Fri Sep 19 15:13:05 2003 from turtle.mytrek.com
[cecelia@turtle cecelia]$

A variety of options are available to enable you to configure your connection. Most have corresponding configuration options that can be set in the configuration file. For example, with the -c option, you can designate which encryption method you want to use, for instance, idea, des, blowfish, or arcfour. With the -i option, you can select a particular private key to use. The -c option enables you to have transmissions compressed at specified levels (see the ssh Man page for a complete list of options).

scp

You use scp to copy files from one host to another on a network. Designed to replace rcp, scp actually uses ssh to transfer data and employs the same authentication and encryption methods. If authentication requires it, scp requests a password or passphrase. scp operates much like rcp. Directories and files on remote hosts are specified using the username and the host address before the filename or directory. The username specifies the remote user account that scp is accessing, and the host is the remote system where that account is located. You separate the user from the host address with an @, and you separate the host address from the file or directory name with a colon. The following example copies the file party from a user's current directory to the user aleina's birthday directory, located on the rabbit.mytrek.com host:

scp party aleina@rabbit.mytrek.com:/birthday/party

Of particular interest is the -r option (recursive) option, which enables you to copy whole directories. See the scp Man page for a complete list of options. In the next example, the user copies the entire reports directory to the user justin's projects directory:

scp -r reports justin@rabbit.mytrek.com:/projects

In the next example, the user george copies the mydoc1 file from the user cecelia's home directory:

[george@turtle george]$ scp cecelia@turtle.mytrek.com:mydoc1  .
cecelia@turtle.mytrek.com's password:
mydoc1     0% |                             |   0 --:--
ETA
mydoc1   100% |*****************************|  17 00:00
[george@turtle george]$

From a Windows system, you can also use scp clients such as winscp, which will interact with Linux scp-enabled systems.

sftp and sftp-server

With sftp, you can transfer FTP files secured by encryption. sftp uses the same commands as ftp (see Chapter 21). This client, which works only with ssh version 2, operates much like ftp, with many of the same commands. Use sftp instead of ftp to invoke the sftp client.

sftp ftp.redhat.com

To use the sftp client to connect to an FTP server, that server needs to be operating the sftp-server application. The ssh server invokes sftp-server to provide encrypted FTP transmissions to those using the sftp client. The sftp server and client use the SSH File Transfer Protocol (SFTP) to perform FTP operations securely.