SUSE LINUX installs the package OpenSSH by default. The programs ssh, scp, and sftp are then available as alternatives to telnet, rlogin, rsh, rcp, and ftp.

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, you can 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 user name is different from the remote user name, you can 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 earth.

ssh otherplanet "uptime; mkdir tmp" 
tux@otherplanet's 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 likewise 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 earth to the host sun. If the user name on earth is different from the user name on sun, specify the latter using the username@host format. There is no -l option for this command.

After the correct password is entered, scp starts the data transfer and shows a growing row of asterisks to simulate a progress bar. In addition, the program displays the estimated time of arrival to the right of the progress bar. All output can be suppressed by giving the option -q.

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 yet, it is created automatically.

The option -p 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 familiar commands as known from ftp. The sftp program may be a better choice than scp, especially when transferring data for which the file names are unknown beforehand.

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 consist 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. A newly installed SUSE LINUX system defaults to version 2. If you want to keep using version 1 after an update, follow the instructions in /usr/share/doc/packages/openssh/README.SuSE. This document also describes how an SSH 1 environment can be transformed into a working SSH 2 environment with just a few steps.

When using version 1 of SSH, the server sends its public host key, as well as 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 over 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-Helman instead 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 SSH daemon contacted can decrypt the session key using its private keys (see man /usr/share/doc/packages/openssh/RFC.nroff). This initial connection phase can be watched closely by turning on the verbose debugging option -v of the SSH client.

Version 2 of the SSH protocol is used by default. Override this to use version 1 of the protocol with the -1 switch. 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 backup 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 a 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 regarding this 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 a secure software that is also easy to use. As 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 file name in which to store the keys:

Enter file in which to save the key (/home/tux/.ssh/id_rsa):

Confirm the default setting and answer the request for a passphrase. Even if the software suggests an empty passphrase, a text from ten to thirty 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.

Enter same passphrase again: 
Your identification has been saved in /home/tux/.ssh/id_rsa 
Your public key has been saved in /home/tux/.ssh/id_rsa.pub. 
The key fingerprint is:
79:c1:79:b2:e1:c8:20:c1:89:0f:99:94:a8:4e:da:e8 tux@sun

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 XDM. 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.

All the relevant changes that resulted from the introduction of version 2 of the SSH protocol are also documented in the file /usr/share/doc/packages/openssh/README.SuSE.

Beyond the previously described security-related improvements, SSH also simplifies the use of remote X applications. If you run ssh with the option -X, the DISPLAY variable is automatically be 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 option -A, 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 system-wide 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 earth

With this command, any connection directed to earth 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 earth can be forwarded to the POP3 port of sun with this command:

ssh -L 110:sun:110 earth

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 the files under /usr/share/doc/packages/openssh.