I am looking at this cluster of student work stations. They are diskless clients which boot from NFS. They also have sshd enabled.

All of these machines share the same ssh host key (rsa,dsa,etc), because they boot from NFS. As NFS is not encrypted, the private keys are transferred in clear text anyways. This is not a huge problem, because the machines are on a separate VLAN and in theory you can only sniff the packages if you are root, which is unlikely to be the case.

Besides this obvious problem (private keys transferred without encryption), is it a bad idea to share the host keys between those machines?

  • I'm not too sure this really is a security question, without you providing more detail. The fact you put it on SU first makes me think you are asking from the POV, can there be issues such as conflicts when multiple hosts use the same key? (Not AFAIK, but I'm not confident enough to answer in place of a SU expert.) The security situation is difficult to answer without you telling us the purpose of the keys and the access controls on them.
    – deed02392
    May 7, 2014 at 10:00
  • Well, the keys are ordinary SSH keys, so they are part of the authentication of the machine I want to connect to. I am no expert in this, but normally the (host name, host key, host ip) tuple identifies a machine when you connect to it (the host ip is optional, but you get a warning by default by OpenSSH if it changes, and you can make it an error). So if I share the host key between machines I have one indication less, when, for example, a MITM attack is going on. But is this really bad and what other things would I have to be aware of?
    – user46168
    May 8, 2014 at 13:42
  • Well what that means is that if you think you're connecting to a specific one of those student workstations, you could actually be connecting to any other one of them, if they're redirecting traffic, since it's the same keypair. But not sure what benefit that would give them, unless they want you to get a headache. I cannot see much of an issue with this to be honest. There are probably more serious security issues in such an environment, if disk data is being transmitted in plain-text.
    – deed02392
    May 8, 2014 at 16:11
  • 1
    There are many legitimate situations where you want to share SSH keys between several machines. For example, here we have a round-robin of 8 machines which clients connect to over SSH. All 8 machines have the same key so that users only have to accept the key once.
    – Moshe Katz
    May 14, 2014 at 15:13
  • A better question might be WHY do diskless workstations have SSHd on them? I assume it enables either instructor access during a learning session or some form of central data backup? In the former case, I can't see that any security is really an issue (unless the students are doing secure work during a session). In the later case there are probably better approaches. May 19, 2014 at 15:28

3 Answers 3


The private key is the distinctive power of each machine. Having distinct keys for the machine makes sense, from a security point of view, only if the machines are not equivalent to each other. As you note, if an attacker obtains full control of one machine, then it can spy on the network and observe the files of all other machines, including their SSH private keys. It could also simulate the bootup procedure of any other machine, using the MAC address for that machine at the BOOTP/DHCP/whatever stage, and obtain all the secret values of that other machine. In short words, hijacking one machine can easily be expanded into hijack of all the machines. In that context, per-machine private keys would not buy you anything more.

If you want better security, including some isolation layer which would make machines not equivalent to each other, then you will need some heavy artillery. NFS is built over RPC, and there is an extension called Secure RPC which allows for encryption of all the data; however, it is old, poorly supported (I am not sure Linux supports it, for instance), and poorly maintained (if at all). A newer and arguably better method would be IPsec. Alternatively, one can encapsulate the NFS traffic into SSH, as explained in section 6.4 of this document. This raises interesting chicken-and-egg questions: how do you setup some SSH (or IPsec) in order to tunnel NFS in it, if you already need the NFS to obtain the SSH (or IPsec) private key ?

This is a rather generic point. Diskless systems are diskless. As such, they are, when shut down, identical to each other. Since a diskless machine cannot permanently store anything, it cannot contain any secret value which would give it some power denied from other machines. Consequently, all the diskless systems can be "emulated" from other diskless systems, in the bootup procedure, as alluded to in the first paragraph. Therefore, you cannot really create a context where the diskless machines would be really distinct from each other; as a corollary, you don't need to make the SSH private keys distinct.

Some notes, though:

  • If you can arrange for each diskless machine to have some local storage, e.g. a SD card on which it boots up, then you can put machine-specific secret values in there; and then you can have per-machine SSH private keys. Simply, the private key is read from the SD card, not from NFS, and private keys cease to travel unprotected on the wire (they cease to travel at all, which is even better).

  • Theoretically, you can get replace such local storage with human storage: arrange it so that a trusted sysadmin presides at each bootup, and enters a long secret password in order to unlock the machine secrets. I am not aware of existing software which would allow that, but there is no conceptual limitation. Except, of course, the need for the physical presence of a sysadmin every time a machine must boot or reboot, which is likely to be an unbearable constraint.

  • Don't put too much trust in VLAN. There are several protocols for that (standard and proprietary), but most are unprotected: frames are tagged by switches so that they know whether a frame should be shown on a specific wire or not. If an attacker gets physical access to one of the switches, or to a wire connecting two switches together or one of the VLAN-able machines to a switch, then he will get full access to the VLAN contents.

  • These are students. Compromise of a machine at some point is a certainty. One of them will unplug a machine, plug his own laptop in its place, configure the laptop to assume the IP and MAC addresses of the unplugged machine, and read all the files. This is easily done, in less than a minute, with generic OS tools. This goes a long way to say that if the students are attackers, then you are doomed. You can try to deter them with physical shielding (don't leave wires accessible in any way) and threats (trespassers will be beheaded and their corpses put on display), but this won't ultimately work. A better method, that I saw employed with success, is empowerment: monitor things so that you identify students who seem to be interested in security, and give them official admin power. They will not hack into machines that they already have root access to; and you can make them co-responsible for security, so they will cooperate in tracking trespassers.

  • A very common method for security is not caring. Just let the diskless stations become a godless wilderness, and filter things at the periphery. Students are creative and prone to test security, but they also get bored pretty quickly. Whether that method is good is an open question, but at least it is very easy to implement.

  • While Linux probably lacks support for the DES "Secure RPC", it does support Kerberos 5 instead.
    – grawity
    Jul 17, 2015 at 7:23

yes, its always a bad idea to share keys inbetween machines without (proper) encryption.

its highly unlikely someone will plugin into that network and sniff out data with the key, but please bear in mind that mobile devices, or any other devices are still vulrenable to malware/virusses etc., this can mean that the can sniff out data if its not protected well enough.

and you are woring with students, im a student myself, so i can assure you there are students that will do their best to disrupt any security limiting their actions, attach mobile devices, or even break stuff, since that is what students do.. so the physical risk is present here too.


Yes, it is a bad idea.

The point of an SSH host key is for the client to verify that it connected to the correct server. If multiple servers share a host key, the client can't do that.

It's not just that the client can't tell which of those machines it's connected to; since the secret keys aren't really a secret, anyone with physical access can connect their own device and pretend to be one of those workstations. Unique host keys wouldn't solve that problem, but it would force an attacker to pick one. (If the attackers device can adequately impersonate a workstation during the boot process, not transmitting keys in the clear also isn't enough to close that vulnerability.)

Weather this is actually a problem may depend on how these workstations are used and how the interact with the rest of your network. Either way, key management for these workstations should fall under the same policy as key management for other SSH hosts on your network.

You must log in to answer this question.