Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a public/private key pair. I put the contents of my public key into my server's .ssh/authorized_keys file. When I SSH into it, it automatically recognizes my key and lets me in.

However, if I use the SAME public key, with a different private key, and try to SSH, the server doesn't let me in. How does it know which private key to look for?

Secondly, how can I change what private key it should accept for this specific public key?

share|improve this question
Incidentally, this doesn't really have anything to do with UNIX specifically; the question and answers are equally applicable if you're logging into, say, a Windows server via SSH. – David Z Jul 14 '14 at 0:31

how did you make a public key for two different private keys? afaik that's impossible with ssh-keygen. if you didn't (which I suspect), your problem is simply that you didn't understand the asymmetric key principle:

When generating the key pair, ssh-keygen generates a private and a public key, which match each other. you upload the public key to the server, and when connecting, ssh encrypts some information using your private key. then the server tries to decrypt it with the public key you gave to it, and if that works, it knows you have the correct private key matching the public key it knows, and so verifies that you are A) you or B) someone who stole your private key. in case A, everything is fine, in case B, it's simply your fault and you should be protecting your private key better :D


if you want to use two different private keys, just upload both their matching public keys to the server.

share|improve this answer

Each public key is compatible with exactly one private key, in the sense that a server or any other computer can use a public key to decrypt a message that was encrypted using the corresponding private key. However, knowing the public key does not allow the server to find the private key.1 The public and private keys are generated at the same time by ssh-keygen or whatever equivalent tool you use to make your keys.

As part of (a simplified "toy" version of) the SSH login process, the server makes up a string, called a nonce, and sends it to the client (your personal computer). The client encrypts the nonce with your private key and sends the result back to the server. Then the server tries to decrypt that result with each public key listed in the .ssh/authorized_keys file, and if it finds one for which the decryption process results in the original nonce, it grants you access. Note that at no point in this process does the server ever have access to, or know anything about, the private key.

Since each public key corresponds to exactly one private key, in a manner fixed by the key's encryption algorithm (RSA or DSA or ECDSA), you cannot change what private key the server will accept for a given public key. If you want to use a different private key, you need to generate the corresponding public key and put it in the .ssh/authorized_keys file as well.

1technically it could, but it would take longer than the age of the universe

share|improve this answer

You can have many entries in authorized_keys. I don't know the specific method used on the server side to match the key pair, but it works.

To answer the second more important question, you generate keys in pairs. They ONLY work with each other. You can't generate a new private key to go with a specific public key or in reverse, you must generate a new pair.

So if you have 10 users (for example), you could generate 10 key pairs so that when the time comes to lock out a single user, you can do so by removing the corresponding public key from authorized_keys, thus rendering the corresponding private key useless.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .