Sharing a common public and private SSH keys for a cluster of machines

Question

I guess this is way to settle an internal debate I am having with myself.

In my provisioning process, I am wanting to share a common public and private ssh keys for each machine in a clusters, (because these are behind a loadbalancer, and I don't want to get key mismatch errors) And an internal twitch, is telling me that is wrong. The correct way would be to generate a private key, for the client, and add the public key to the authorized_key file?

I am not able to reason properly why sharing a common key pair among all the nodes in the cluster is bad. One that does come to mind is the fact, it only takes one machine to be comprimised. What would be a use case where we will want to use option one? Or is it totally frowned upon.

A description of the requirement: If we have Bob, wanting to connecting to a cluster of Alices', we want to bob to be able to connect to each Alice in the cluster of Alices..

Answer 1

To answer your question, yes, you can share the host key on all the servers in your load balanced pool. Then, you do the host key verification once for the IP/DNS entry you are load balancing and it will log into any of the pool members from then on without asking you again.

Before I go any further, for those wondering why you would do this. This may not be about controlling the servers (administration). It might be about using scp/sftp to send files and then likely some sort of scheduler/job application on each pool member.

It's not necessarily about balancing the load either. You might be interested in this set up if you are going for high availability, for example.

Anyway, let's pretend you have registered myapp.mycompany.net to 10.12.77.77 and this then round robins to 8 servers. You share the host keys between all 8 servers and then ssh myapp.mycompany.net, it will ask you to confirm, and then you are set. Now you can scp/sftp/whatever you are trying to do to the DNS entry and it will not ask you when it goes to a new pool member.

Hope this helps!

Answer 2

I don't think this should be an issue - using a single key pair to access many servers is perfectly fine and most of the world works that way.

Its important to understand, as @Tom Leek mentioned, that the private part of the key - which must stay secret - is only stored on your single machine and is never transfered out of it. So even if one of the servers is compromised (in a way other then someone stealing your private key), there is no way that this access can be used to gain SSH access to the other servers (although likely the attacker used an exploit that will work just as well on all the other servers as they have identical configuration).

I do have to note that your use of a "Load Balancer" to access the servers over SSH seems suspect to me: "Load Balancer" usually denotes an IP-level or TCP-level access control such that the client connect to a single IP and each time gets assigned a different backend. This is not an accepted way to connect to SSH, because you will still get a host mismatch error when the client tries to verify the host key regardless of your login key (unless you init all hosts with the same host key, which I think is a poor choice). A likely configuration is that you will use a DNS round robin configuration to address all servers as the same name, where each time it resolves to a different IP. In such a setup the client can verify each IP separately and you will not get an error.

Answer 3

Client and server keys live in different worlds -- the client key is verified by the server, the server key is verified by the client. Your problem at hand is about having many servers and one client, and key sharing between servers. What you do with the other world (the client key and the authorized_keys file) is irrelevant; it has no impact on that question.

I am tempted to say that the biggest problem with this key sharing is not that the key is shared; it is why you want to share the key. You want to share the key because you don't know to which of the servers you are going to connect. And that is the problem: you are doing a SSH through a load balancer that will send you to one of the servers, but with no control on which one you end up. This is not what you want. You want to be able to do a SSH to all servers, not just a randomly chosen one. You cannot have that if you load-balance the SSH connections.

If you want (as I believe) to be able to control all your cluster machines individually, then you must have a way to connect to any of them specifically, and possibly (probably) several at the same time. This means using their non-shared specific IP addresses, or, as @Iserni suggests, distinct ports (if you must SSH "from the outside" and have only one IP address available). At that point, the key sharing is less important. You may still want to share the key for other reasons (e.g. creating all machines from an already configured image; or automatically creating an already populated .ssh/known_hosts for your client). Key sharing between servers implies moving the private key around, which is, in all generality, a not very good idea; but machines from a cluster are probably close together and one may assume (or at least hope) that they can talk together without being spied upon by outsiders.

You may also want to investigate the tools linked from that answer.