SSH:Authorized Keys

This article originally appeared on the University of Cambridge Engineering site.

Key generation

Decisions to make

Passphrase or not?

If you use a passphrase, the key will not be usable unless you type the passphrase to make it available.

So this is not helpful if you want ssh to run unattended for some reason.

On the other hand, it means that someone with temporary access to your account can't just make a copy of the private key file and then use it subsequently

key type?

Unless you have good reason to do otherwise, allow the key generator to use its default (rsa for ssh-v2 connections).

Creating the key

You can create a private/public key pair (in the files ~/.ssh/filename and ~/.ssh/filename.pub) that has no passphrase protecting the private key, by doing the following:

   cd ~/.ssh
   ssh-keygen -f filename -C 'Some comment' -N '' -t rsa -q

The two files created (filename and filename.pub) can then be used as described below.

If on the other hand, you'd like to protect the private key file with a passphrase (which will be needed to be typed at any client that wants to use the key pair):

   cd ~/.ssh
   ssh-keygen -f filename -C 'Some comment' -t rsa -q

and you'll be prompted for a passphrase. This has no limitation on length. All the normal advice about non-guessable passwords may reasonably be applied to it, although it's possible that a suitably long passphrase consisting of dictionary-attackable words can be just as secure as a short passphrase of random characters.

What the private/public key files are for

The private key is the secret one, not surprisingly. It needs to be kept secure (not world-readable). Only a client with knowledge of the private key can correctly respond to a challenge issued by a server that is using the public key.

If the private key is not passphrase protected, then the file containing it is particularly sensitive; even temporary exposure of your account to a third party could allow it to be copied and then used inappropriately.

If the private key is passphrase protected, then its vulnerability is lower; an attacker would need a copy of the private key file, and also to observe your keystrokes typing the passphrase to your client program (or to have inserted a trojan version of the client program, or ...).

The public key does not need to be kept secret; there is no practical way of guessing the private key that will match it. It is put in your ~/.ssh/authorized_keys file on the machine that you want to connect to.

There may be good reasons to keep the authorized_keys file protected from world-readability (it may contain directives as to what machines may use a given key or what commands will be run in response to the use of a given key, which may be sensitive information) but protecting the public key is not one of them!

Setting up an authorized_keys file

Once you've created your key pair, you can insert the public half of it into your authorized_keys file on computer "X". A client on computer "Y" that knows the private key can then authenticate to your account on computer "X".

So, on the machine you want to log into, you should add a line to your ~/.ssh/authorized_keys file that contains exactly the single line that was created in the filename.pub file (for whatever choice of "filename" you made).

For example, we might wind up with a .ssh/authorized_keys file that looks like:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAybmcqaU/Xos/GhYCzkV+kDsK8+A5OjaK
5WgLMqmu38aPo56Od10RQ3EiB42DjRVY8trXS1NH4jbURQPERr2LHCCYq6tHJYfJNhUX
/COwHs+ozNPE83CYDhK4AhabahnltFE5ZbefwXW4FoKOO+n8AdDfSXOazpPas8jXi5bE
wNf7heZT++a/Qxbu9JHF1huThuDuxOtIWl07G+tKqzggFVknM5CoJCFxaik91lNGgu2O
TKfY94c/ieETOXE5L+fVrbtOh7DTFMjIYAWNxy4tlMR/59UVw5dapAxH9J2lZglkj0w0
LwFI+7hZu9XvNfMKMKg+ERAz9XHYH3608RL1RQ== This comment describes the 
key

except that I have deliberately split the single long line to make it more readable.

Making an ssh connection using a private key

On the machine you want to log in from you would run

   slogin -i ~/.ssh/filename remotehost

(for appropriate values of "filename" and "remotehost") thus telling slogin to look in the private key file.

