![[Univ of Cambridge]](http://www.eng.cam.ac.uk/images/house_style/uniban-s.gif)
![[Dept of Engineering]](http://www.eng.cam.ac.uk/images/house_style/engban-s.gif)
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.
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 client (eg
slogin) needs to establish that it is
talking to the machine you asked it to, and not another machine
that's spoofing it (or sitting in the middle accepting data and
passing it on transparently).
- the server on the remote machine may want to establish that you are
connecting from the machine you appear to be, and not another machine
that's spoofing it.
- the client needs to convince the server that you are who you claim
to be, and are authorised to do things on the server.
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.
- encryption
-
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.
- authentication
-
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.
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):
- IDEA
-
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.
- Blowfish
-
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.
- 3DES
-
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).
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.
- ssh-keygen
- 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
- 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
-
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.
- make-ssh-known-hosts
- 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.
on a separate page
on a separate page
[Help]
Updated on 8th October, 1998
Patrick Gosling
jpmg@eng.cam.ac.uk