Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm doing an assessment of a small network that is using a good bit of virtualization. They have cloned some of their linux machines after generating their SSH server host keys. So the servers all have the same host key. I'm certain this is bad, but I can't explain why. Can you explain why this would be or provide an example of a scenario in which this could be exploited. Or is it just a case of bad practice?

share|improve this question
    
It would be great if you could formulate what exactly is your question. –  Simon Aug 28 '13 at 0:44
    
revised .. Thanks. –  user896117 Aug 28 '13 at 1:34
add comment

3 Answers

This could be bad if one machine was compromised and the attacker was able to steal the key. They would then be able to impersonate any of the other machines without tipping off the users with a host key change warning when they next attempted to log into the malicious host. If there are other security mechanisms in place on the network then this threat could be largely mitigated.

share|improve this answer
add comment

The more a private key is shared, the less private it becomes. This is just a generic assessment: in some situations, this can be harmless. What it means in the specific case of SSH servers is that the security of these three servers becomes an all-or-nothing system:

  • Each server knows enough to impersonate any of the others.
  • If one of the server is hacked into, the attacker learns the shared private key and can impersonate any other of the servers.

Sharing the private key, on the other hand, can have real benefits:

  • As you observe, it happens "naturally" in some cases of VM cloning.
  • If routing is dynamic in some way (e.g. there is load balancing), a given client system may not always fall on the same machine for the same name; in that case, if the relevant nodes do not share the same private key, then the client will shout and scream and complain.
  • When a client connects to a given server for the first time, that client has no saved public key for that server yet, so the human user is supposed to check the server key fingerprint against an authoritative source (e.g. a phone call to the sysadmin). If all servers share the same private key, then the single fingerprint can be printed out in big letters and glued to the office walls; this is much less practical when there are many servers and each of them has its own key.

Sharing the private key is thus a definite "no way" thing when the machines are not meant to be equivalent to each other with regards to security. However, when they are equivalent, sharing the private key can make some operations simpler. Sharing the private key MUST be done when some forms of load balancing are employed (although load balancing and SSH rarely fit together). Sharing the private key can be considered "acceptable practice" when all the systems are elements of a big computing cluster.

share|improve this answer
add comment

Yes this is bad. As was said previously, if one host gets compromised, then any other hosts with the same private key would need to be rotated to prevent MITM attacks.

A better strategy would be to create the key after the host was stood up, or generate a new key after imaging. Take a look at what some of the big guys do (AWS, linode, etc) for ideas on how to provision many different VMs securely.

share|improve this answer
add comment

Your Answer

 
discard

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.