SSH (secure shell) is a program for logging into remote hosts, executing commands remotely, and moving files from one machine to another. It is intended to:
- replace telnet, rlogin, rsh, and rcp (SSH2 and OpenSSH have a replacement for ftp called sftp);
- provide strong authentication and secure encrypted communications between two untrusted hosts over an insecure network; and
- enable secure X connections and secure forwarding of arbitrary TCP connections.
rsh, rlogin, and rcp etc. are vulnerable to certain types of security intrusion because they rely on a trusted host mechanism for authentication. For example, if an intruder can gain write access to a user's .rhosts file on a remote system, he or she can modify its contents to allow them access to all of the hapless user's files, without even knowing the password. SSH has additional layers of authentication on top of the host-based one (e.g. use of the .rhosts file), which will prevent the interloper from logging into the remote machine even if the .rhosts file is compromised. Use of the "r" programs, as well as telnet, also makes it possible for a user's password to be detected. The use of so-called sniffer programs will allow an eavesdropper to catch each and every packet on the local network. With access to the raw packet traffic and knowledge of the protocols being used, these sniffer programs can discover your password because it is transmitted in the clear. Interception of cleartext passwords and other forms of data is impossible with SSH because all communication is encrypted over the network.
Important Notice to Users of the TACC Systems:
There are severe vulnerabilities associated with the use of rcp, rsh, rlogin, etc. that can compromise the security of any machine that implements these means of access. To safeguard TACC resources from malicious attacks and to enhance network security, all users are encouraged to employ the entire suite of SSH tools (ssh-client programs like scp, sftp, etc.) to establish connection to the TACC machines. Beginning October 1 of 2001, network access to the supercomputers using the "r" commands, as well as telnet and ftp, will be gradually phased out. There is as yet no specific date past which the "r" commands will be completely disabled, but it cannot be overemphasized that there is an urgent need from a security standpoint to discontinue the use of these insecure commands as soon as possible. For the mutual benefit of all parties concerned, users are strongly urged to migrate to SSH as soon as possible.
Three implementations of the SSH software currently exists: SSH1, SSH2, and OpenSSH. Released in 1995, SSH1 is the brainchild of Tatu Ylonen and supports the SSH-1 protocol (also developed by Ylonen). SSH2 was released three years later and is based on the superior (more secure) SSH-2 protocol. The difference between the two protocols are enormous, and consequently, SSH1 and SSH2 are not compatible. OpenSSH is an implementation of SSH from the OpenBSD project, and provides support for both SSH-1 and SSH-2 protocols. Because of differences in implementation (note that session rekeying is now supported in the latest version of OpenSSH), there are certain interoperability problems between OpenSSH and SSH1/SSH2, although most of them are easily addressed.
Although SSH1 is still the more popular implementation, it is based on protocol 1, which has several security holes and is no longer under development. In addition, the availability of free implementations of SSH2 and OpenSSH is bound to encourage its usage among more people.
The machines at TACC support both SSH1 and OpenSSH implementations. Currently, the default SSH server supports only protocol 1, but a move towards default support for protocol 2 is imminent. TACC users are thereby encouraged to download the SSH2 or OpenSSH implementations of ssh-client programs.
SSH is available from a variety of free and commercial sources:
UNIX platforms
- OpenSSH is a free version of the SSH suite of programs developed by the OpenBSD project. It includes ssh-client programs ssh, scp, sftp, and other basic utilities like ssh-agent, ssh-add, ssh-keygen, and sftp-server. Sshd (the ssh-server) is included as well in the package, for enabling SSH access to the local workstation from outside. OpenSSH supports both SSH-1 and SSH-2 protocols.
- The ssh source code for UNIX is available free of charge for non-commercial use from ftp://ftp.cs.hut.fi/pub/ssh; visit the ssh home page at http://www.ssh.fi for more information. You will need a C compiler to build the SSH client and server. This version of SSH has been tested and verified correct on most versions of the UNIX operating system. Commercial versions that include patent licenses are available from Data Fellows. Both SSH-1 and SSH-2 protocols are supported.
- The SecureCRT terminal emulation package for Windows from Van Dyke Technologies, Inc. has an excellent implementation of ssh version 1.5 protocol (SSH-1). One can download the software and try it out for free for 30 days before purchasing.
- www.ssh.com offers free SSH2 client programs for academic use only. The suite includes sftp (a secure version of ftp implementing the SSH-2 protocol) and ssh, which supports both SSH-1 and SSH-2 protocols. Registration is required to download the software (click here to go to the download site).
- A commercial version of SSH named F-Secure SSH for Windows is available from Data Fellows. It runs on all versions of Windows (3.11, 95, NT) using any WINSOCK-compatible TCP/IP stack and provides support for both SSH-1 and SSH-2 protocols.
- A free SSH client for Windows, ttssh, is available from this site in Australia. It is implemented as an extension DLL for Teraterm Pro, a free terminal emulator/telnet client for Windows. Ttssh provides implementations of SSH1 and SSH2.
- PuTTY is a free implementation of Telnet and SSH for Win32 platforms, as well as providing an xterm terminal emulator. It is written and maintained primarily by Simon Tatham. Version 0.50 supports the SSH-2 protocol.
- NiftyTelnet 1.1 SSH r3 is an enhanced version of Chris Newman's NiftyTelnet 1.1 application which adds support for encrypted terminal sessions using the SSH (Secure Shell) protocol. It is available at http://www.lysator.liu.se/~jonasw/freeware.html.
- MacSSH is a modified version of BetterTelnet and provides SSH2 implementation for Mac clients. You can find it at http://pro.wanadoo.fr/chombier/.
SSH Installation for UNIX or LINUX
These instructions are very general, by no means detailed nor complete, and are meant only for novice users with no prior experience in installing software on their UNIX workstations.
For UNIX users:
- If your group/department has a system administrator, have him/her do it. This is the best option if you have a sys admin who is not swamped with work at the moment. No such luck? Proceed to step 2 to install SSH yourself.
- Ftp the tar file or compressed tar file (ends in .tar.gz extension) from any of the ftp sites given in the previous section, to the /tmp area of your workstation or any other scratch directory.
- If you downloaded the compressed tarfile, unzip and extract using:
in the directory where you want to do the installation from (/tmp is recommended). Replace the "*" with the name of the SSH distribution.gunzip -c *.tar.gz | tar xvf -
If you downloaded the tarfile, extract the source files with:tar xvf *.tar - Cd to the directory created by untarring the file, usually called
"ssh-< version-number >", where the first number in <
version-number > denotes the protocol number. Read the file called
INSTALL in this top-level directory, for the detailed
installation instructions. Typically, you will be asked to do the
following:
but in some cases, you might have to change some parameters in the make include file. In any event, make sure to read the INSTALL file carefully, it will tell you what to do../configure ./make ./make install - If all goes well, you should have a full functioning suite of ssh client programs. But your shell should be able to find the program before it can run it. Check if ssh is in your path by executing "which ssh" if using csh, or "type ssh" in the Bourne shell. These commands should return the path to the ssh program. In case you get a "command not found", typing rehash should allow the shell to recognize recently created executables. If problems still persist, you need to review the installation log files to check where the executables were placed.
- If installing the ssh-server, proceed as in steps 2-5. After the install:
- Start the ssh server daemon sshd to allow connections to your machine from the outside world.
- Include sshd as one of the services started at boottime.
For Linux users:
One can either download a gzipped tarfile of the SSH source or a packaged form of the binaries (i.e. pre-compiled SSH). In the former case, follow the instructions outlined for UNIX installation. In the latter case, each flavor of Linux (e.g. Suse, Debian, RedHat, SlackWare, etc.) has its own packaging format. Only the RedHat rpm installation is going to be discussed here:
- Download the latest version of the ssh program rpm's from www.redhat.com, rpmfind.net, or one of ReadHat's mirror sites. A minimum ssh-client installation (i.e. you can only ssh to a remote host from your workstation, not into) requires two rpm files: openssh-2.5.2p2-1.7.2.i386.rpm and openssh-clients-2.5.2p2-1.7.2.i386.rpm. To be able to connect to your workstation from another machine, you will need to pick up the ssh-server rpm file, openssh-server-2.5.2p2-1.7.2.i386.rpm.
- As root, unpack and install the rpms using the command:
rpm -Uvh openssh* The install is successful if ithe rpm command does not return anything.
- Verify that your shell can find the executables using "which ssh" in csh or "type ssh" in the Bourne shell. If you get a "command not found," type rehash, and this should change the shell lookup tables to incorporate the path to the new executables.
- If installing the ssh-server, you have to start the sshd
daemon in the current session. As root, execute:
/sbin/service sshd start To ensure that the ssh server daemon gets started at boot time, you can either go to the "control service/activity" menu of the linuxconf interface or run the chkconfig command, as root in both cases. Here's how to do the latter:
/sbin/chkconfig --add sshd
The discussions in this section are meant for beginners and are not meant to be comprehensive nor in-depth. For a more thorough discussion, please refer to A Detailed Look at SSH.
In very general terms, request of a service from a remote host (e.g. login connection, execution of commands, file transfers) using SSH can be divided into two broad parts:
- Establishment of a secure connection between the SSH client and
server
SSH sets up a secure connection between the client and server to protect the privacy of any communication that occurs over the network. Privacy refers to protecting the secrecy of the data from being interpreted by an attacker who might be listening in on the connection. To ward off such threats, SSH encrypts all the data transmitted between client and server using strong encryption algorithms. In the present context, a secure connection not only entails privacy protection of all transmitted data, but also guards against data tampering in what is known as integrity checking.
A certain amount of preparation is needed prior to the establishment of a secure connection. This multistep process involves:
- disclosure between the client and server of supported SSH protocol versions;
- authentication of the server to the client;
- agreement between client and server regarding encryption, compression, and authentication methods to be used for the session; and
- generation of the symmetric key for encryption (also called the session key).
A secure connection is set up if all the preceding steps complete successfully. Henceforth, all communication between client and server will be encrypted for secrecy and checked to guard against corruption or deliberate tampering.
- Authentication of the client to the server
The client then attempts to authenticate itself to the server using any of the following methods until one succeeds.
Under the SSH-1 protocol, six authentication methods are tried in the following order:
- Kerberos
- Rhosts
- RhostsRSA
- Public-Key
- TIS
- User password
while the SSH-2 protocol only supports three:
- Public-key
- RhostsRSA
- User password
Details on these different authentication procedures, as well as the different components of SSH, are presented on A Detailed Look Inside SSH.
To connect to a remote SSH server, all that's needed is a working implementation of the SSH client on the local workstation and an account on the host where the server is running. These step-by-step instructions enable SSH access to a remote system from a local workstation:
- Use the ssh program to request a login connection to a
remote machine:
teaparty> whoami madhatter teaparty> ssh alice@wonderland.utexas.edu alice@wonderland.utexas.edu's password: not echoed ------------------------------ Welcome to WonderLand! ------------------------------wonderland>In the preceding example and in succeeding ones, user madhatter on teaparty logs into machine wonderland.utexas.edu as user alice. Provided the account for alice exists on wonderland and madhatter knows the password, then the SSH server on wonderland will permit the login request.
Password authentication is convenient and easy to use for first-time SSH users, but it has its pitfalls. First of all, typing and retyping passwords can get cumbersome, especially when establishing multiple login sessions. Secondly, password authentication is less secure than public-key authentication because the password is transmitted over the network, albeit in encrypted form. It is invulnerable to being decoded while in transit, but may be readily detected when it reaches the server, if that machine has been compromised.
The next steps are optional, but recommended for convenience and to ensure maximum security when running SSH.
- Public-key authentication provides a safer means for the user to be
authenticated on the SSH server. Public-key cryptography is used to verify
the user's identity, and does not involve the transmission of any sensitive
information over the network. To start using public-key authentication, first
a user must generate the public and private keypairs on the workstation
running the SSH client. The client program
ssh-keygenis used for this purpose:teaparty> ssh-keygen -t rsa1 Initializing random number generator...
Generating p: ...++ (distance 868)
Generating q: ...++ (distance 42)
Computing the keys...
Testing the keys...
Key generation complete.
SSH2 uses DSA-based public-key cryptography (OpenSSH can run either RSA or DSA when using protocol version 2), so ssh-keygen has to be run as follows:
teaparty> ssh-keygen -t dsa It is perfectly acceptable to generate two sets of keypairs corresponding to the two SSH protocols. Next, ssh-keygen will ask for the name of the file in which the private key will be stored with a prompt similar to this:
On SSH2, the prompt is different:
Enter file in which to save the key (/home/madhatter/.ssh/id_dsa): Press <RETURN> so that the private key is stored in the default location. Next, the user must type a passphrase (it's like a password but isn't limited to eight characters):
Enter passphrase: not echoed
Enter the same passphrase again: not echoedFor security reasons, the private key is stored in encrypted form. The passphrase is necessary to decrypt the private key for later use in user authentication to the SSH server. ssh-keygen finishes its work by displaying messages similar to these:
Your identification has been saved in /home/madhatter/.ssh/identity.
Your public key is:
several lines of digits
Your public key has been saved in /home/madhatter/.ssh/identity.pub.SSH2 will issue a similar message but with the filenames replaced by id_dsa for the private key and id_dsa.pub for the public key.
- Check the contents of the
$HOME/.sshdirectory, viz.:teaparty> ls -l .ssh total 56 -rw-rw-r-- 1 madhatter madhatter 79 Sep 6 09:58 config -rw------- 1 madhatter madhatter 736 Sep 6 07:45 id_dsa -rw-r--r-- 1 madhatter madhatter 620 Sep 6 07:45 id_dsa.pub -rw------- 1 madhatter madhatter 544 Aug 3 08:54 identity -rw-rw-r-- 1 madhatter madhatter 348 Jan 9 2001 identity.pub -rw------- 1 madhatter madhatter 16398 Sep 10 08:57 known_hosts -rw-r--r-- 1 madhatter madhatter 5909 Sep 10 08:55 known_hosts2 -rw------- 1 madhatter madhatter 512 Aug 9 16:41 random_seed
$HOME/.ssh/identity and $HOME/.ssh/id_dsa contain the RSA and DSA private keys and should be accessible only by the user. $HOME/.ssh/random_seed contains the seed for the random number generator used by SSH and should be kept private, accessible only by the user. The third file, $HOME/.ssh/identity.pub and $HOME/.ssh/id_dsa.pub hold the RSA and DSA public keys and can be read by anyone.
- Next, the user must login to the remote host and create a .ssh
directory, if there isn't one. The RSA public key
(.ssh/identity.pub) from the workstation should be appended to
the .ssh/authorized-keys file in the user's home directory on
the remote machine. If the server supports the SSH-2 protocol, the
.ssh/id_dsa.pub must be appended as well to the
.ssh/authoried_keys2 file. The following example provides an
illustration:
teaparty> whoami madhatter teaparty> ssh -l alice wonderland.utexas.edu Password: not echoed
-------------------------------- Welcome to WonderLand! -------------------------------- wonderland> pwd /home/alice wonderland> mkdir .ssh wonderland> scp madhatter@teaparty.utexas.edu:.ssh/identity.pub rsakey Password: not echoed
wonderland> scp madhatter@teaparty.utexas.edu:.ssh/id_dsa.pub dsakey Password: not echoed
wonderland> touch .ssh/authorized_keys wonderland> touch .ssh/authorized_keys2 wonderland> cat rsakey >> .ssh/authorized_keys wonderland> cat dsakey >> .ssh/authorized_keys2 wonderland> exit teaparty>The scp command provides a secure way of transferring files across the network and is included in most SSH-client distributions. Consult the scp man page for more details on its implementation and use. Note that the touch commands in the previous example are needed to create .ssh/authorized_keys and .ssh/authorized_keys2. Otherwise, the append will not work (as implemented by the cat commands in the above example). If these files exist, then it is not necessary to touch them.
When madhatter logs back into wonderland as alice using SSH, he will be prompted for a passphrase instead of his password:
teaparty> ssh alice@wonderland.utexas.edu Please enter your passphrase for .ssh/id_dsa: not echoed
-------------------------------- Welcome to WonderLand! -------------------------------- wonderland>Password and public-key authentication differ in many ways but one distinction deserves mention. In password authentication, there is a one-to-one mapping of the username on the remote machine to his or her password, as maintained by the operating system in a system-wide database (in file /etc/passwd). In contrast, the use of public-keys require that the user make this association manually by appending his/her key to the authorized_keys file(s) in the remote machine. Additionally, there may be a many-to-one mapping of keys to user, where each public key in the authorized_keys file corresponds to different means of accessing the account on the remote machine. To clarify, suppose madhatter is known as user whiterabbit at rabbithole.utexas.edu that logs in as alice at wonderland. Public key authentication for user whiterabbit will only be possible if his public keys are installed in alice's authorized_keys file(s) in wonderland.
- Repeat the preceding step for every remote host that the user will connect to using SSH.
- Typing the passphrase each time a SSH-client program is run could be
cumbersome to a lot of people, especially when running scripts that
execute shell commands on remote systems. One way to avoid having to
enter the passphrase when requesting a SSH connection is to run what is
known as a ssh-agent. The ssh-agent acts on
the user's behalf to authenticate the user to the remote SSH server,
with the capability of remembering passphrases so the user does not have
to enter it explicitly when requesting a SSH connection.
At the beginning of a login session, the user must start ssh-agent:
teaparty> ssh-agent csh teaparty> ssh-add Enter passphrase for '.ssh/identity': not echoed
workstation> ssh-add -t dsa csh Enter passphrase for '.ssh/id_dsa': not echoed
The command ssh-agent takes the name of a login shell as an argument, and could be set to csh, sh, bash, or tcsh. Any SSH service launched within this shell that requires the use of public-keys will interact with ssh-agent.
ssh-add loads the passphrase into the agent's cache. By default, ssh-add prompts for the passphrase corresponding to the RSA key. To load the passphrase for the DSA key, the "-t dsa" option needs to be included in the ssh-add command line. Both ssh-agent and ssh-add must be executed for passphrase-less SSH access to work.
teaparty> ssh alice@wonderland.utexas.edu -------------------------------- Welcome to WonderLand! -------------------------------- wonderland>Finally, agent forwarding must be enabled on the home machine, by including the line
in the system-wide or personal SSH configuration file. The location of the system-wide config file varies from system to system, but the personal file usually resides in $HOME/.ssh/config.ForwardAgent yes The ssh-agent takes into effect until the login session is terminated. It is most convenient to invoke ssh-agent in the login initialization files, such as .login or .xsession.
- The official SSH site can be found at www.ssh.com. It has an FAQ and download sites for SSH-client and server programs on multiple platforms.
- A very informative SSH FAQ page can be found here. The section on "Getting Secure Shell" has a comprehensive list of free and commercial downloads of SSH for different platforms.
- "SSH The Secure Shell The Definitive Guide", by Barrett and Silverman (published by O'Reilly books).
- A very basic introduction to cryptography is available on this page.
- A Detailed Look Inside SSH gives a more in-depth discussion of SSH, including its key components, features, and the mechansim by which a SSH connection is established.