The ssh client will check all your keys until it finds one that matches.
This is how it works (this is very simplified, before this a quite complex dance has been made to encrypt all of this):
- The server creates an auth token.
- The token is encrypted using your public key on the server.
- The server send the encrypted token to the client.
- The client tries to decrypt the token, using all known private keys.
- If it is successful it will send the decrypted token back to the server.
- If the token matchs the server will let the client in.
What files are keys depends on the client.
For the Openssh client (Ubuntu default client), according to its man page, the files that are supposed to be private keys are ./sshid_rsa, .ssh/id_dsa, .ssh/id_ecdsa, plus those given after the -i flag (it supports multiple files) and those declared in the config file.
You can give it the -v option to make it print a line when it tries to use any file as a key. This is an example from a non-key login:
$ ssh -v www.hostremoved.com
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
<...>
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/javier/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/javier/.ssh/id_dsa
debug1: Trying private key: /home/javier/.ssh/id_ecdsa
debug1: Next authentication method: password
<...>
As you can see, it prints all the keys it tries, it fails all. You can use this in your system to discover what files is ssh using in your own system.
Below you can see the output if some existing key is found and tried
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: user@xyz
user@xyz is the information appended to the public key.
If you're wondering how your ssh client finds your private keys, it's not magic. Under Gnome (xfce and KDE also) there is a special ssh-agent that automatically adds keys in .ssh directory that have a correspondending public key with the ending .pub.
If you not have such a comfortable ssh agent, you'll have to add your private keys with ssh-add key.
Unsetting SSH_AUTH_SOCK is a workaround, but doing so disables ssh-agent, which some people might still want to use.
It seems that ssh-agent can't sign anything with the private key because it doesn't properly decrypt it when automatically adding this key to the keyring.
If one generates the standard id_rsa identity file in ~/.ssh, or stores a private key along with its public key in ~/.ssh, ssh-agent automatically adds this to its keyring. But when doing so, it doesn't prompt for a passphrase, it doesn't ever decrypt the key.
The solution is to add the key manually. Remove all pkcs#8 encrypted keys from the ssh-agent using ssh-add -D and move private+public key files out of ~/.ssh. reboot or ssh-agent -k, then move back your pkcs#8 encrypted PRIVATE key to ~/.ssh. Using ssh-add, one is prompted for the decryption passphrase. ssh-agent can now access the unencrypted private key, and therefore sign stuff with it.
(via Damon Dransfeld)
Best Answer
ssh-adddoesn't store anything locally or remotely on disk. This command loads your private key, asking once for its password, into the SSH Agent that was previously started.The SSH Agent holds the private keys in memory only. When you launch the SSH client, it uses the private key from the SSH Agent, without asking for the private key password again, to authenticate against the target server.
The
.sshdirectory will contains (in the home directory of any user) :authorized_keys: list of public keys allowed to be used to connect to this serverconfig: optional file with configuration parameters for the SSH clientknown_hosts: maintain a list of hosts to which you already connected together with a hash to detect if the host key has changed since the last time.