22

I am working on an embedded device that runs FreeBSD and SSH.

As you know, sshd likes to randomly generate a set of server keys when it first boots up. The problem is that we will be shipping the product with a read-only sd-card filesystem (non-negotiable).

My two options as I see them are:

  • Ship the same sshd server keys on all devices
  • Mount a memory file system and generate the server keys on each boot (slow...)

Is it a major security problem to ship the same server keys on all devices? These items will not be directly on the internet. There will occasionally be multiple devices owned by the same person and on the same network.

Most of the time the device will not be connected to the internet.

Logging in with SSH is not part of normal operation. It is mostly for the convenience of the programmers and technicians. Customers will not be logging in to the device with SSH.

What are the ramifications of using the same server keys on multiple hardware devices?

PS could someone please create an internet-of-things tag?

EDIT: I am talking about installing the same host private keys on all servers (devices). As far as user public/private keys, there are currently no plans to use key based login - it would be password login. Again, same password on all servers (devices).

I know that this is probably a bad idea. I'd like to know why precisely it is a bad idea though so I can understand the tradeoffs.

NXT
  • 371
  • 2
  • 7
  • If you mean the host keys, then users with more than one of your device may get warnings depending on their ssh client configuration. the bigger concerns would be around actual ssh authentication keys. Hopefully you are not installing any private keys and hopefully your public keys are restricted to specific source networks and hopefully your private keys owned by your techs have a strong passphrase on them and hopefully those keys are never checked into a repo by mistake. IoT's are getting a really bad name because of those things. Not saying you would, just saying that is a big issue. – Aaron Dec 04 '16 at 17:49
  • I am talking about installing the same host private key on all servers, if that is what you mean. – NXT Dec 04 '16 at 18:00
  • 2
    Using same username / password on all devices is a very bad idea. Those are way easier to brute-force than the private key used for public key authentication. Even if these deviced aren't supposed to be directly connected to the internet, someone will do it anyway. And if "not directly connected" means NAT, they are connected enough... – Tero Kilkanen Dec 04 '16 at 19:06
  • Tero, yes, I do mean NAT, can you elaborate on the risks? – NXT Dec 04 '16 at 19:25
  • 7
    Sharing the SSH key means that someone who can access the private key on one device can impersonate all of these devices. – user253751 Dec 04 '16 at 23:44
  • 3
    While this is an interesting question, I don't see anything about it that relates to system administration, and is thus off-topic for Server Fault. You're asking about designing an debugging/diagnostic interface for an embedded device that you are shipping, and not an interface that would be relevant to sysadmins. This question could be migrated to [security.se]. – 200_success Dec 05 '16 at 08:43
  • @200_success It's a question about managing sshd security on a non-PC unix platform. That seems relevant to me. However thank you for pointing out the security stackexchange site, I was unaware that it existed. – NXT Dec 05 '16 at 19:11

6 Answers6

27

Rather than storing host-specific data such as ssh host keys on the SD card or other read-only media, you can store this in NVRAM, which is what it's for on an embedded system. You'll need to do some custom scripting to store and retrieve the keys at boot time, but the scripts will be exactly the same for every device.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
12

The impact of shipping the same key pair with all your devices is directly related to the security of the clients connecting to them, as it means that there is no way (from an SSH client) to uniquely identify the device it may be connecting to. Should your key pair be leaked, it could be used for MITM attacks.

On the other hand, regenerating the keys on each boot, will also trigger an alert on the clients.

For reference, from man ssh(1):

ssh automatically maintains and checks a database containing identification for all hosts it has ever been used with. Host keys are stored in ~/.ssh/known_hosts in the user's home directory. Additionally, the file /etc/ssh/ssh_known_hosts is automatically checked for known hosts. Any new hosts are automatically added to the user's file. If a host's identification ever changes, ssh warns about this and disables password authentication to prevent server spoofing or man-in-the-middle attacks, which could otherwise be used to circumvent the encryption. The StrictHostKeyChecking option can be used to control logins to machines whose host key is not known or has changed.

dawud
  • 14,918
  • 3
  • 41
  • 61
5

It sounds like in the first option, the SSH keys would be available on the SD card. So any user could take the card and read them out. So basically your private keys have become (mostly) public.

