Chapter 13. SSH: Secure Network Operations

Contents

13.1. The OpenSSH Package
13.2. The ssh Program
13.3. scp—Secure Copy
13.4. sftp—Secure File Transfer
13.5. The SSH Daemon (sshd)—Server-Side
13.6. SSH Authentication Mechanisms
13.7. X, Authentication, and Forwarding Mechanisms
13.8. Configuring An SSH Daemon with YaST
13.9. For More Information

In networked environments, it is often necessary to access hosts from a remote location. If a user sends login and password strings for authentication purposes as plain text, they could be intercepted and misused to gain access to that user account without the authorized user knowing about it. This would open all the user's files to an attacker and the illegal account could be used to obtain administrator or root access, or to penetrate other systems. In the past, remote connections were established with telnet, which offers no guards against eavesdropping in the form of encryption or other security mechanisms. There are other unprotected communication channels, like the traditional FTP protocol and some remote copying programs.

The SSH suite provides the necessary protection by encrypting the authentication strings (usually a login name and a password) and all the other data exchanged between the hosts. With SSH, the data flow could still be recorded by a third party, but the contents are encrypted and cannot be reverted to plain text unless the encryption key is known. So SSH enables secure communication over insecure networks, such as the Internet. The SSH implementation coming with openSUSE is OpenSSH.

13.1. The OpenSSH Package

openSUSE installs the OpenSSH package by default. The ssh, scp, and sftp command line tools are then available as alternatives to telnet, rlogin, rsh, rcp, and ftp. In the default configuration, system access of a openSUSE system is only possible with the OpenSSH utilities, and only if sshd is running and the firewall permits access.

13.2. The ssh Program

Using the ssh program, it is possible to log in to remote systems and work interactively. It replaces both telnet and rlogin. The slogin program is just a symbolic link pointing to ssh. For example, log in to the host sun with the command ssh sun. The host then prompts for the password on sun.

After successful authentication, you can work on the remote command line or use interactive applications, such as YaST. If the local username is different from the remote username, log in using a different login name with ssh -l augustine sun or ssh augustine@sun.

Furthermore, ssh offers the possibility to run commands on remote systems, as known from rsh. In the following example, run the command uptime on the host sun and create a directory with the name tmp. The program output is displayed on the local terminal of the host jupiter.

ssh otherplanet "uptime; mkdir tmp"
Password:
1:21pm  up  2:17,  9 users,  load average: 0.15, 0.04, 0.02

Quotation marks are necessary here to send both instructions with one command. It is only by doing this that the second command is executed on sun.

13.3. scp—Secure Copy

scp copies files to a remote machine. It is a secure and encrypted substitute for rcp. For example, scp MyLetter.tex sun: copies the file MyLetter.tex from the host jupiter to the host sun. If the username on jupiter is different than the username on sun, specify the latter using the username@host format. The -l option has a different meaning for this command.

After the correct password is entered, scp starts the data transfer and shows a growing row of asterisks, simulating a progress bar. In addition, the program displays the estimated time of arrival to the right of the progress bar. Suppress all output with the -q option.

scp also provides a recursive copying feature for entire directories. The command scp -r src/ sun:backup/ copies the entire contents of the directory src including all subdirectories to the backup directory on the host sun. If this subdirectory does not exist it is created automatically.

The -p option tells scp to leave the time stamp of files unchanged. -C compresses the data transfer. This minimizes the data volume to transfer, but creates a heavier burden on the processor.

13.4. sftp—Secure File Transfer

The sftp program can be used instead of scp for secure file transfer. During an sftp session, you can use many of the commands known from ftp. The sftp program may be a better choice than scp, especially when transferring data for which the filenames are unknown.

13.5. The SSH Daemon (sshd)—Server-Side

To work with the SSH client programs ssh and scp, a server (the SSH daemon) must be running in the background, listening for connections on TCP/IP port 22. The daemon generates three key pairs when starting for the first time. Each key pair consists of a private and a public key. Therefore, this procedure is referred to as public key–based. To guarantee the security of the communication via SSH, access to the private key files must be restricted to the system administrator. The file permissions are set accordingly by the default installation. The private keys are only required locally by the SSH daemon and must not be given to anyone else. The public key components (recognizable by the name extension .pub) are sent to the client requesting the connection. They are readable for all users.