The connection would then be made without any further authentication being necessary (although slogin would prompt for a passphrase if the private key were protected by one.

authorized_keys: restricting access

What we have described above allows any remote host where the private key is known to make any kind of ssh connection (login, remote command execution, port forwarding, etc.) to the computer on which the authorized_keys. There are a number of things that can be done in an authorized_keys to further restrict access. These are all arranged by prefixing the line containing the public key by a single "phrase" of comma-separated options (see below for an example of what this winds up looking like)

Host access list

If the options phrase at the beginning of a line contains the keyword from="string" this restricts the use of the key on that line to sessions that originate from hosts that match "string". Examples might be

   from="trusted.eng.cam.ac.uk"
   from="*.eng.cam.ac.uk,!untrusted.eng.cam.ac.uk"
   from="tw?00.eng.cam.ac.uk"

The hostname used will need to be the hostname reported when the IP (network) address of the connecting machine is looked up in the DNS. The * wildcard matches one or more characters, while the ? wildcard matches a single character. If the connecting hostname matches an entry prefixed by '!', then it will be rejected.

Forced command

If the options phrase at the beginning of a line contains the keyword command="string", then any ssh connection that authenticates using that particular key will only run the command specified, even if the command line it was given specified another command.

Other options

Various ssh facilities may be suppressed by adding the following options to the options phrase at the beginning of a line:

   no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

When heavily restricting an ssh key in circumstances where entirely automated remote connections are desired, it is generally a good idea to apply all of these options unless the command being run actually needs one of these facilities.

Example authorized_keys file

This example file has two entries. Note that there is no whitespace in the list of options; they are separated by commas, and strings are double-quoted (eg in the argument to from=).

#
# comments are ignored in authorized_keys files
#
from="trusted.eng.cam.ac.uk",no-port-forwarding,no-pty ssh-rsa AAAAB
3NzaC1yc2EAAAABIwAAAQEAybmcqaU/Xos/GhYCzkV+kDsK8+A5OjaK5WgLMqmu38aPo
56Od10RQ3EiB42DjRVY8trXS1NH4jbURQPERr2LHCCYq6tHJYfJNhUX/COwHs+ozNPE8
3CYDhK4AhabahnltFE5ZbefwXW4FoKOO+n8AdDfSXOazpPas8jXi5bEwNf7heZT++a/Q
xbu9JHF1huThuDuxOtIWl07G+tKqzggFVknM5CoJCFxaik91lNGgu2OTKfY94c/ieETO
XE5L+fVrbtOh7DTFMjIYAWNxy4tlMR/59UVw5dapAxH9J2lZglkj0w0LwFI+7hZu9XvN
fMKMKg+ERAz9XHYH3608RL1RQ== This comment describes key #1
# 
# this one should be restricted so that only machines with hostnames
# matching *.eng.cam.ac.uk can use it.
# 
from="*.eng.cam.ac.uk",no-X11-forwarding,noagent-forwarding ssh-rsa 
AAAAC4MybC1yc2EAAAABIwAAAQEAybmcqaU/Xos/GhYCzkV+kDsK8+A5OjaK5WgLMqm
u38aPo56Od10RQ3EiB42DjRVY8trXS1NH4jbURQPERr2LHCCYq6tHJYfJNhUX/COwHs
+ozNPE83CYDhK4AhabahnltFE5ZbefwXW4FoKOO+n8AdDfSXOazpPas8jXi5bENf7he
ZT++a/Qxbu9JHF1huThuDuxOtIWl07G+tKqzggFVknM5CoJCFxaik91lNGgu2OTKfY9
4c/ieETOXE5L+fVrbtOh7DTFMjIYAWNxy4tlMR/59UVw5dapAxH9J2lZglkj0w0LwFI
+7hZu9XvNfMKMKg+ERAz9XHYH3608RL1RQ== This comment describes key #2

Note that in reality, such a file would only have two uncommented lines, both of them very long.

If it doesn't work

There are a number of reasons why key authentication might not work.

Wrong keys

First, check that you really have put the matching public key in the ~/.ssh/authorized_keys file on the machine you're trying to connect to, and that you're telling your ssh client about the correct private key using the -i argument.

Keys the wrong way round

The public key goes in the destination host's ~/.ssh/authorized_keys file.

The private key is needed on the machine you're running ssh or slogin from.

File permissions

Some clients and servers are very picky about file permissions on their configuration files. Among possible objections they may have are:

• a key file being writable by anyone other than the user (eg group-writable)
• a private key file being readable by anyone other than the user.

Wrong ssh protocol version

Most ssh clients and servers support both v1.5 and v2 of the ssh protocol.

Sometimes, however, they'll both decide to prefer v1.5 even though they both support v2. In such cases, your ssh-rsa key (which is v2 compliant) won't work.

Solution: Force v2 by using the -2 flag to ssh or slogin

     ssh -2 -i ~/.ssh/my_private_key remotemachine

failure to use the right authentication mechanisms

The client can be configured to request particular authentication mechanisms in a particular order. A non-standard local configuration file can therefore potentially lead the client to prompt for a password before in a particular ordera successful keybased authentication can occur.

The following options passed to ssh or slogin should compel the client to only offer/try the key-based authentication mechanism only:

   ssh -2 -i ~/.ssh/my_private_key \
       -o 'PasswordAuthentication no' \
       -o 'ChallengeResponseAuthentication no' \
       -o 'PreferredAuthentications publickey' \
       remotemachine