] Keys are more
secure than passwords in general and address all the weaknesses
mentioned earlier.
2.4.3. Installing a Public Key on an SSH ServerMachine
When passwords are used for
authentication, the host operating system maintains the association
between the username and the password. For cryptographic keys, you
must set up a similar association manually. After creating the key
pair on the local host, you must install your public key in your
account on the remote host. A remote account may have many public
keys installed for accessing it in various ways.
Returning to our running example, you must install a public key into
the "pat" account on shell.isp.com. This is done by editing a
file in the SSH configuration directory:
~/.ssh/authorized_keys
for SSH1 and OpenSSH[9] or
~/.ssh2/authorization for SSH2.
For SSH1 or OpenSSH, create or edit
the file ~/.ssh/authorized_keys and append your
public key, i.e., the contents of the
identity.pub file you generated on the local
machine. A typical authorized_keys file contains
a list of public key data, one key per line. The example contains
only two public keys, each on its own line of the file, but they are
too long to fit on this page. The line breaks inside the long numbers
are printing artifact; if they were actually in the file, it would be
incorrectly formatted and wouldn't work:
1024 35 8697511247987525784866526224505474204292260357215616159982327587956883143
362147028876494426516682677550219425827002174890309672203219700937187777979705864
107549106608811204142046600066790196940691100768682518506600601481676686828742807
11088849408310989234142475694298520575977312478025518391 my personal key
1024 37 1140868200916227508775331982659387253607752793422843620910258618820621996
941824516069319525136671585267698112659690736259150374130846896838697083490981532
877352706061107257845462743793679411866715467672826112629198483320167783914580965
674001731023872042965273839192998250061795483568436433123392629 my work key
These are RSA public keys: the first number in each entry is the
number of bits in
the key, while the second and third are RSA-specific parameters
called the public
exponent and
modulus. After these comes an arbitrary amount
of text treated as a comment. [Section 8.2.1, "SSH1 Authorization Files "]
For SSH2, you need to edit two files, one on the client machine and
one on the server machine. On the client machine, create or edit the
file
~/.ssh2/identification and insert a line to
identify your private key file:
IdKey id_dsa_1024_a
On the server machine, create or edit the file
~/.ssh2/authorization, which contains
information about public keys, one per line. But unlike SSH1's
authorized_keys file, which contains copies of
the public keys, the
authorization file lists
only the filename of the key:
Key id_dsa_1024_a.pub
Finally, copy
id_dsa_1024_a.pub from your local
machine to the remote SSH2 server machine, placing it in
~/.ssh2.
Regardless of which SSH
implementation you use, make sure your remote SSH directory and
associated files are writable only by your account:[10]
# SSH1, OpenSSH
$ chmod 755 ~/.ssh
$ chmod 644 ~/.ssh/authorized_keys
# OpenSSH only
$ chmod 644 ~/.ssh/authorized_keys2
# SSH2 only
$ chmod 755 ~/.ssh2
$ chmod 644 ~/.ssh2/id_dsa_1024_a.pub
$ chmod 644 ~/.ssh2/authorization
The SSH server is picky about file and directory permissions and may
refuse authentication if the remote account's SSH configuration
files have insecure permissions. [
Section 5.4.2.1, "Acceptable permissions for user files"]
You are now ready to use your new key to access the "pat"
account:
# SSH1, SSH2, OpenSSH; output shown is for SSH1
$ ssh -l pat shell.isp.com
Enter passphrase for RSA key 'Your Name <you@local.org>': ************
Last login: Mon May 24 19:44:21 1999 from quincunx.nefertiti.org
You have new mail.
shell.isp.com>
If all goes well, you are logged into the remote account.
Figure 2-2 shows the entire process.
Figure 2-2. Public-key authentication
Note the similarity to the earlier example with
password authentication. [Section 2.2, "Remote Terminal Sessions with ssh"] On the surface, the only difference is that
you provide the passphrase to your private key, instead of providing
your login password. Underneath, however, something quite different
is happening. In password authentication, the password is transmitted
to the remote host. With cryptographic authentication, the passphrase
serves only to decrypt the private key to create an authenticator.
[
Section 2.4.1, "A Brief Introduction to Keys"]
Public-key authentication is more secure than password authentication
because:
- It requires two secret components -- the identity file on disk,
and the passphrase in your head -- so both must be captured in
order for an adversary to access your account. Password
authentication requires only one component, the password, which might
be easier to steal.
- Neither the passphrase nor the key is sent to the remote host, just
the authenticator discussed earlier. Therefore, no secret information
is transmitted off the client machine.
- Machine-generated cryptographic keys are infeasible to guess.
Human-generated passwords are routinely cracked by a
password-guessing technique called a dictionary
attack. A dictionary attack may be mounted on
the passphrase as well, but this requires stealing the private key
file first.
A host's security can be greatly increased by disabling
password authentication altogether and permitting only SSH
connections by key.