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?

  • It would be great if you could formulate what exactly is your question.
    – Simon
    Aug 28, 2013 at 0:44
  • Advise them to delete the ssh host key on the golden image...
    – ThoriumBR
    Sep 9, 2019 at 1:03

5 Answers 5


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.

  • "so the human user is supposed to check the server key fingerprint against an authoritative source" this virtually never happens. I'm right now lost trying to understand if running ssh-keygen on a shared host is a bad idea. Would like to do it for this reason though...
    – Milind R
    Dec 23, 2014 at 17:33
  • It's also a good idea on cluster hosts, because if you don't every single ssh implementation I'm aware of will throw a fit if you try to connect to the shared IP when a different host has the master flag set... May 22, 2015 at 7:50

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.


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.


Even without access to the private keys(which the other answers do a good job of covering), just access to a public key can be a problem. For example, Shodan.io can be used to search for public keys, so if you share a host keypair over a bunch of IOT devices, and do something silly, like leave a default password on, it becomes trivial to locate all publicly addressable devices.


I'm going to answer differently.

If what you are creating is a "single system image", having a shared server key is the only way to effectively do that -- all network instances of all of the servers must appear to be one, and only one, server.

The implications of that are as the other answers have mentioned, which is also consistent with the concept of a "single system image". If a server had 4 network interfaces and one of those 4 were compromised, the entire server would -- of course -- be compromised. What you have is some number of physical or virtual instances, instead of some number of network interfaces.

There is nothing "wrong" with doing this, but it does require that you NEED to do this, and aren't just being lazy (don't just be lazy ...) AND you ensure that the systems protect themselves from this kind of cascading compromise.

TL;DR - If you don't have an absolute need to do this, don't do it.

  • 1
    I would suggest that you only share a host key pair if you are using high-availability clustering software such as Veritas Cluster Server or Red Hat High Availability, and confine the host key pair to members of a single cluster. Also, should the shared key be compromised, it must be replaced on all cluster members at once. Sep 9, 2019 at 21:40

You must log in to answer this question.

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