With more and more computers installed in networked environments, it often
becomes necessary to access hosts from a remote location. This normally means
that a user sends login and password strings for authentication purposes. As
long as these strings are transmitted as plain text, they could be
intercepted and misused to gain access to that user account without the
authorized user even knowing about it. Apart from the fact that this would
open all the user's files to an attacker, the illegal account could be used
to obtain administrator or
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 flavor that comes with SUSE Linux is OpenSSH.
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. In the default configuration, system access of a SUSE Linux system is only possible with the OpenSSH utilities and only if 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
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, you can log in using a different login
name with ssh
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 executed on sun.
scp copies files to a remote machine. It is a
secure and encrypted substitute for rcp. For
sun: copies the file
from the host earth to the host sun. If the username
on earth is different than the username 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. Suppress all output by
giving the option
scp also provides a recursive copying feature for
entire directories. The command scp
sun:backup/ copies the entire contents of the directory
src including all subdirectories to
backup directory on
the host sun. If this subdirectory does not exist yet, it is
-p tells scp
to leave the time stamp of files unchanged.
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
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
.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. To continue using
version 1 after an update, follow the instructions in
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 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-Helman 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
-v of the SSH
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
~/.ssh/known_hosts or by the server's
inability to decrypt the session key in the absence of an appropriate
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 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 for the
system must be removed from
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. 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
-t rsa or
-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
-p -t rsa or
-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
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
usessh at the beginning of the
.xsession file to
yes and log in via
a display manager, such as KDM or
XDM. Alternatively, enter
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
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 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
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
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 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