About ssh

These pages were first written in November 2000 when Maths decided to move away from telnet/rlogin to ssh for remote logins in advance of a general college-wide block at the perimeter firewall for incoming connections using these less secure protocols. Back then, ssh was not widely used and was not installed or even available for many Maths computers so it was something of a novelty; now it is telnet that is becoming rare - Windows no longer includes a telnet client with the default installation, for example.

ssh (Secure SHell) is an enhanced replacement for the UNIX rsh, rlogin and telnet utilities and offers an encrypted end-to-end link between hosts which is considerably more secure than both telnet and the notoriously insecure rsh. ssh is also the underlying transport used by sftp (Secure FTP) and scp (Secure CoPy) and is widely used for many other communications tasks such as running rsync over a secure encrypted connection, for example.

ssh is a client-server protocol - you use ssh client software running on your local computer to connect to a remote computer which is running a ssh server. All modern Linux, UNIX and Mac computers have an ssh client installed as part of the basic operating system and most also have an ssh server installed as well but, for security reasons, this is not always enabled or running by default. Also, it's worth remembering that the desktop version of Ubuntu Linux does not come with an ssh server installed - you need to install this yourself by typing 'sudo apt-get install openssh-server'.

In the Windows computer world, ssh is not used at all except for communicating with UNIX-like computers so ssh will not normally be found on a standard Windows installation. However, third-party ssh clients are available that can be installed on a Windows PC and a popular free ssh client is PuTTY which you can download and install yourself from:

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

ssh clients are also available for Android (the Juice app is highly recommended), Apple and some other smartphones and tablets.

How do I use it?

Basic usage

ssh host

where host is the name of the remote host you want to connect to. If your username on the remote system is different from your username on the system you are currently using and connecting from, either of the commands:

ssh -l username host
ssh username@host

where username is your username on the remote host, this will allow you to connect to the remote system called host. Here's a real world example - Jenny Bloggs has the username jbloggs and wants to connect to hessian, a Linux system in Maths. She can use either of the two commands:

ssh -l jbloggs hessian.ma.ic.ac.uk
ssh jbloggs@hessian.ma.ic.ac.uk

Advanced usage

More advanced uses include running a command or starting a program on the remote system without actually having to log into it:

ssh username@host command

where command is a built-in shell command or an executable program on the remote system you are connecting to. Here are some examples:

ssh username@host df -k

shows available disk space on the remote system

ssh username@host ls -l

lists the files and directories in your home directory

ssh username@host /usr/local/bin/R --vanilla < my_program.R &

starts your R program called my_program.R and exits, leaving the program running in the background even though you have not logged into the remote system.

The known_hosts file

Every time you make a connection to a remote system using ssh, a pair of SSL keys are used to verify the authenticity of the remote sytem and to encrypt the entire session. These keys are supplied by the remote system and are known as the host keys; one is a private key which is kept on the remote system and the other is the public key which is made available to a connecting system (ie, yours) if it wants to connect to it. The first time you connect to a remote ssh host, you won't already have its public host key so the ssh client (the software that runs on the computer you are connecting from) will prompt you if you want to accept the key from the remote system and connect as in this example:

andy@riemann:~ $ ssh potomac3
The authenticity of host 'potomac3 (155.198.196.32)' can't be established.
RSA key fingerprint is 6e:49:83:30:f5:c5:07:e8:15:65:22:ba:44:f5:0a:ac.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'potomac3,155.198.196.32' (RSA) to the list of known hosts.
Password:

Normally you would answer 'yes' and your ssh client will store the remote system's public key along with some other information such as IP address and the hostname as you have typed it, etc in a file called known_hosts in the .ssh folder in your home directory and complete the connection. If you change your mind and answer 'no' then the connection attempt is aborted and the remote system's public host key will not be stored in your known_hosts file.

The next time you connect to that same remote system, your ssh client checks the ~/.ssh/known_hosts file to find out whether you have connected to that machine before and if so, uses that machine's public host key already stored there and then the connection proceeds to the next step (either a password prompt or a successful connection).

Setting up ssh to connect without a password

A useful feature of ssh is the ability to connect and log into a remote system without having to type in a password or answer any other ssh prompts. This makes possible unattended/scripted logins to do all sorts of things - start remote compute jobs, transfer files, initiate backups, etc. Security and user authentication is provided by a pair of encrypted SSL keys, one of which (the private key) you keep to yourself and the other (the public key) you keep on the remote system.

Once you have created a key pair and started to use automated logins, you'll wonder why you never did this before as being able to connect to large numbers of systems without having to type in passwords every time saves so much time.

