|Department of Engineering|
|University of Cambridge > Engineering Department > computing help > jpmg help|
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
~/.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 -qThe two files created (
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 -qand 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.
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
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!
So, on the machine you want to log into, you should add a line to
~/.ssh/authorized_keys file that contains exactly
the single line that was created in the
file (for whatever choice of "filename" you made).
For example, we might wind up with a
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 keyexcept that I have deliberately split the single long line to make it more readable.
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.
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
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)
If the options phrase at the beginning of a line contains the
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.
* 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.
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.
Various ssh facilities may be suppressed by adding the following options to the options phrase at the beginning of a line:
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.
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
# # 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.
There are a number of reasons why key authentication might not work.
First, check that you really have put the matching public key in
~/.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
The public key goes in the destination host's
The private key is needed on the machine you're running ssh or slogin from.
Some clients and servers are very picky about file permissions on their configuration files. Among possible objections they may have are:
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
ssh -2 -i ~/.ssh/my_private_key remotemachine
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
This may be a useful way of minimising the chances of an entirely autonomous ssh-based command execution failing due to attempting a user interaction.