Ask HN: What are the best practises for using SSH keys?

fail2ban is for any log you want to monitor and block access to your machine for; not just ssh. fail2ban isn't a "keep my logs clean" tool it's a "reduce my attack surface" tool.

Edit: Feel free to Google "fail2ban security" if you disagree.

If you have a lot of machines, SSH certificates are supported in OpenSSH 5.6+ and are awesome: https://www.digitalocean.com/community/tutorials/how-to-crea.... They allow for centralized management of authentication/authorization without having to touch each machine (beyond an initial trust relationship setup).

This is probably the wrong forum, but I have a question or two that I see as related.

I have setup a VPS, disabled passwords, and setup a key with a passphrase to gain access. At this point my greatest worry is losing this private key, as that means I can't access the server.

What is a reasonable way to backup my private key?

Encode it as something similar to a QR-code, print it, and store it in a hole in the wall? Copy it to an USB-stick and hide that somewhere safe?

Alternatively, I have access to more than one computer, so I could also authorize a couple of other keys to access the server. So I would transfer the public key to the authorized machine, and add them to the authorizedkeys from there?

How to deal with the possibility of death? Do I trust someone with my keys and passphrases?

I was originally going to post something along these lines, but then I realized that this argument doesn't work the same in this particular context, and the parent isn't necessarily arguing against password stores in general. Sure, it might be better (in the sense of not concentrating your risk to a single file) to have a strong (importantly, private) scheme for creating passwords (say, based on the site and account name). But if you're restricted to some inane restrictions ("6-10 alphanumeric characters"), then there's not really a strong argument against a password manager in this case.

Sure, in general, you want to avoid password reuse to isolate password compromises / security breaches (some companies are still storing passwords in plaintext in 2016, ugh). But in this case, we're talking about private keys that should never leave your local machine. If those are compromised (even passphrase-protected), then it's not inconceivable to think that your password store might also be compromised.

> Is it better to use a different passphrase on each key, or does using the same one not matter much?

Using a passphrase is highly recommended except for server-to-server accounts, which should be locked down (and specify the specific command that server can execute in the authorized_keys file - Userify[1] supports this).

You should definitely use a different passphrase for keys stored on separate computers, and it's not a bad idea to use a different passphrase for separate keys stored on the same computer, especially if they have different servers they can access. However, practically speaking, if your computer was compromised (ie keylogger etc) then it's game over anyway.

> Does increasing the amount of bits in a key really have an effect on the security of the key, or does it not make much difference in a real-world use?

Yes, it does make a difference, depending on what you mean by "real-world". Anyone less than a state-level actor will probably be unable to cost-effectively attack even a 1024 bit key, but that won't be true for long. We suggest 2048 bit keys if you are using RSA, with 4096 if you prefer extra security and don't mind slight latency during a connection, or ED25519 for keys on systems that support it. Generally the defaults are pretty good. We have a HOWTO for different OS's here: https://userify.com/docs/generating-ssh-keys-on-ec2/

> How much less secure is it to not use a passphrase on a key?

From the server's perspective, it's EXACTLY the same, but from the client (your laptop's) side, it's completely different. While it's possible that your laptop could still contain your decrypted key in its key manager's RAM or suspended state (ie unencrypted swap file etc), the use of a passphrase even on (actually, ESPECIALLY on) a non-full-disk encrypted system will raise the level of effort to access your key to near-impossibility levels, especially from non-state actors, whereas a key that has NO passphrase is a piece of cake. Use a passphrase EVEN WITH full disk encryption (for example, the evil maid attack)

> Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?

If you're using a different key and storing them on different computers, you should probably use a different passphrase on each key. The passphrase (or even if one exists) is not visible to remote servers (or Userify[1] - we provide a free-text field that becomes your authorized_keys on remote servers.)

You don't need to use a different key per user account, although you can. You also should not use a different key per server.. that will turn into a management nightmare. It's perfectly ok to use one key everywhere, but you should probably use a different key on your laptop and desktop, or if the keys have different levels of access (Userify[1] can automate that for you too).

> How/Where should private keys be stored on a device using them?

Ideally on a device using full-disk encryption, including swap and laptop suspend space, to prevent access to a decrypted key in RAM (you are using a passphrase, right?). However, FDE does not protect you from other compromises on your system (i.e., another user that gains escalation to root and installs a key logger), and does not protect against a compromise of your BIOS (i.e., Intel UEFI) or boot process (evil maid attack again).

> What are some of the pros and cons from a security standpoint, and how may doing different things affect the usability of a key?

Keys are safer than certificates because there are less moving parts and no outside requirements for your internal CA or dependency on a CA that might go down. Keys can be a management nightmare at scale, but there is software to manage them (ie Userify[1], ManageEngine[2], BeyondTrust[3], ssh universal key manager[4], keybox[5] (free/open source), etc). If you are doing a small project with few team members, you can also do management with Chef, Puppet, etc, or just by hand.

In terms of usability, a real key solution that manages keys across entire groups of servers with a few clicks can be really helpful... you can do all of the regular SSH things like tunneling (replace stun/sslwrap, etc), proxying all of your other traffic (SOCKS5), keep SSH connection alive (autossh etc), smart ban based on failed attempts (fail2ban, deny hosts), forward encrypted X11 or VNC connections, forward SSH itself (tunnel SSH within itself), and so much more.

We're going to start blogging about all the awesome things you can do with SSH soon, since it's really an amazing and deep protocol.

1. Userify https://userify.com Free cloud and on-premises versions available; full disclosure: I work there

2. ManageEngine: https://www.manageengine.com/

3. BeyondTrust: https://www.beyondtrust.com/

4. SSH Universal Key Manager: http://www.ssh.com/ (no TLS?)

5. Keybox http://sshkeybox.com/