Ssh – How bad is it to have multiple devices with the same SSH server keys

embeddedfreebsdinternet-of-thingsssh

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.

Best Answer

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.

Related Solutions

SSH – Stop Client from Offering All Public Keys

This is expected behaviour according to the man page of ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity is read.  The default is ~/.ssh/identity for protocol
         version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for
         protocol version 2.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

Basically, specifying IdentityFiles just adds keys to a current list the SSH agent already presented to the client.

Try overriding this behaviour with this at the bottom of your .ssh/config file:

Host *
  IdentitiesOnly yes

You can also override this setting on the host level, e.g.:

Host foo
  User bar
  IdentityFile /path/to/key
  IdentitiesOnly yes

Ssh – How to automate SSH login with password

Don't use a password. Generate a passphrase-less SSH key and push it to your VM.

If you already have an SSH key, you can skip this step… Just hit Enter for the key and both passphrases:

$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.

Copy your keys to the target server:

$ ssh-copy-id id@server
id@server's password:

Now try logging into the machine, with ssh 'id@server', and check-in:

.ssh/authorized_keys

Note: If you don't have .ssh dir and authorized_keys file, you need to create it first

to make sure we haven’t added extra keys that you weren’t expecting.

Finally, check to log in…

$ ssh id@server

id@server:~$

You may also want to look into using ssh-agent if you want to try keeping your keys protected with a passphrase.

Best Answer

Related Solutions

SSH – Stop Client from Offering All Public Keys

Ssh – How to automate SSH login with password

Related Topic