A connection is initiated by the SSH client. The waiting SSH daemon and the requesting SSH client exchange identification data to compare the protocol and software versions, and to prevent connections through the wrong port. Because a child process of the original SSH daemon replies to the request, several SSH connections can be made simultaneously.

For the communication between SSH server and SSH client, OpenSSH supports versions 1 and 2 of the SSH protocol. Version 2 of the SSH protocol is used by default. Override this to use version 1 of protocol with the -1 option.

When using version 1 of SSH, the server sends its public host key and a server key, which is regenerated by the SSH daemon every hour. Both allow the SSH client to encrypt a freely chosen session key, which is sent to the SSH server. The SSH client also tells the server which encryption method (cipher) to use. Version 2 of the SSH protocol does not require a server key. Both sides use an algorithm according to Diffie-Hellman to exchange their keys.

The private host and server keys are absolutely required to decrypt the session key and cannot be derived from the public parts. Only the contacted SSH daemon can decrypt the session key using its private keys. This initial connection phase can be watched closely by turning on verbose debugging using the -v option of the SSH client.

The client stores all public host keys in ~/.ssh/known_hosts after its first contact with a remote host. This prevents any man-in-the-middle attacks—attempts by foreign SSH servers to use spoofed names and IP addresses. Such attacks are detected either by a host key that is not included in ~/.ssh/known_hosts, or by the server's inability to decrypt the session key in the absence of an appropriate private counterpart.

It is recommended to back up the private and public keys stored in /etc/ssh/ in a secure, external location. In this way, key modifications can be detected and the old ones can be used again after reinstallation. This spares users any unsettling warnings. If it is verified that, despite the warning, it is indeed the correct SSH server, the existing entry for the system must be removed from ~/.ssh/known_hosts.

13.6. SSH Authentication Mechanisms

Now the actual authentication takes place, which, in its simplest form, consists of entering a password as mentioned above. The goal of SSH was to introduce secure software that is also easy to use. Because it is meant to replace rsh and rlogin, SSH must also be able to provide an authentication method appropriate for daily use. SSH accomplishes this by way of another key pair, which is generated by the user. The SSH package provides a helper program for this: ssh-keygen. After entering ssh-keygen -t rsa or ssh-keygen -t dsa, the key pair is generated and you are prompted for the base filename in which to store the keys.

Confirm the default setting and answer the request for a passphrase. Even if the software suggests an empty passphrase, a text from 10 to 30 characters is recommended for the procedure described here. Do not use short and simple words or phrases. Confirm by repeating the passphrase. Subsequently, you will see where the private and public keys are stored, in this example, the files id_rsa and id_rsa.pub.

Use ssh-keygen -p -t rsa or ssh-keygen -p -t dsa to change your old passphrase. Copy the public key component (id_rsa.pub in the example) to the remote machine and save it to ~/.ssh/authorized_keys. You will be asked to authenticate yourself with your passphrase the next time you establish a connection. If this does not occur, verify the location and contents of these files.

In the long run, this procedure is more troublesome than giving your password each time. Therefore, the SSH package provides another tool, ssh-agent, which retains the private keys for the duration of an X session. The entire X session is started as a child process of ssh-agent. The easiest way to do this is to set the variable usessh at the beginning of the .xsession file to yes and log in via a display manager, such as KDM or GDM. Alternatively, enter ssh-agent startx.

Now you can use ssh or scp as usual. If you have distributed your public key as described above, you are no longer prompted for your password. Take care of terminating your X session or locking it with a password protection application, such as xlock.

[Note]File Permissions for Host-Based Authentication

If the host-based authentication is to be used, the file /usr/lib/ssh/ssh-keysign or /usr/lib64/ssh/ssh-keysign should have setuid bit set, which is not the default setting in openSUSE. In such a case, set the file permissions manually. You should use /etc/permissions.local for this purpose, to make sure that the setuid bit is preserved after security updates of openssh.

13.7. X, Authentication, and Forwarding Mechanisms

Beyond the previously described security-related improvements, SSH also simplifies the use of remote X applications. If you run ssh with the -X option, the DISPLAY variable is automatically set on the remote machine and all X output is exported to the remote machine over the existing SSH connection. At the same time, X applications started remotely and locally viewed with this method cannot be intercepted by unauthorized individuals.

By adding the -A option, the ssh-agent authentication mechanism is carried over to the next machine. This way, you can work from different machines without having to enter a password, but only if you have distributed your public key to the destination hosts and properly saved it there.

Both mechanisms are deactivated in the default settings, but can be permanently activated at any time in the systemwide configuration file /etc/ssh/sshd_config or the user's ~/.ssh/config.

ssh can also be used to redirect TCP/IP connections. In the examples below, SSH is told to redirect the SMTP and the POP3 port, respectively:

ssh -L 25:sun:25 jupiter

With this command, any connection directed to jupiter port 25 (SMTP) is redirected to the SMTP port on sun via an encrypted channel. This is especially useful for those using SMTP servers without SMTP-AUTH or POP-before-SMTP features. From any arbitrary location connected to a network, e-mail can be transferred to the home mail server for delivery. Similarly, all POP3 requests (port 110) on jupiter can be forwarded to the POP3 port of sun with this command:

ssh -L 110:sun:110 jupiter

Both commands must be executed as root, because the connection is made to privileged local ports. E-mail is sent and retrieved by normal users in an existing SSH connection. The SMTP and POP3 host must be set to localhost for this to work. Additional information can be found in the manual pages for each of the programs described above and also in OpenSSH package documentation under /usr/share/doc/packages/openssh.

13.8. Configuring An SSH Daemon with YaST

The YaST SSHD Configuration module is not part of the default installation. To install it, start YaST and select Software+Software Management and search for yast2-sshd. Confirm the found item and install it.

To configure an sshd server with YaST run YaST and choose Network Services+SSHD Configuration. Then proceed as follows:

  1. On the General tab, select the ports sshd should listen on in the SSHD TCP Ports table. The default port number is 22. Multiple ports are allowed. To add a new port, click Add, enter the port number and click OK. To delete port, select it in the table, click Delete and confirm.

  2. On the General tab, select the features the sshd daemon should support. To disable TCP forwarding, uncheck Allow TCP Forwarding. Disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders. See Section 13.7, “X, Authentication, and Forwarding Mechanisms” for more information about TCP forwarding.

    To disable X forwarding, uncheck Allow X11 Forwarding. If this option is disabled, any X11 forward requests by the client will return an error. However users can always install their own forwarders. See Section 13.7, “X, Authentication, and Forwarding Mechanisms” for more information about X forwarding.

    In Allow Compression determine, whether the connection between the server and clients should be compressed. After setting these options, click Next.

  3. The Login Settings tab contains general login and authentication settings. In Print Message of the Day After Login determine, whether sshd should print message from /etc/motd when a user logs in interactively. If you want to disable connection of a user root, uncheck Permit Root Login.

    In Maximum Authentication Tries enter the maximum allowed number of authentication attempts per connection. RSA Authentication specifies whether pure RSA authentication is allowed. This option applies to SSH protocol version 1 only. Public Key Authentication specifies whether public key authentication is allowed. This option applies to protocol version 2 only.

  4. On the Protocol and Ciphers tab, determine which versions of the SSH protocol should be supported. You can choose to support version 1 only, version 2 only, or to support both SSH version 2 and 1.

    Under Supported Ciphers, all supported ciphers are listed. You can remove a cipher by selecting it in the list and clicking Delete. To add a cipher to the list, select it from the dropdown menu and click Add.

  5. Click Finish to save the configuration.

13.9. For More Information

http://www.openssh.com

The homepage of OpenSSH

man ssh_config

Manpage of OpenSSH SSH client configuration files

man ssh_config

Manpage of OpenSSH SSH daemon configuration file

man sshd

Manpage of OpenSSH daemon

man scp , man sftp , man slogin , man ssh , man ssh-add , man ssh-agent , man ssh-copy-id , man ssh-keyconvert , man ssh-keygen , man ssh-keyscan

Manpage of several binary files to copy (scp, sftp), login (slogin, ssh), and manage keys.