3

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..

  • Why does the load balancer balance all ports? It could only balance those actually supplying the balanced service, not SSH too. Or it might be feasible to dedicate a port range and, within that range, one port for every machine in the cluster. 2201 -> alice-1, 2202 -> alice-2 and so on. – LSerni Apr 23 '15 at 23:19
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!

  • This is our exact use-case! We are using it for RSync over ssh. After staring at it, for a while I realised why I had to share the key-pair. So you get my up vote :) – Sriram Venkatesh May 25 '15 at 2:40
1

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.

0

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.

  • Why do you say that not having control over which server you end up in is a problem ? Unless I miss something, that's the design goal of the cluster described by the OP – Stephane Apr 24 '15 at 8:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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