Title: One SSH Key Per Machine!

Author: Bob Schmidt

Date: 05 September 2018 18:32:49 +01:00 or Wed, 05 September 2018 18:32:49 +01:00

Summary: Silas S. Brown has some advice on configuring secure connections.

Body: 

I recently had a small nightmare when my private SSH key was compromised. I had left it on a system I trusted, but due to a mistake made by (apparently) a newly-employed system administrator, the entire contents of my home directory on that system, including the private SSH key, was made available for public download for a few hours and they didn’t have logs to show whether or not it had been downloaded. So I had to quickly contact every server on which I’d ever placed my public SSH key and either change it myself or ask them to revoke it (I had to ask them in cases where the server was offline or otherwise unreachable but I was concerned it might be put back online later).

I now have a different private SSH key on each system. Instead of thinking of the private key as ‘my key’ that identifies me as an individual, I now think of it as identifying the system (well, my account on the system) that I’m using. I may have to add multiple public keys to each .ssh/authorized_keys file on the servers I have access to, but I have much more fine-grained control over which of my clients can access which servers, which should hopefully reduce the hassle next time we find a breach (if server X trusts client Y but not client Z, then I don’t have to bother updating server X when I’m told client Z was compromised).

My .ssh/authorized_keys files now look like:

  ssh-rsa long_key_here client1
  ssh-rsa long_key_here client2

where client1, client2 etc can be any strings I like (the third field of these files is ignored by sshd), so I simply use them to name the machines on which the corresponding private keys are stored. Each key is, of course, generated by running the ssh-keygen command on the corresponding client (there’s no point running it elsewhere), which creates .ssh/id_rsa (the private key) and .ssh/id_rsa.pub (the public key) – I then edit the public key file and make sure the label is what I want it to be, before copying it to the .ssh/authorized_keys of the servers I use and/or uploading it to GitHub, GitLab and/or Bitbucket. (I did once have a problem with Bitbucket: I had both a personal account and a work account, and it wouldn’t let me use the same SSH key for both, so if I wanted to access both from the same machine then I had to generate two keys on that machine and look up how to use git with ssh-agent to select an alternate key, but hopefully that’s a rare situation.)

Many (but not all) SSH servers also allow you to put from="IP" before the ssh-rsa column, where IP is a single IP address or a list of IP addresses and/or subnets (e.g. from="192.168.0.0/16,1.2.3.4" ssh-rsa ...) to specify from where the client is expected to connect. This doesn’t provide very much additional security, since anyone who fully compromises a client is likely to use it in-place with no change of IP address, but it may at least protect against the lesser failure mode of an attacker obtaining a copy of a private key but without actually obtaining control of the client on which it is stored. So if a particular client has a fixed IP address, or is within a fixed IP network block, it may be worth considering adding from= specifiers, although you will of course need to change these if the client ever does change its IP.

I’m also an avid user of the .ssh/config file on clients to abbreviate hostnames and do other tricks. For example:

  TCPKeepAlive yes
  ServerAliveInterval 200
  Compression yes
  CompressionLevel 9
  
  Host ds linux.ds.cam.ac.uk pwf
   HostName linux.ds.cam.ac.uk
   User ssb22
   ControlMaster auto
   ControlPath /tmp/.dspath

The first four options are useful over slow or unreliable links. The Host option lets me give the server several names (in this case including the old name it used to have, in case I ever accidentally type that one) and maps it to the real HostName. The User option makes sure I log in as the correct user even if my username on the local system is different (although I usually try to get the same username if I can). The ControlMaster and ControlPath options let me pass additional sessions through the same connection, which is useful if the server keeps your home directory on a Windows file share or something, as this often results in it requiring a password login rather than a public key login: at least ControlPath lets you avoid typing the password for any additional shells you want to open.

Other good options include Port, if the server is running on a non-standard port to reduce the amount of clutter in its logs from probes, and ProxyCommand, which can be set to run a ‘port-knocking’ script to ask the server to open its port before performing an nc command to it. You need to write the latter as:

  ProxyCommand /bin/bash -c 'port-knock >/dev/null  2>/dev/null && /usr/bin/nc %h %p'

where port-knock is whatever command you use to do the ‘port knocking’ (or for example a curl command to run a CGI script that opens the port).

Silas S. Brown Silas is a partially-sighted Computer Science post-doc in Cambridge who currently works in part-time assistant tuition. He has been an ACCU member since 1994 and can be contacted at ssb22@cam.ac.uk

Notes: 

More fields may be available via dynamicdata ..