Creating a ssh key pair is easy using the ssh-keygen utility - there are quite a lot of options to this but by default it will create keys suitable for most users (a 2048 bit RSA key pair for use with ssh protocol 2 connections). But do note that you must create a keypair with no passphrase; if you specify a passphrase, it defeats the whole object of the private/public keypair scheme as you'll then be prompted for the passphrase instead of the password! So in the example ssh-keygen session shown below, simply hit the return key both times you are prompted for a passphrase and it will create a keypair that does not use or require a passphrase:

andy@riemann:~ $ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ma/a/andy/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/ma/a/andy/.ssh/id_rsa.
Your public key has been saved in /home/ma/a/andy/.ssh/id_rsa.pub.
The key fingerprint is:
80:d9:2c:2d:d7:4e:57:7f:a1:68:6a:d1:79:02:bc:18 andy@riemann.ma.ic.ac.uk

This will create two keys in your .ssh folder:

andy@riemann:~ $ ls -l .ssh
total 64
-rw------- 1 andy mastaff   883 Nov 10 14:50 id_rsa
-rw-r--r-- 1 andy mastaff   222 Nov 10 14:50 id_rsa.pub

The id_rsa key is your private key which you should look after and never give to anyone else; note that its permissions are such that only yourself can read it or change it and if you relax these permissions in any way, the key becomes insecure. Most ssh clients will warn or even prevent you from using the key until the permissions have been set correctly. On the other hand your public key is id_rsa.pub which can be read by anyone - this is intentional otherwise the remote system will not be able to use your public key.

The private key, id_rsa, needs to be in your .ssh folder on the computer you are making the ssh connection from while the id_rsa.pub public key must be in your .ssh folder on the computer you want to connect to. At Imperial College, more often than not your home directory on both the computer you are connecting from and the one you are connecting to will be one and the same as for most users, their home directories will be on a central or local fileserver. So you won't actually have to worry about copying your public key to other computers in most cases. But if you are connecting to a remote system where your home directory is not the same as your college home directory, or to an external system, then you will have to copy your public key to your .ssh folder on the remote system first

Once you have created your key pair, copy your id_rsa.pub public key to a file called authorized_keys or, alternatively, if this will be the only ssh key pair you will ever use on these systems, you can simply create a soft symbolic link (symlink) to it:

andy@riemann:~ $ cd .ssh
andy@riemann:~/.ssh $ ln -s id_rsa.pub authorized_keys

If you intend connecting to the remote system using a variety of key pairs, eg perhaps using one pair for connecting from one Maths computer to another and a different pair to connect to a Maths computer from a computer at home, then you will need to rename one of the public keys to a different name and then add them both to your authorized_keys file, each on a separate line.

Now make a ssh connection to the remote system where your id_rsa.pub key is already installed; if you have not connected to that system before, you'll be prompted as usual whether you want to do this as your ~/.ssh/known_hosts file will not already have a public host key for that host. Once you have answered 'yes' to confirm the connection, you will be logged in without being asked for your password and the next time you connect to that system, you will not even be asked if you want to connect. Magic!

Using the X Window System over ssh

In addition to interactive text-based connections, ssh also has the ability to provide a secure encrypted tunnel for X Window System traffic between an X client such as Matlab or xmaple running on a remote system and the X server running on your local PC. This is known as X forwarding and operates seamlessly and transparently via separate channels to your interactive login sessions.

Just to clarify the terminology used in the X Windows System - the X Server is the computer you are sat in front of, where you are using the keyboard, mouse and one or more display screens. The X client is the X Window program running on a remote system that you are connected to, whose output is being sent over the network to your local computer (the X server) and you are controlling that remote X client program using your own mouse, keyboard, etc. This is not intuitive and initially it might take a little getting used to the fact that your system is the server as far as the X Window System is concerned while the remote system (which very often is a 'real' server!) is running the X client program, as this is the reverse of the usual situation where your local system will be a client of a remote server. But when you think of it, the computer you are sat in front of can have X Window connections open to several different computers at once, each running different X Window applications as clients of your computer; all the processing work is being done on the remote X client systems and all your X server has to do is display the output from those programs and allow you to control each remote X client using your keyboard and mouse, etc.

There are two security-related points that need to be borne in mind before trying to run X Window applications over an ssh connection - you need to allow the remote system to connect to your local X server and you will almost certainly need to enable X forwarding in ssh.

Allowing remote systems to access your X server using xhost

Connections from remote systems to your X server (that is, your graphical display, keyboard, mouse and other pointing devices on your local PC that you are sitting at) will by default be refused in the interests of security and you need to enable this using the xhost command before you use the ssh command to make the connection. A simple use of this utility would be to type xhost + as in this example:

andy@purdy:~$ xhost +
access control disabled, clients can connect from any host

