Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have two websites. One website is a clone of the other website. When I checked the sshd_config file in both the sites they are exactly similar, except one uses authorized_keys as the identification and the other uses Known_keys as the identification, I hope this is not a problem since the path are defined accordingly showing the location and the file name of the public key.

I am wondering why am I not able to login with the same private key of same machine whose public key is up in the both servers.

Am I missing some information? Or it's not possible?

share|improve this question
Please try and learn from how I pulled apart your original question into three separate questions. Asking very pointed and one-dimensional questions like the ones I extracted from your question is more likely to yield helpful answers. In an ideal world, you would have created three SU questions, one for each of the questions in my answer. Having a lot of questions on SU isn't a problem, as long as the questions are good, answerable questions, and the answers are high quality and well documented. –  allquixotic Jul 26 '12 at 17:38

2 Answers 2

up vote 10 down vote accepted

This question is actually three separate questions.

Question 1:

Is it possible to use the same keypair for SSH access to two or more servers?

Answer 1:

Yes, it is possible, many people (self included) do it regularly. There is no reason why it would be in any way limited to one server. We're assuming that you're talking about client keypairs and not server certificates. A client keypair authenticates the client, i.e. the machine attempting to gain access to an SSH session. You can most definitely re-use your client keypair, and one server will be none the wiser that your keypair is used on other servers.

Question 2:

Is it recommended to use the same keypair for SSH access to two or more servers?

Answer 2:

Depends on who you ask, and how rigorous your security plan is. There are added risks of using the same keypair for two or more remote hosts. These risks are above and beyond the nominal risks of using a keypair at all for one host.

Anyone obtaining your private key (as well as the private key passphrase, if applicable) will be able to access all systems that your private key authenticates. The problem then devolves to the attacker knowing the hostnames of all the servers that your private key is authenticated to, and the user accounts on each of those hosts that consider your public key an authorized key. This increases the potential damage that can be done in the event that your private key is stolen.

Note that it is not an authentication risk if someone obtains only your public key: for all you care, you may as well put your SSH public key up on your homepage. You can even safely post it here in your question just for kicks and giggles, with absolutely no security implications. It's called public for a reason.

If you have any reason to suspect that your private key is anything but completely secure, and you are worried that the damage would be significantly greater if both systems were compromised, then you can create two private keys. But, if you store both private keys on the same system, and they either have no passphrase, the same passphrase, or the passphrases themselves are stored somewhere (a piece of paper, LastPass, etc) in the same place, then having two separate keypairs is not actually adding any security. But if you use full disk encryption and have a well-secured client system, then the risk of having your private key and passphrase stolen is relatively low.

By the way, if you are using private keys without any password at all, then you better not be doing anything worth more than a few dollars on your systems. If you're conducting any sort of official business, commercial or otherwise, in my opinion it is absolutely essential to use a strong, unique password that is not written down anywhere for a private key that gains access to any system of value. If you're dealing with customers' personal information (credit card numbers, etc), make that "absolutely essential" up there in 72 pt font and 10 times bolder. If you're dealing with government classified information, make that "absolutely essential" in 5000 pt font and 5000 times bolder.

Question 3:

Why doesn't my public key authentication work?

Answer 3:

This depends on your specific setup. You didn't give us any specific details about why it doesn't work. We need specifics. Error messages, detailed logs (but omit passwords and usernames and IP addresses!), and a list of the software and versions you're using for both the SSH client and the SSH server, and the operating system and version of both systems.

However, I strongly suspect that one reason why it isn't working is that you're using the wrong file on one of the systems. known_keys is not for public key authentication; it's for the SSH client (the client on which the known_keys file resides) to cache the public keys of the servers that it connects to. You should be using authorized_keys on both systems. (Kudos to the other person answering your question for posting this fact a few seconds before me :))

share|improve this answer
Thanks for the detailed explanation, that really helped in my understanding. In order to resolve the issue I think, I have to upload my sshd_config file itself. –  tough Jul 27 '12 at 10:40
What do you mean by upload your sshd_config? If you do upload that, it'll need to go in /etc/ssh directory and overwrite the one already there. But you certainly shouldn't store any public/private keys or anything like that within sshd_config... just making sure you didn't think that was the purpose of that file :) –  allquixotic Jul 27 '12 at 13:06
By upload sshd_config, I mean to edit my question adding all the information on the sshd_config as well a 'ssh -v' after some edits as suggested by you. I need some suggestion form known user like you, if I should ask that in another question or edit this one itself, I don't want to be banned from asking question here as well, like in [stackoverflow] (stackoverflow.com) some days ago. –  tough Jul 27 '12 at 13:56

known_keys and authorized_keys are completely different stuff.

The authorized_keys file is where you must put the public keys which match the private keys you are going to use to access the server. It is supposed to be on the servers you want to get into.

known_keys is a file where the remote servers' fingerprint is stored so you know that if you try connecting there again it is really the server you expect to be. That is to prevent man-in-the-middle attacks, where someone could spoof the hostname or IP address of the remote server to steal information you might supply thinking you were connected to the right one. This file is automatically created or updated when you try to connect somewhere new, so note it is related to SSH operation as a client. If you see this file on your server you probably tried to connect from it to somewhere else.

share|improve this answer
Your answer is helpful, and most likely nails the technical issue that is preventing the OP from successfully authenticating to the server that is (mis)-using the known_keys file. I +1'ed it but I'm hoping that my longer answer is more helpful overall because it contains answers to all three of the OP's implied questions. –  allquixotic Jul 26 '12 at 17:35
Sure @allquixotic, thanks. You really took some time to write such a comprehensive answer. +1 for you too! :) –  Claudio Jul 26 '12 at 17:39
@Claudio Thanks, for the answer. Now turning to connection problem, I have asked another question, with some debug file and sshd_config –  tough Jul 27 '12 at 15:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.