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.

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.

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.

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.

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.

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.

	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.

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.

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: