SSH Keys – Using SSH Keys with Multiple Computers

ssh

I have three computers: Windows desktop, Linux notebook and Macbook. From any of this computers I am connecting to my servers using SSH. To connect to remote server I use SSH-keys.

What is your approach to work in this case? Do you create separate SSH keys to each machine or use one pair of keys on each machine. If the answer is the second one where do you keep them and how do you deploy them on new notebooks/computers you have.

Best Answer

Can you use the same private key from multiple devices?

Yes.

There is no technical limitation on the number of devices where you can install and use the same private key.

Should you re-use private keys or generate a new key-pair for each device?

Although I am of the opinion that you authenticate to prove your identity and your identity is not tied to the device that you're currently using setting up new private keys for every system you use may be a good strategy. That may for instance help you keep access to work systems separate from other activities and prevent a cross-over from using a "work" laptop for your private projects and logging in to work from the family PC.

Using the same private key from multiple devices has a big advantage on ease of use, add the private key once on the new system and you're set up to access every remote system without further effort. It is also a convenient back-up when one system might break.

The more places where your private key is stored, the higher the risk of a compromise. The fewer keys you use, the more impact a compromised key may have.

You mostly mitigate that risk by securing your private key with a passphrase. (Which you should do regardless.)

To copy the shared private key from work station or laptop to another:

When you can (temporarily) run an ssh server on the new workstation:
Since there is no particular requirement to keep public key private: send the public key to the new workstation via any means, add it to the ~/.authorized_keys file and, using the private key to authenticate from an existing workstation, copy the private key over ssh to your new workstation (and optionally disable sshd again).
Copy the password protected private key to a USB thumb drive (or similar removable media) and wipe that afterwards.

When using separate private keys for each device, but you use all devices to authenticate to the same remote systems:

send the public keys of each workstation to the others via any means. (Note again that there is no particular requirement to keep a public key private.)
Use the trusted private key on an existing workstation to copy and add the new public key to all remote systems (with for instance ssh-copy-id -i new_key.pub)
(All systems I use allow me to use multiple public keys with a single account, but that may not universally be the case though)
When setting up authentication on new systems, add the public keys for all private keys that you're using, not just the public key associated with the workstation you're currently using.

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.