[Univ of Cambridge] [Dept of Engineering]

ssh (secure shell) - how it works

In order to keep this document readable, some details of the operation of ssh, particularly of the cryptographic techniques used, have been simplified to the point of not being completely accurate.

Once you have read about the workings of ssh, it may be worth reading the recommendations of how to use ssh in various kinds of situation.

Basic principles of ssh operation

The main point of the ssh tools is to allow you to securely interact with remote machines. Before you actually do anything (run a session, transfer a file, or whatever), there are three things that need to be done: The traditional tools such as rlogin only usefully performed the third of these tasks, and did so in a flawed manner by transferring your password in plain text across a potentially insecure network.

In order to do this, the ssh programs pass through a number of stages of negotiation before permitting the user to do what they wish to:

host identification
Proving that the remote host you're talking to is the one you think it is.

Establishing an end-to-end link whose data transfers are encrypted, so that no-one who's observing the network can derive any information from it. Note that this happens before authentication occurs, so any passwords or other authentication information will not be transmitted in an observable form.

This is the stage at which the user proves to the server that they have the right to perform operations as a particular user on the server machine. This may be by quoting a password, or by some other means.

Host identification

This is done using a technique known as RSA authentication. Hosts that support ssh arrange to have a host identification key consisting of a public and private part. The private part of the key is secret and only known to the administrator of the machine, while the public part of the key is freely available. A message RSA-encrypted with the public part of the key can only be decrypted with knowledge of the private part of the key.

During this stage of the session setup, the server sends its public key to the client, and the client encrypts a random session key with it and sends the result back to the server. The client clearly knows the session key as it generated it, and the server can use its private key to decrypt the message the client sent to it.

The session key is used by whichever cipher is chosen for encryption. Since only the client and a server running on a machine that knows the secret half of the server's host key can know the session key, this both secures the session, and assures the client that it must be talking to the correct server machine.

Host identification - further checks

There are further checks that ssh performs.
Server Check
[Server Check] Firstly, the client expects to have a list of public keys for server machines available to it, on either a per-machine or per-user basis. If it is asked to contact a machine for which it doesn't have a public key locally held, it will warn the user with the following message:
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? 
If the user agrees to continue connecting, the host public key will be added to that user's personal list of host public keys.

Machine administrators can arrange for a list of known host public keys to be made available in an appropriate location - this saves users from having to store their own copies of host public keys, and reduces the number of times that the slightly alarming message above occurs.

Client Challenge
Secondly, for certain types of authentication, the server may need to prove that the client machine is what it claims to be. It will only do this when an administrator has included the public key for the client machine in the per-machine list of known host public keys on the server machine. The server will create a "challenge" encrypted with the client's host public key - only if the client is the machine it claims to be will it have access to the correct private key which enables it to decrypt the challenge and send it back to the server.
There is further discussion of the maintenance of lists of host public keys in the section on installing and administering the ssh package.


The previous section showed how ssh ensures that both you, and if necessary the server at the other end know who you both are. The next question is what steps are you going to take to prevent any data (both authentication information, and subsequent session data) transferred (password, keystrokes and program output in the case of slogin or password and file contents in the case of scp) being snoopable.

In order to do this, the ssh client and server use RSA to exchange keys for one of a number of different ciphers (encryption methods) which will be used to encrypt all subsequent data transfers in the session. An attacker would need to know the key in order to decrypt any part of the session, and the keys are negotiated in an encrypted form that requires knowledge of one or other hosts' secret host keys.

What encryption methods can I use?