This will allow man-in-the-middle attacks, like the following:

  1. A user sets up a SSH server with the private keys obtained from your device and gives that IP address to your technician.
  2. Your technician inputs the root password over the SSH connection.
  3. The user now knows the root password that is valid for all your devices.

However, you shouldn't be using root passwords in the first place, use ssh keys for authentication instead. Then the impact of shared server keys is pretty small if you only log on from a LAN.

SSH also provides forward secrecy, so an attacker has to be able to setup a false server to benefit from the keys; passively sniffing the traffic will not allow decrypting it.

jpa
  • 184
  • 3
  • It's funny how our preconceptions can blind us (me). The SD-Card is inside the unit behind a panel and underneath a circuit board, so it never occurred to me that someone would pull it out. However, you are correct, it absolutely is accessible to anyone with a screwdriver. Thanks for the reminder to consider the physical security of the system. – NXT Dec 05 '16 at 19:14
  • WRT #2, the root password should not be sent over the SSH connection. It should be input into the terminal client, and used for the local half of an authentication protocol that proves possession of the secret without transmitting the secret ("knowledge proof"). Even decades-old systems knew to send a hash of the password and not the password itself. Include a nonce in the challenge/response protocol, and the attacker neither knows the original password nor any token that can be used in its place. – Ben Voigt Dec 06 '16 at 00:05
  • 1
    @BenVoigt I think that most unix systems do transmit the password to the server. The shadow file stores only a hash, but you don't want to trust a hash generated by the client - because otherwise anyone would be able to login with a stolen hash, without reversing it. So the server has to know the actual password in order to run bcrypt or similar on it. – jpa Dec 06 '16 at 07:15
2

I read this in horror! I who have done multiple machines in the same cluster with the same ssh host key would never dare do this. Do not under any circumstances allow machines with different sets of administrators to share ssh host keys. That way lies madness and screaming horror when you get posted for your lack of security.

Behold I tell you the truth, he who compromises one device compromises all of them. Once obtained one, expect bad people to jump from one to another at will and the security rolled back as though it were thin paper.

joshudson
  • 403
  • 4
  • 10
  • 1
    Could you elaborate on how an attacker would use a stolen server private key to compromise other devices? – jpa Dec 06 '16 at 07:16
  • @jpa: For host keys, by intercepting and stealing passwords, etc. Also, this setup seems to propose doing the same thing with user keys. – joshudson Dec 06 '16 at 16:11
1

Since you mention that the SSH access is not used by the end user/customer you may want to turn off SSH access by default and only enable it temporarily when the device is put into "debug" mode.

You can then either ship all the devices with the same key, assuming that you have protected the "debug" mode so it can't be triggered remotely by someone trying to hack the device.

Or you have a new key generated when the device goes into "debug" mode - so you don't have to waste boot-time generating the keys each time the device is powered up.

Edders
  • 111
  • 3
1

Here's a sample attack scenario based on the constraints you have:

If your devices are, say a Raspberry Pi's for example. If I walk up and yank the SD card from one, I can stick the SD card in my own computer, find the sshd key and copy that to everywhere I want. Maybe I grab my own raspberry pi and a USB ethernet card. Now I can stick that in between a target device and wherever they're going and monitor for ssh connections. When I see that the target device is trying to make an ssh connection, I do this:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

Oh, what's that? Your password is "I like cats"? Boy, this is an interesting email you sent to your wife. I bet it would be even more interesting if she read this email that you sent to your next door neighbors wife.

The possibilities are endless. And the target would never know, because the sshd key is identical to the one found on the real server. Depending on the physical security of the facilities that are receiving your device, this could be incredibly trivial. Don't do this.

Instead, do what you already propose but fix it. Before you write your image run something like this: 

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

And now every server has a new key. Because you really, really don't want to be distributing copies of a key. I mean honestly it's at least as bad as snapping a picture of your house keys and uploading them to the Internet with your home address.

Wayne Werner
  • 709
  • 4
  • 14
  • 26
  • 1
    If someone has physical access to your hardware and you fail to encrypt the data at rest then all bets are off. – user9517 Dec 06 '16 at 12:53