ssh is a protocol used to create an encypted communication channel from a local computer (the client) to a remote system (the server). Once initiated, you can use this channel to

• run commands on the server in a shell window

• transfer files to/from the server

• automate tasks that login to the server without user intervention

• run X applications on the server and display them on the client

• encrypt a vnc session to run a desktop session on the server and display it on the client

All this can be done securely since the channel is encrypted. After discussing the basics of how ssh works, we will briefly tackle each of these issues.

In the pages following we discuss a lot of key-based techniques for communication. Briefly, there are two types of keys used:

• the goal of the initialization process is to produce a single key, shared by server and client, that is used to encrypt and decrypt the session. This is called the session key. It is a symmetric key, which means there is a single key used to both encrypt and decrypt data and both sides have it.

• the session key, of course, cannot be passed between server and client if the communication is to be secure. In order to generate the session key, an asymmetric key algorithm is used. This consists of a key pair generated on one side of the communication. The key pair consists of a public key and a private key with a very special property - data encrypted with the public key can only be decrypted with the private key. The public key can thus be broadcast so anyone can use it to encrypt data. So long as the private key is kept secret on the server that owns it, only that server can decrypt messages intended for it.

• Communication using a symmetric key is two-directional and relatively fast. Communication using an asymmetric key pair is unidirectional and much less efficient. Thus, asymmetric keys are only used to generate the symmetric key and to authenticate. We will see the use of key pairs (or an asymmetric key) used for the authentication of hosts and of users.

Disclaimer: ssh is complex and I am not an expert on it. I am going to try to present each of these as simply as possible. We will restrict our discussion to Openssh using SSH protocol version 2. Other packages (SSH1, Openssh/2, SSH2) differ in the specifics of the implementation and, importantly, in the name, location and content of the authorized_keys file.

Basic ssh connections

An ssh (openssh) connection proceeds in several steps:

1. you initiate the connection from the client to the server using 

ssh (or sftp or scp or ...) [user@]host

The server and client agree on a protocol.

2. the server identifies itself and sends back its [public part of the asymmetric] host key. The client uses the host key to encrypt a message, sends it back to the server and verifies that the server can decrypt it, which proves it has the corresponding private part of the host key.

3. the client looks in your file of known hosts (~/.ssh/known_hosts) to see if the host has previously been contacted. Each entry in known_hosts contains a host identifier and that host's host key. There are three possibilities:

• if a host key for the server is found in known_hosts that matches the host key, the host is recognized and the connection proceeds

• if a host key for the server is found in known_hosts and it is different from the host key, the connection is refused with a stern message like:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
71:e6:71:f3:72:61:9c:48:a2:55:1f:9f:26:7c:d4:84.
Please contact your system administrator.
Add correct host key in /users/gboyd/.ssh/known_hosts to get rid of this message.
Offending key in /users/gboyd/.ssh/known_hosts:2
RSA host key for 147.144.23.58 has changed and you have requested strict checking.
Host key verification failed.

ssh is telling you that it has previously connected with the server and the host key is different than that it saved during the previous connection (the 'offending key', where the :2 indicates line 2 of known_hosts). This could be due to another host masquerading as the server (as indicated in the message) or to something innocuous like reinstalling the server's operating system. In any case, it will refuse to connect to the server until you delete the 'Offending key'. The message above tells you what to do. If you believe the host key may have changed with good reason, edit ~/.ssh/known_hosts and delete line 2. (Don't delete the entire file, as many students do!) Then reconnect. This will result in the last possibility:

• if no host key for the server is found in known_hosts you will get a message like

The authenticity of host '147.144.23.58 (147.144.23.58)' can't be established.
RSA key fingerprint is 71:e6:71:f3:72:61:9c:48:a2:55:1f:9f:26:7c:d4:84.
Are you sure you want to continue connecting (yes/no)?

to which you must answer yes (the entire word) if you want to continue to connect. The host key is added to known_hosts for later connections.

This complexity is necessary as a rogue machine could sit between you and the server masquerading as you to the server and as the server to you. This machine would then be in a position to break the encryption after it is established. (Note that this could still occur if you accept the new host key! It is only prevented after the first time you connect, when the host key can be verified.)

At this time a session identifier is also computed by both sides of the communication. It is used later to identify the session.

4. The session key, which is used to encrypt the bulk of the session, is computed using an amazing technique called the Diffie-Hellman algorithm where a shared secret is used to generate the same key independently on the server and on the client. Each session produces a different session key. Basically, each of server and client create an asymmetric key pair and exchange the public portion.  They then independently compute the session key using their own private key and the other system's public key. Amazingly, this algorithm creates the same session key on both server and client, and it cannot be reproduced without one of the private keys. The session key, which is symmetric, is used to encrypt the rest of the session.

5. Encryption is begun (using the shared session key).

6. The client attempts to authenticate itself to the server. It can use a variety of methods. We will only discuss two: public key exchange and password. So far, most of us are familiar with the password mechanism, which is our login password. Remember, the password is encrypted with the session key before it is transmitted. (We will discuss authentication based on asymmetric key exchange in the next page.)

Once authentication succeeds, you are logged in to your encrypted session.

Besides ssh, the familiar scp and sftp programs establish an ssh secure encrypted channel for their work. In fact, if your host allows it, you can send any data you want through ssh to encrypt it before going across the internet using an ssh tunnel.

We will discuss the public key authentication process next. According to the definitive work, it is the most secure authentication mechanism available. It also allows you to connect to a server without intervention, enabling automated processes across a secure channel.

Note on the ssh port

The ssh protocol by default uses the well-known port 22 on the server. Since this is a standard port, it is often a target for hackers trying to break in - every connection is allowed a number of attempts at login per connection (usually 3-5) before being disconnected. If you are running your own server you may want to hide ssh's port by running sshd on the server on a private port of your choosing. This means the well-known port would appear inactive, fooling casual observers into believing that ssh connections are not allowed. 

To change the default ssh port, edit /etc/ssh/sshd_config and add the Port XXX line, where XXX is your private port. Then restart sshd using service sshd restart. Unfortunately, there is no common syntax for invoking an ssh client program and pointing it at your private port. Here are the current options for the command ssh clients:

ssh -p XXX

sftp -oPort=XXX

scp -P XXX

Yes, scp and ssh disagree on the capitalization of 'p'.