SSH (Secure Shell) lets a user connect from one computer to another over a network and execute commands, transfer files, or get a command prompt. It uses strong cryptography to protect the data in transit and also to authenticate both the user and the server. SSH serves as a drop-in replacement for TELNET, FTP, rlogin, rsh, and rcp, none of which use strong cryptography by default.
SSH consists of both a client program, ssh, which the user runs directly, and a server program, sshd, that handles incoming requests on the server.
The ITSO currently recommends the client from ssh.com. Since support for the non-commercial version of this client will soon be discontinued, the ITSO is currently evaluating other options, such as PuTTY.
SSH server products are also available for Windows from ssh.com and others, but the ITSO has not evaluated any of them.
The ITSO recommends OpenSSH, which offers a client and server for most Unix platforms.
Currently, much of the communication on computer networks is done without encryption. As a consequence, anyone who has access to any computer on the network can listen in. This technique is used by attackers, curious administrators, employers, criminals, industrial spies, and governments. Some networks leak off enough electromagnetic radiation that data may be captured even from a distance.
When you log in to most systems, your password goes in the network in plain text. Any listener can then use your account to do any evil he likes. Many incidents have been encountered worldwide where a cracker starts a program on a workstation without the owner's knowledge just to listen to the network and collect passwords. These so-called sniffing programs are available on the Internet and can be built by a competent programmer in a few hours.
Furthermore, it is possible to hijack connections on the network. In other words, an intruder can enter in the middle of an existing connection and start modifying data in both directions. This technique can, for example, be used to insert new commands in sessions authenticated by one-time passwords. Consequently, no security method based on purely authenticating the user is safe. Moreover, route spoofing can be used to bring almost any connection on the Internet to a location where it can be attacked.
Encryption and cryptographic authentication and integrity protection are required to secure networks and computer systems. SSH uses strong cryptographic algorithms to achieve these goals. Ease of use is critical to the acceptance of a piece of software. SSH attempts to be easier to use than its insecure counterparts (TELNET, FTP, etc.). SSH is available for Windows and most Unix platforms.
The software consists of a number of programs.
ssh is the program users normally use, and is initiated as:
% ssh host.example.edu % ssh host.example.edu uptime
The first form authenticates the user and then opens a new shell on the remote computer (host.example.edu in this example). The latter form executes the uptime command on the remote computer.
When started, ssh connects to the sshd service on the server computer, verifies that the server really is the computer to which it wanted to connect, exchanges encryption keys (in a manner which prevents an outside listener from getting the keys), and performs authentication using public key authentication or conventional password based authentication. The server then (normally) allocates a pseudo-terminal and starts an interactive shell or user program.
The TERM environment variable (describing the type of the user's terminal) is passed from the client side to the remote side. Also, terminal modes are copied from the client side to the remote side to preserve user preferences (e.g., the erase character).
If the DISPLAY variable is set on the client side, the server will create a dummy X server and set DISPLAY accordingly. Any connections to the dummy X server will be forwarded through the secure channel to the real X server. An arbitrary number of X programs can be started during the session, and starting them does not require anything special from the user. (Note that the user must not manually set DISPLAY because then it would connect directly to the real display instead of going through the encrypted channel). This behavior can be disabled in the configuration file or by giving the -x option to the client.
Arbitrary TCP/IP ports can be forwarded over the secure channel. The program then creates a port on one side, and whenever a connection is opened to this port, it is passed over the secure channel, where a connection will in turn be made to a specified host:port pair. Port forwarding must always be explicitly requested and cannot be used to forward privileged ports (unless the user is root). It is possible to specify automatic forwards in a per-user configuration file, for example to make electronic cash systems work securely.
If there is an authentication agent on the client side, any connection to it will be automatically forwarded to the server side.
For more information, see the manual pages for ssh(1), sshd(8), scp(1), ssh-keygen(1), ssh-agent(1), and ssh-add(1).
X11 forwarding serves two purposes: it is a convenience to the user because there is no need to set the DISPLAY variable, and it provides encrypted X11 connections.
X11 forwarding works as follows. The client extracts Xauthority information for the server. It then creates random authorization data and sends it to the server. The server allocates an X11 display number and stores the random Xauthority data for this display. Whenever an X11 connection is opened, the server forwards the connection over the secure channel to the client. The client parses the first packet of the X11 protocol, substitutes real authentication data for the random data (if the random data matched), and forwards the connection to the real X server.
If the display does not have Xauthority data, the server will create a Unix-domain socket in /tmp/.X11-unix and use it as the display. No authentication data is forwarded in this case. X11 connections are again forwarded over the secure channel. To the X server the connections appear to come from the client side.
One should be careful not to use xon, xstart, or similar scripts that explicitly set DISPLAY to start X sessions on a remote system because connections won't use the secure channel. The recommended way to start a shell on a remote computer (host.example.edu in these examples) is:
% xterm -e ssh host.example.edu
The recommended way to execute an X11 application on a remote machine is:
% ssh -n host.example.edu emacs &
If you need to type a password or passphrase to authenticate to the remote computer, you may use:
% ssh -f host.example.edu emacs
It's important to understand that SSH can be used to tunnel connections from one host to another. This means that a user with SSH access to a system can use that system as a proxy, making their connection appear to have originated from the host running the SSH server. In order to avoid this situation, the ITSO recommends the following setting for the sshd.
AllowTcpForwarding no
This value can be set in the sshd_config of the server.