WARNING: Private keys must be kept secret. An intruder with your private key can access your account as easily as you can.The public key represents your identity for incoming connections to your account. When an SSH client requests access to your account, using a private key as proof of identity, the SSH server examines the corresponding public key. If the keys "match" (according to a cryptographic test [Section 188.8.131.52, "Public-key authentication"]), authentication succeeds and the connection proceeds. Public keys don't need to be secret; they can't be used to break into an account. A key pair is typically stored in a pair of files with related names. In SSH, the public key filename is formed by adding the suffix .pub to the private key filename. For example, if the file mykey holds a private key, its corresponding public key is found in mykey.pub.
In contrast, some Windows implementations such as F-Secure SSH Client store keys in the Windows Registry.
In fact, in SSH1, the so-called "private key file" contains the public key as well, for completeness, and only the part of the file containing the private key is encrypted with the passphrase. But the private key file is in a private binary format; the public key file is there for human convenience, to make it easy to add the public key to an authorized_keys file with a text editor, for example.You may have as many SSH identities as you like. Most SSH-1 and SSH-2 implementations let you specify a default identity clients use unless told otherwise. To use an alternative identity, you must change a setting by command-line argument, configuration file, or some other configuration tool. The structure of identity files differs for SSH1, SSH2, and OpenSSH, so we will explain them separately. Their locations in the filesystem are shown in Figure 6-2 (private keys) and Figure 6-3 (public keys).
This default may be changed with the IdentityFile keyword. [Section 7.4.2, "User Identity"]
You may recall that SSH2 supports PGP key authentication. [Section 184.108.40.206, "PGP authentication"] The identification file may also contain PGP-related keywords:# SSH2 identification file # The following names are relative to ~/.ssh2 IdKey id_dsa_1024_a IdKey my-other-ssh2-key # Absolute paths work for SSH2 2.1.0 and later IdKey /usr/local/etc/third-key
Using a separate identification file might seem cumbersome, but it provides flexibility SSH1 doesn't. As we've said, it permits an identity to contain multiple keys, any one of which may authenticate you. Another advantage of the SSH2 system is ease of deletion. To remove an SSH2 private key from consideration, simply delete or comment out its line from the identification file. To accomplish the same task with SSH1, you have to rename the private key file. Like SSH1, SSH2 has an authorization file for incoming connections but with a difference. Instead of containing copies of public keys, the SSH2 authorization file merely lists the public key files using the Key keyword:# SSH2 identification file PgpSecretKeyFile my-file.pgp IdPgpKeyName my-key-name
This is easier to maintain than SSH1's authorized_keys file because only one copy of each public key exists. For SSH1 and OpenSSH, in contrast, there are separate copies in the .pub and authorized_keys files. [Section 8.2.2, "SSH2 Authorization Files "]# SSH2 authorization file Key id_dsa_1024_a.pub Key something-else.pub
|5.10. Summary||6.2. Creating an Identity|
Copyright © 2002 O'Reilly & Associates. All rights reserved.