1

I have been starting to think about security in a bit more depth recently and have hit a few questions which I would really value opinions on.

For years I have had the same SSH Keypair to get to my own servers, github etc. I have secured my private key and kept it that way. I have the private key between multiple machines, work laptop, private laptop and mobile device. Now whilst I dont see this as an issue because I never know where I will need to connect from to sort issues etc. Recently whilst reading some blogs about how an unscrupulous employer scanned and collected private keys on their employee laptops it made me think about who could potentially have access to my machines. my current employer backs up their laptops so in essence my private key could be stored anywhere on their systems and allow anyone who has access to these systems access to my key.

So what is the best way around this issue? I need my keys on multiple machines/devices so how do I manage this and keep them all secure? I have read about separating out keys to single devices, servers and users

  • User1 -> Server1 (1x Keypair)
  • User1 -> Server2 (1x Keypair)
  • User1 -> Server3 (1x Keypair)

This doesnt really solve anything though as it just means more keys to manage with hardly any security benefits.

The next option would be to change the logins from Key based auth to TOTP authentication (Username, Password and Time-based One-time Password). This would get rid of the need for having a private keypair, but still allow access to my servers. Of course I would still need keys for sites like GitHub etc.

Does anyone have any other thoughts on this?

  • Do you have a passphrase on your private key? That would limit their ability to use the key as recovered from backup, and you can use a key agent to cache the unlocked key in memory while using the system so you don't have to type it repeatedly. – gowenfawr Jan 27 '16 at 14:26
  • Hi gowenfawr, Yes I have a password on the key and use the standard key agent on linux/mac. – Tony Jan 27 '16 at 14:41
  • 1
    Unless you're concerned about your employer keylogging you to gain that passphrase, or doing a memory dump of your laptop and extracting the private key, then having the password on the key is probably sufficient protection. That's a different risk profile than "employer backs it up and any systems personnel could grab a copy of the key". – gowenfawr Jan 27 '16 at 14:44
  • This is not an uncommon question over on unix.stackexchange.com and you may want to poke around over there, too. For example: this question and this question and if you have a much bigger complex system, this answer. – drewbenn Jan 27 '16 at 18:32
2

You can encrypt your key file and ssh will prompt you password to decrypt when you are connecting to your server.

ssh-keygen -p [-f keyfile]

ssh-keygen will prompt for a password used to encrypt the key.

0

Even with the passphrase, it is probably a matter of time before it gets decrypted. Also you'll have to integrate the totp service, which might not be possible if you're not the admin. Unfortunately key rotation then becomes a necessity.

0

While there's nothing I can imagine that will protect you from a really determined individual with admin access to your machines, an alternative to passphrases on files stored locally is to use a smart card - there is support in PuTTY, WinSCP and for ssh/scp/sftp on Linux and probably other OS too.

0

Continuing my obsession with hardware tokens and YubiKey NEO devices, I generated an GPG key on token, exported the public key, and used gpgkey2ssh to convert it to the format that goes in my authorized_keys file.

Instead of using ssh-agent to decrypt my key file from disk, I plug in my security token and use gpg-agent. Access now requires that the key is physically in the computer and it cannot be copied.

Fully compatible with GitHub, requires no server configuration changes other than rotating the key out, and requires the very minimal install of gpg-agent to utilize it on the client.

As for needing the key on multiple machines, use agent forwarding (ssh -A) to keep that temporal access benefit of requiring the hardware token is in place.

  • I really like the idea of hardware tokens, but what if its as simple as the company you work for disabling usb ports. – Tony Jan 29 '16 at 11:47
0

I use one key per client computer, and all the remote servers I need to access have 1 or more lines in their authorized_keys file, depending on which clients should be allowed to access them.

So if you have a home laptop, a home mobile, and a work laptop, each of those would get one keypair. Then you upload each public key to every remote computer that each of those should be allowed access to. For example, the server you push your home backups to would probably get the public key of both home computers, but not your work computer; a web server you support for work but might need to access from your mobile when you're on call will get the public keys for your work laptop and your mobile.

Now you've created a new problem for yourself: key management. But as long as the number of client computers remains small, you can manage it manually.

Whenever you provision a new computer, part of your setup is now to create a new keypair for it and push the public key out (probably using one of the existing computers) to all the servers it should be allowed to manage. When you decommission a computer, you go out and remove all its public keys (if you "securely" decommission it and the private key is destroyed, this may not be an urgent task). When a computer is no longer trusted (for example you realize your work computer's keys have been backed up even though you tried to prevent it, and then you accidentally googled the passphrase protecting them) you can just remove that computer's public key everywhere and generate a new keypair for that computer.

  • I think this is quite a good solution, the problem is key management, as you said if its a small number of hosts and servers it shouldn't really be a problem. – Tony Jan 29 '16 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.