ssh clients and servers can negotiate to use one of a number of different encryption technologies for this purpose. Some implementations may only support a subset of these ciphers (often due to the lunacy of various governments' restrictions on the use and/or import/export of encryption technology, or due to perceived difficulties with patents in certain countries). All servers and clients are required to support "3DES" as a fallback cipher in case all other requested ciphers are unavailable.

The encryption method used can be selected by command-line argument - the versions of ssh compiled up in CUED support the following (details unashamedly pinched from the file README.CIPHERS in the ssh distribution):

The default encryption method for ssh as installed in CUED

to force, use "-c idea" command line argument

A 128-bit block cipher. Faster than 3DES, but slower than Arcfour and Blowfish. The IDEA algorithm is patented in many countries, and the patent holder disallows commercial use (their definition of commercial use include connections from one corporation to another corporation).

Performance on a pentium machine is about 64% of "none" encryption.

use "-c blowfish" command line argument

Bruce Schneier's block cipher that was designed to be a fast and free alternative to existing encryption algorithms. It is unpatented and license-free. SSH version uses a 128-bit key for Blowfish (the algorithm allows anything from 32 to 448 bits).

Performance on a pentium machine is about 88% of "none" encryption.

use "-c 3des" command line argument

Three-key triple-DES (effective key length of about 112 bits) in inner CBC-mode. This is the default fall back cipher that is used if the client asks for a cipher that isn't supported by the server. RSA private key files are encrypted by 3DES by default. (Some older versions encrypted private key files with IDEA, and such key files may still be around.) Performance on a pentium machine is about 45% of "none" encryption.

There are a number of other encryption methods ("ciphers") supported in the ssh distribution, but they are not compiled in unless explicitly requested. These include "Arcfour" (which has a security problem when used with the version 1.5 protocol), "DES" with 56 bit key (which is trivially crackable on modern hardware), and "none" (which is only provided for testing purposes, and introduces multiple security vulnerabilities if enabled).

What mechanisms are there to authenticate myself?

By this point, we've established a secure (encrypted, unsnoopable, and unspoofable) connection between two hosts that have reliably identified each other. We now need to proove that the user running the client is authorised to do things at the server end. In order to do this, they must authenticate themselves.

There are four authentication methods supported in ssh protocol version 1.5

rhosts authentication
This is not recommended and is disabled within CUED , as it is almost as insecure as the rlogin family of programs.

In this case, the server does nothing more than to check if the client host is listed in the .rhosts file for the user that the client is requesting to be logged in as.

rhosts with RSA authentication
This is a significant improvement on the above. In this case, the server does the same check of the .rhosts file, but if this would have succeeded, it will not allow the login unless it is able to validate the client machine as being what it claims to be with an RSA challenge (as discussed towards the end of the host identification section ).

Thus, if the user wishes to always be trusted when they connect from machine X, ssh will go along with this, but will make sure that no-one pretends to be connecting from machine X when they're actually somewhere else.

password authentication
In this case, the client asks the user for their password. It quotes it (via the encrypted session) to the server, which performs the required check to see if it is the valid password for the user that the client is requesting to be logged in as.

This form of authentication requires no trust of the client host being who they are, the domain name services being accurate, or whatever - merely that the possession of the correct password is a valid identification of the user - that is, that they have kept the knowledge of their password suitably secure.

pure RSA authentication
In this case, the server will, if it is aware of a public key for the user that the client is requesting to be logged in as, and if the client quotes that public key, create an RSA challenge encrypted with that public key. If the client knows the corresponding private key, it can decrypt the challenge and send it back to the server, which now knows that the client must have the secret and should therefore be allowed access.

This form of authentication requires no trust of any host, network or software - it relies purely on possession of the private user key by the client.

What are the other programs shipped with ssh?

ssh-keygen produces an RSA public and private key pair. The default action of the program is to create the key pair, prompt the user for a file to write the private key in, prompt the user for a passphrase with which to encrypt the private key, write the private key encrypted with the passphrase to the file specified, and write the public key to the same filename with .pub appended. It has a number of other possible behaviours which are documented in its man page.

It is highly advisable to follow the advice in the man page concerning the use and choice of passphrase. Even though the private key file is created by default with permissions that only allow the owner to read it, it may well be transferred between machines if it is on an NFS mounted filesystem, and encryption of the private key decreases the risk associated with this.

The only circumstance in which it is reasonable (and indeed desirable) not to use a passphrase, is when creating a public/private host key pair, in which case the private host key should be held on a local non-exported filesystem in a file readable only by the root account.

ssh-agent is a program which remembers private authentication keys for you. A program started as a sub-process of the agent inherits a connection to the agent, (and sub-sub-processes of that do as well), and any ssh program called from such a sub- or sub-sub-process (etc.) will automatically attempt to use the ssh-agent to acquire the information it needs to authenticate itself. Thus you can avoid the need to type RSA pass-phrases every time you call one of ssh, slogin or scp.

ssh-agent when first started up has no authentication keys held. You have to use ssh-add for that.

ssh-add connects with your current authentication agent and adds a private authentication key to the list that it is remembering for you. By default it adds the authentication key corresponding to the identity stored in the file $HOME/.ssh/identity, but can add any others you choose. It will prompt you for the passphrase to decrypt the contents of the identity file to extract the private key, which it will then pass on to the authentication agent.

If ssh-add is started with its input disconnected from a tty, for instance by running
ssh-add < /dev/null
then it will use a graphical interface to query the user for their passphrase. This means that it can be usefully integrated into your .xsession file.

This is a simple script that connects to a list of hosts to find out what public host keys their sshd daemons (the processes that provide the ssh service on a server) quote. You can use it to create a list of known hosts for a host or a particular user.

How best to use ssh in various situations

on a separate page

Installing and administering the ssh package

on a separate page

Updated on 8th October, 1998
Patrick Gosling