which will allow any remote system to connect to your system and send X Window output to it from an X client application. This is OK if you're in a hurry or just need to set up an X session for a short period but it could leave your X server open to abuse. Much better is to first refuse all connections:

andy@purdy:~$ xhost -
access control enabled, only authorized clients can connect

and then to specifically permit the host(s) you want to allow connections from:

xhost +lovelace.ma.ic.ac.uk

Note that if you have already typed xhost + and then followed it up with xhost +lovelace.ma.ic.ac.uk, the latter does not imply that global access has been disabled! If in doubt, just type xhost with no parameters and it will tell you the current settings:

andy@purdy:~$ xhost
access control enabled, only authorized clients can connect
INET:lovelace.ma.ic.ac.uk

(The INET prefix to the xhost report signifies it's a normal Internet IPv4 network host connecting via ordinary TCP/IP - there are a number of other ways your X server can be connected to but they are not frequently used).

Enabling X forwarding in ssh

By default, X forwarding is enabled in commercial implementations of the ssh client and those bundled with some UNIX installations but disabled on the Openssh implementations found on most Linux and open source UNIX distributions. On Linux, you need to enable X forwarding when you connect to a remote system by using the -X option to ssh, for example:

ssh -X username@host

and you can disable it again with the small x option, -x:

ssh -x username@host

Once you have logged into a remote system you can start up your X application there and view/control it on your local system. Here is an example screenshot of an interactive login in which the xclock application is started on the remote system:

the X output (in this case the X clock) will appear in a separate window to the shell that the connection was made from.

As with the ssh remote commands described above, you can also launch an X application on the ssh command line without actually having to log into the remote system first but you may need to give the full path to that application because when you don't log in and start a shell, you will not have a default path (since there is no shell), eg:

ssh -X hessian.ma.ic.ac.uk /usr/bin/X11/xclock &

will start up the remote system's xclock on your PC - note the full path to the xclock program.

ssh warning messages

Sometimes when connecting to a remote computer that you have connected to before you may see the following message:

andy@anahata:~ $ ssh potomac.ma.ic.ac.uk
Warning: the RSA host key for 'potomac.ma.ic.ac.uk' differs from the key for the IP address '155.198.196.144'
Offending key for IP in /export/home/andy/.ssh/known_hosts:520
Matching host key in /export/home/andy/.ssh/known_hosts:878
Are you sure you want to continue connecting (yes/no)

This can occur if you have in the past connected to the remote machine called potomac using the short hostname 'potomac' rather than the long hostname 'potomac.ma.ic.ac.uk' and the public host key for 'potomac' already exists in line 520 of your known_hosts file and also, another entry for the same machine with the long hostname 'potomac.ma.ic.ac.uk' exists in line 878. Now you have 2 keys for the same machine but slightly different addresses and ssh will alert you to the fact - in general, it is safe to answer 'yes' and proceed. You can in any case edit your known_hosts file with any text editor and delete one of the two keys, say, the one on line 520. Eg, using vi, you can simply use the following key sequence:

andy@anahata:~ $ vi ~/.ssh/known_hosts
520G
dd
[ESC]:wq

A more worrying message (or messages) may sometimes appear:

andy@anahata:~ $ ssh presley.ma.ic.ac.uk
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for presley.ma.ic.ac.uk has changed,
and the key for the according IP address 155.198.196.6
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
8e:4f:ed:22:69:ab:f1:da:7c:a7:17:95:34:96:5b:fa.
Please contact your system administrator.
Add correct host key in /export/home/andy/.ssh/known_hosts to get rid of this message.
Offending key in /export/home/andy/.ssh/known_hosts:585

RSA host key for presley.ma.ic.ac.uk has changed and you have requested strict checking.
Host key verification failed.

This particular instance is actually nothing to worry about - the machine presley was moved from level 6 in the Huxley building to the basement level 1 and as a result, its IP address changed from 155.198.192.37 to 155.198.196.6. As the machine was powered off before it was moved and then powered back on again in its new location, it created a new public/private host key pair at boot time which differs from the public host key already stored in your known-hosts file. The solution to this scenario is to edit your ~/.ssh/known_hosts file and remove line 585 as described above.

But not all warnings of this type can be explained away as easily as this one and if you are in any doubt, do not connnect to the remote system until you have satisfied yourself that the system is what you think it is. A system that has been compromised (in other words, broken into) by an unauthorised person may well have had its normal ssh installation replaced by a different one which might be logging all of your keystrokes, for example. But even so, it will never have the same host key pair as the original system which should alert you to the fact that something has changed on the remote system and you should treat it with suspicion until proved otherwise.

Research Computing Manager,
Department of Mathematics

last updated: 10.5.21