Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What are the best practises for using SSH keys?
306 points by TheCustardKing on Sept 25, 2016 | hide | past | favorite | 110 comments
Following the recent post about upgrading SSH keys to ED25519, I am wondering what the best practises (regarding security) for using SSH keys are.

For example:

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

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

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

- 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?

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

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




From my experince as an attacker --

   - Is it better to use a different passphrase on each key, or does using the same one not matter much?
   - How much less secure is it to not use a passphrase on a key?
   - Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?
None of these things really matter that much. Make sure you use full disk encryption and never stand up from your machine without locking it, and make sure you keep your local machine patched. If I get code execution on your machine, I am going to use whatever keys are loaded in your ssh-agent to pivot, hijack your existing open sessions, or modify your ssh client to dump the keys I need.

   - 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?
Key length is a protection against the future, and against state level actors. Right now, key length doesn't matter much to me because I'm more focused on just stealing your keys from you regardless of length.


Indeed, I have FDE enabled and a passphrase, but I reckon that the passphrase is not buying me much.

OTOH, it's defense in depth, and there are some vulnerabilities which could allow to exfiltrate keys without non-sandboxed-RCE

https://blog.mozilla.org/security/2015/08/06/firefox-exploit...

I reckon that a passphrase protected key would be safe from this attack (modulo offline brute-forcing)


> OTOH, it's defense in depth

Yup. IMO not using a passphrase is nuts, considering there is practically no convenience loss (ssh-agent, OS X keychain, pageant) and fairly significant benefit. Protects against:

- accidentally exposing the private key (it happens, accidental wildcard in the shell), and

- attacks that aren't after your keys specifically, e.g. your home directory gets stolen.


In general I agree with you, with the caveat that there are a number of products that don't give a toss about security (lookin' at you, Hashicorp) that actually and unironically require you to have your keys unencrypted on disk.

I have since discarded these products (and others should too), but they do exist.


Nobody seemed to answer this question, and neither did the original blog post (besides "trust me and do it"), so maybe you can shed more light on the main point:

Why are ED25519 keys better than RSA, how compatible are they with different systems, and are they worth the hassle and risk of generating and using a new one?


> Why are ED25519 keys better than RSA

Two reasons: 1) they are a lot shorter for the same level of security and 2) any random number can be an Ed25519 key. To generate an RSA you have to generate two large random primes, and the code that does this is complicated an so can more easily be (and in the past has been) compromised to generate weak keys.


If I understood it correctly, you're saying that RSA requires the two numbers to be big AND random, otherwise the algorithm isn't strong? Therefore Ed25519 is better because it's strong regardless of the key?

What I don't get then is how can a short key be secure, that goes against what I was taught in college. Aren't shorter keys more prone to collisions and bruteforce attacks?


Aren't shorter keys more prone to collisions and bruteforce attacks?

Given the same cipher, more or less, yes. Between ciphers, though, key-lengths are less relevant, and the differences in those ciphers become more so.

EDIT: Think of it in terms of Shannon Entropy: because RSA requires a pair of primes, the keyspace is so much sparser — that is to say, more "predictable" (if, granted, at a mostly theoretical level) — so keys need to be that much larger to be secure.

Contrarily, with ED25519, keys can be smaller, because the keyspace is denser.

(Or am I just talking out my ass here?)

EDIT 2: s/smaller/sparser/, s/bigger/denser/, regarding keyspaces. Thanks, 'lisper!


Not bigger -- denser.


Great replies, I got it now, it makes sense. Thanks to both of you!


RSA requires two numbers which are big and random and prime. It is the primality that makes things tricky. Generating random primes is a lot harder than generating random numbers.

The other factor (no pun intended) that makes RSA keys large is that there are more efficient algorithms for factoring than there are for solving the elliptic curve discrete log problem, e.g. https://en.wikipedia.org/wiki/General_number_field_sieve If you crunch the numbers on this you will find that a 2000-bit RSA key has a security level of about 100 bits, i.e. it takes about 2^100 operations to factor a 2000-bit RSA key using GNFS.


Not disagreeing, but I think both randomness and primality testing both have the problem that it's so easy to do them poorly. Generating random primes of these sizes isn't all that difficult, and even proofs can be done in reasonable time frames (e.g. under 10 seconds for 1024-bit inputs). There are also a couple random proven prime algorithms which run pretty fast. Getting software to correctly implement everything .... that seems to be hard.


> Getting software to correctly implement everything .... that seems to be hard.

Exactly. Generating random primes is not terribly difficult in theory, but in practice it is very tricky, which makes it hard to answer the question: how do you know you can trust your keys? Sure, you can verify that your primes are prime, but how do you know how much entropy they have? The only way to figure that out is the audit the code. (And then you have the problem of making sure that the code you're running is the code you audited.)

Generating random numbers is also tricky, but a lot less so than generating random primes: take an entropy source and run it through a whitener, i.e. feed it to sha512. As long as you have a reliable estimate of the lower bound of the quality of your entropy source, you're good. A lot fewer moving parts.


ED25519 keys are cryptographically more secure, and are more politically secure if you want to call it that due to the undermining of NIST the NSA was/is doing. (plus it comes from djb, all hail djb!)

OpenSSH already has support built in, as does Mosh, and therefore, I do think it's worth it.

I do sometimes disagree with using keys though, despite everyone pushing it so hard, there are cases where I think passwords are the way to go, but thats a long post for another time.

Also, I really like usin pam auth mods, such as yubikeys or google auth for two factor. That combined with regular hardening, and yes Ill admit it, non standard ports (reduces log alert fatique) does a pretty good job.


> I do sometimes disagree with using keys though

That sounds interesting, could you elaborate on that?


Note that ED25519 is more vulnerable to quantum computation than is RSA.


If, like most such claims I've seen lately, you're referring to No Such Agency's recommendation against adopting Suite B, the reasons behind that move seemed to me not to be about ECC being "more" QC vulnerable than RSA. They simply said, "If you haven't made this switch already, just keep using RSA while we figure this whole 'quantum' thing out."

ECC and RSA are both ultimately going to fall to practical quantum computing, and probably over a time frame short enough that it won't matter which cipher you picked.


In your experience what difference does full disk encryption vs home encryption have in this context? We've been debating this a lot at work.


FDE leaves very few if any opportunities for accidentally spilling cleartext secrets onto the disk. If by home encryption, I assume you mean some encrypted container (or encrypted document). Consider what you "DO" with the decrypted contents.. often you are copying them out to perform some action (authentication, etc).. Are you certain the apps you use and your clipboard won't be paged to disk temporarily? If secrets are in memory, then get paged to disk, is your swap encrypted? It is more likely you are still protected if using FDE (depends on your setup).

All that being said, thats a certain level of paranoia which i dont think is productive.. but perhaps for targets of the state or what have you, I'd rather not chance it.


I think in this case, "home" encryption is what I use. Most Linux systems when you install will offer to encrypt your home folder. When you login, your password unlocks a key which ecryptfs uses to virtually mount a directory filled with encrypted files to be your home directory. As long as you are logged in, the home directory contents are available (transparently). When you logout, the virtual mount is destroyed, leaving behind only the encrypted files.

To put it in perspective, if you were logged out completely and tried to login remotely, you would be forced to use a password login initially. If it was more like my desktop where I'm logged in and the screen in locked, the home folder is unlocked, so I can remotely ssh in using just my keys.


The default encryption on Ubuntu, if you select 'Encrypt my home folder' during setup, uses ecryptfs on your home folder, and cryptswap for swap. For some reason, /tmp/ isn't encrypted by default as far as I can tell.

AFAIK the main benefit is: if you want to run a multi-user or headless system, you need the network stack brought up before a password is entered - which home directory encryption provides and FDE can't.


> For some reason, /tmp/ isn't encrypted by default as far as I can tell.

It does not give any extra benefit because tmpfs only resides in RAM, and disk encryption typically only concerns data at rest.

If you come to a point where you want to have /tmp/ encrypted, you would rather encrypt the whole RAM. (Does anyone actually do that?)


I consider best practice to be using a hardware token.

My favoured solution is to use a yubikey via gpg: with this method you use your gpg subkey as an ssh key. The yubikey 4 supports RSA 4096 bit keys, if you need NFC then the Yubikey Neo supports max RSA 2048 bit keys.


If you are going to set this up, sit down and spend an hour thinking about your backup and recovery strategy first. I'm familiar with an organization that did a POC for 2FA using them and had a surprisingly high failure rate.


I order 3 for each user, and tell them to keep the third somewhere really, really safe.


Maybe the safest thing is to not give them the 3rd one, until they ask you to pull it out of your safe.


This. It's so cheap and easy to use a hardware token for your GPG and SSH keys nowadays (YubiKey 4! TPM! Smartcards!). If you're not using one, you should.


Do you have a list of guides you recommend for getting started with YubiKey?


I found this guide to be pretty comprehensive: https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on-yubike...


I have tried this for Windows and could not find the right magic to bring my yubico and ssh keys together (keepass otp stinks). What am I missing?


I haven't done the setup on windows before; but gpg4win does the auth correctly, and it automatically hooks up to putty!


If you don't know already the OpenPGP implementation used in the new Yubykeys is no longer[1] open source. Not that it really matters, since you couldn't verify the running code anyway, but this doesn't make me feel I should trust them.

[1]: https://www.techdirt.com/articles/20160515/02094934446/bad-n...


The other nice benefit of this is that now you have pgp keys for your organization to which you can encrypt backups and suchlike.


A good practice to enforce (if you can) is to only share credentials with your coworkers if they're gpg encrypted. e.g. coworker asks for password to some AWS box? encrypt it to their GPG key and email it to them.


- coworker asks for password to some AWS box?

To be clear, GPG encrypted is better than plain text for all sorts of secrets, but using a single account and passing around passwords won't scale. (Or rather the security implications of everybody having root access via a single shared account and passing the password around should frighten you.)

Ideally there's some sort of mechanism so all users can login to their own account on servers (from puppetized ssh keys to LDAP, among others), and no one is actually passing around passwords.


The first rule: never share a private keys between physical devices. Apart from reducing the opportunities for it to go walkies in transit, or accidentally get left on a USB stick, it allows you to revoke a single credential if you lose (control over) that device.

From that, we get:

  - you're not sharing passphrases between keys, you're 
  sharing them between devices, and whether that's safe
   depends how likely it is that a compromised passphrase 
  on one device can be transferred by an attacker to another.
  - Similarly, whether a blank passphrase is a good idea or
   not depends on what other measures are protecting access 
  to that private key.
  - If a private key ever turns up on the wrong machine, 
  you *know* the key and both source and destination 
  machines have been compromised.


If I understand this properly, how do you use the same identity from two different machines on a service like github?

If they only allow you to upload one public key per account, then you aren't able to use that account on both your desktop and laptop, if you have separate private keys on them, no?

Edit: Actually I just looked at github and they allow multiple keys. Is it generally the case that any service that offers ssh keys will allow multiple keys?


There's no reason not to. The `authorized_keys` file on a host does exactly that. Whether a specific service does the same is down to that service.


How do you revoke the keys when a machine a compromised? Log in to each service and remove it when you become aware?


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).


Additionally there is a fork of OpenSSH called PKIXSSH that supports X.509 certificates in addition to keys and OpenSSH certificates. This is useful for using the same credential (certificate) to authenticate using other protocols such as TLS (via TLS client certificate) and Kerberos (via PKINIT).

It supports OCSP responders as well as CRLs.

It can allow or deny access based on X.509v3 extensions.

Using this and a hardware token with an X.509 certificate you can completely eliminate passwords for most cases and have no ability to leak your keying material (barring HSM vulnerability).

Android and iOS devices have historically had little support for smartcards so that's a downside of you use those devices. There's a smartcard framework in Android but I've not used it since 4.x and it was not useful.

Support on ChromeOS, Linux, Windows, Mac OS X, Solaris, and *BSD has been a lot more reliable.

Also, this is a fairly common usage scenario thanks to HSPD-12 and the tens of millions of affected PKI users.


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?


For backing up your keys, they can be encrypted to a device with full disk encryption, or to a mountable disk image that's encrypted, and then push that file off site.

As for access if you lose a key, unless you somehow run a VPS that also uses full-disk encryption (and requires a passphrase on boot), then your hosting provider has access to your VPS.

For instance, with DO or Linode, you can log in to the admin console and reset the root password of a server. Once done, you can use the terminal built into the admin panel to access to the server even if SSH is disabled.

Presumably, someone could work with the provider, prove you are dead, and that they should gain access to your servers. At that point it would come down to the policy of the hosting provider.


An account that can only login on the local ptys is a good enough backup plan.

The disk encryption doesn't buy you much in such an environment, though... Even with whole disk encryption if you're running virtualized; then your provider can just read your VM's memory anyway...

Unless your VPS is going to be forever shutdown, disk encryption under a hypervisor you don't control seems reasonably pointless -- I only use it for physical security to stop people being able to use disks they yank from physical boxes -- even then if they were motivated enough they could probably grab the memory from the server(s) and get the keys anyhow...

AFAIK, there is no possible protection from this besides running your own gear. There were recently published attacks where someone managed to pull keys from other machines by abusing some either intel or vmware's memory dedupe tech bugs iirc (don't have the link handy) -- so; it's not even limited to what your provider may be doing...


As long as the key is password protected with a reasonable strength password (say, a sentence which you remember) then why not put them everywhere? I generally have a copy of my ~/.ssh copied to a few locations, and I'm not really concerned about people guessing the password more than someone hijacking a ssh auth sock on a remote system (which is why you should ssh -A only when you need to :}})

Edit:

To elaborate on this a bit more -- perhaps I'm not an ideal role model for 'best practice' ssh key behavior -- but I end up dealing with a whole load of keys and boxes in $dayjob:

punkz:~$ wc -l ~/.ssh/known_hosts

1473 /home/punkz/.ssh/known_hosts

punkz:~$ ls -l ~/.ssh/id_* | wc -l

31

I deal with these by creating a new keypair for each client I'm working with (sometimes one for each of their environments) and I incorporate their name, or the location of the office I first attended for them, into the passphrase for the key somehow. While this is similar enough to the others that I won't forget the whole thing and so if I have to pick up some old client where I've forgotten the phrase there's usually only about 4 combos with the client's name or the address with various CaSeOpTiOnS or so on that I can usually get there..

I suspect if someone, or ... say .. some state, was targeting me personally to get access to a specific key that if they've gotten to the point where they have copies of them anyway; I wouldn't be able to stop them with a clever passphrase which is more unique than what I currently do.. Thinking along those lines then, I'm aiming to protect against lazy/stupid attackers wanting 'low hanging fruit' as it were, vs the big boys who probably have other ways of pulling these secrets from me....

I maintain a completely different passphrase schema for my personal keys -- either way, that's how I do it; seems good enough for me.. Any thoughts?


You don't need to use different keys for each customer.. it's not a problem to just provide the same public key for all of them. However, if you have several different access devices (i.e., laptop and desktop), you should definitely have different keys on those. (disclaimer: I work for Userify)


I disagree -- you really do need to; I tend to need to use ssh -A on my clients (jump boxes, etc) -- and the agent I will only have their key in it -- if one of the other staff with root on the bounce box, or an attacker, grabs my auth sock, then the keys only let them further into that one client, instead of pwning all my others...

Or say, someone pwning a dev jenkins box doesn't get an agent connection which lets them into prod...


You (probably) don't need to use -A to use a jump box. SSH agent forwarding with -A is unsafe on shared jump boxes where either 1) anybody else has root on the jump box or 2) everybody uses a shared account on the shared jump box, because the connection to your agent can be hijacked and used to authenticate as "you" elsewhere.

Look at ssh's -W or -J options (depending on how old your ssh client is), or see e.g. [0].

[0] https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J...


Any other reasons for separate keys, if I don't use ssh -A?


Not really. Think of each key as, well, a key.. If you used the same key in every lock in your house, that might be ok... Sometimes, though, you need to be more careful -- the only motivation for using more than one is to limit the damage someone getting a copy of that key does, right?


It might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case one is compromised or assumed to be compromised. (disclosure: I work @ userify)


In addition, it might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case the third-party service you're using to manage the keys to the kingdom is compromised or assumed to be compromised.


Sorry to hijack this, but this is absurd.

I really must have missed the story here -- people pay for a third party service to manage their private keys?

... Err. That's so illogical it's making my brain hurt to even work out why I would need to explain how illogical it is...

I can't even come up with a good analogy for how wrong that whole idea is, fortunately I don't have to though since no one that has mastered 'ssh-keygen' and 'cp' would actually do so.....

2FA, okay; the service provider only has half the story. ssh-keys-as-a-service? WAT.

Edit:

Okay, I looked a bit more at userify and it seems to be an agent that runs on your systems which generates authorized_keys files....

From their docs:

"There are two parts of the Userify installation: creating the agent (readable only by root) in /opt/userify, and setting the agent to start at bootup. Setting the agent to start at bootup is a bit trickier, but the installation process attempts to detect the server type and set it up properly."

Am I reading this wrong? You hook up an agent, which runs as root, which farms out authorized_keys entries across the estate? One possible mech for deploying the agent is conf management?

What the actual fuck? Why would anyone do this? Do I even need to explain why this is blowing my mind so much?


keyegn + cp don't do everything. Unless the distribution and session killing is automated, you can't easily revoke access. Of course you could implement this fairly easily with {chef/puppet/salt/ansible/...} and ldap, but it requires time / bandwidth. This is what userify seems to give you.

I'm not saying it's a good solution though. I agree that it's giving someone full access to your whole environment and it's a bad idea.


But... But...

Okay, there are a few things here.. I'm not trying to rant at the people behind this directly, there are a number of similar agent-based tools which have similar issues, so please don't take it personally...

1) If you have the ability to roll out an agent such as this, with your conf management, then you could just manage your users that way instead....

2) Even assuming that this SAAS is un-hackable (lolz), you're now in the situation where all access to every machine in your environment can be changed with a single password on some web ui you don't control, which can be accessed from anywhere.

3) This should go without saying -- I can't put too much faith in how well it's implemented -- pwn the saas, then I immediately own every system connected to it..

4) The enterprise docs talk about sitting it next to your LDAP system... If I had an ops discipline and environment which has gotten to the point where I'm dealin with LDAP, why wouldn't I just configure PAM to read my ssh keys from that, instead of this?

I understand this is one of many such products which are coming out of the lack of desire/time/staff to handle opsy-style tasks when features could be getting written (I'm planning a talk on this...)

But.. does anyone really think that the cost of spending a day wrangling ansible to manage access to your servers is worth more than giving some random third party the ability to add users to your production databases?

I've dealt with many, many different auth mechanisms up to this point. LDAP+Pam_MkHomedir, NFS, Config Management, Shared Keys, Shared Passwords, etc etc. Each have problems, but I don't think the issues with any of those are solved by this, are they?

This must be aimed solely at small startups with no ops experience, right? No one would actually put this near real data, would they?


> This must be aimed solely at small startups with no ops experience, right? No one would actually put this near real data, would they?

I hope so. But if I'm wrong, I'd like to hear from the actual users what do they get out of it.


> Do I even need to explain why this is blowing my mind so much?

Not to me, I felt exactly the same way.

I simply cannot fucking believe that somebody would "outsource" something as sensitive as this. Then again, I don't run my services on other people's computers either. My servers are either in our cages in datacenters or in buildings that we own, they're locked down as much as I can get them (DISA STIGs, etc.), we encrypt the hell outta data, we have strict security policies, etc.

I really can't imagine doing something this crazy but clearly I'm in the minority.


Userify is available as on-premise too. (btw I strongly agree with you... we're offering 5 server enterprise license model and we're looking at an unlimited stripped-down free version.)

Also, you're probably running servers at a third party hypervisor already.. ;) they could be scanning your RAM and reading your disk and you'd never know.


Yeah, actually I'm not. All of my servers are either in our own cages in datacenters or housed in buildings that we own. We don't do AWS/DigitalOcean/etc. (Nice attempt at a jab, though.)

I certainly wasn't trying to shit on you (or your company/employer) personally... but to me the idea of turning over ultimate control of all my servers, data, etc., to some unknown third-party and simply trusting them is absolutely fucking absurd.

I pretty much agree with everything cyberpunk said in this thread. I've been around long enough that it shouldn't but some of the things people do with regard to security sometimes surprises me and just leaves me standing there with my mouth hanging open, saying "WTF?".


"unknown third-party and simply trusting them is absolutely fucking absurd"

So how do you feel about TLS and the 100's of trusted certificates embedded in your browser/mobile device?


Are you really asking the difference between the CA bundle and some node+redis+python startup being able to drop authorized_keys across your datacenter?

... eh?


The original conmment was about "unknown third parties". I'm not advocating handing over your ssh keys to anyone but if you did, at least this would be a third party you consciously chose to trust. The crap load of CA's you implicitly trust on the other hand... Do you even know the names of 10 out of about 200 of them embedded in your browser?

EDIT: Case in point.. did you know the name WoSign before they became notorious? https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBG...


If you use fail2ban make sure to pin the right key to the right host. Otherwise ssh will try all the keys and get you banned from your own host. The easiest way is to use the ~/.ssh/config:

    Host myhost
      IdentityFile ~/.ssh/myhost


Good advise. This happenned to me. By luck I had another account I could use to recover. I wish I could disable that feature. I use config now but the default should not be to try every key in ssh directory.


Agreed. That seems like a weakness in OpenSSH. One should have to turn on a "try all keys" option to get that behaviour ..


Yeah, it's on by default. See IdentitiesOnly to turn it off.


It still may try other identity files. You need the IdentitiesOnly option, I believe.

I've been bitten by this a few times.


You should do this even if you're not using fail2ban. Otherwise any box you connect to can enumerate all of your public keys, which could be a problem for some people.


I don't think doing this actually prevents that. Your full agent is still forwarded. You need to use a separate agent per key if you want to prevent the remote host from using your other keys.


If you're using key based auth exclusively, you don't need fail2ban.


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.


Also, low values of the sshd option "MaxAuthTries" makes having multiple keys annoying. There are servers I have to log into with "1" or "2". It's really annoying and doesn't enhance security, especially with "PasswordAuthentication no".


The classical document about this:

http://lackof.org/taggart/hacking/ssh/


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

This is a question of layers. If you don't have a passphrase on your key, what stops someone from gaining access to it? Just your account password? If they steal your device, is there some form of storage encryption involved?

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

I have different keys for different purposes per client device. This is mostly because sometimes I need to login to places that are ancient enough I need to use a weaker key than I would like to use in other places or vice-versa, there's places I can only login with ed25519 keys.

Though having different keys per purpose isn't necessary it allows me to keep certain identities separate. I have a different one for GitHub for example, mainly because GitHub exposes my public key and therefor allows for clever tricks like tying the key to an established identity should I use that key to authenticate in other places.

I would also recommend configuring SSH so that it doesn't send over any/all keys by default. Take a look at the IdentitiesOnly option in ssh_config.


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

Yep in an ideal world, though I suspect in practice it doesn't matter much.

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

You are relying completely on the security of your disk, against either physical or cyber. Use a passphrase, use an agent to manage it.

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

Per client device. This is the device that can be compromised and cause invalidation to be required, so this is the one which should be seperate. For convenience you can maintain all your devices public keys concatenated together and hand them out like that - comment each with hostname and date created for ease of identification.

- 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?

Up to a point. RSA in 8 bits is trivial. Go for a highish key length, different key types have different recommended lengths. Note some machines dont support higher lengths.

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

In $home/.ssh

Permissions should be set for only you to read with no writing. Even better if your home drive is encrypted as it is only vulnerable whilst you are logged in.

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

If you hop machines a lot key per client can be problematic. In this case a portable secure drive is useful. Of course one leak can be fatal here.

Try not to fall back on passwords, they have nothing like the same security.

Most usability issues are caused by the people running the servers not reacting in a timely fashion to key updates.


If necessary, it's possible to fall back to password plus OTP.

That's a reasonable compromise, since you carry the OTP generator around with you.


Some general advice based on most requirements.

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

If they are being used on different device then different passphrases makes sense otherwise no.

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

10? Not sure you can really quantify an answer. I'd recommend a passphrase if you aren't already using disk encryption with that it's probably less of a concern however with agents there's not much issue with not having one.

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

Use a different key per client device but you don't need a different key for logging into different servers unless you care about people correlating those users.

- 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?

Use more than 2048bit for RSA/DSA beyond that it doesn't matter.

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

~/.ssh on some local filesystem.


Don't use DSA


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

It is better to use a different passphrase for each key but it is also less convenient unless you're using a password manager (personally, I'm using KeePass)

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

That depends on the security of the computer where the keys are. I remember a Firefox vulnerability where one site exploiting it was looking for ssh keys on the local file system. So I'd say that a passphrase is very important.

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

Personally I'm using a key per account per host.

> - 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 up until 2048 where the returns of increasing the amount of bits will start diminishing.[1]

  [1]: https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096


> It is better to use a different passphrase for each key but it is also less convenient unless you're using a password manager (personally, I'm using KeePass)

If you are going to use a password manager to store them there's no point in using different passphrases.


Why not? Granted the passphrase are in one place but as long as your password store doesn't get compromised managing to brute force a key's password then only gives you access to the machine(s) that one key is accepted on.

Also, the keys don't have to reside on the same device the password store is on. If you have one key per client device for example.


Because if your password manager is compromised, so are all of the passphrases stored in it. So what would the point, then, be of using different ones?


So because a password manager is one-stop shopping (something that I'm subconsciously uneasy about, to be sure), it's pointless to use different passphrases, one of the major selling points of password managers.

So to protect against that, don't use a password manager. Which means that you're more likely to re-use passphrases, because lots of them are hard to remember and keep straight. So breaking one gets access to many others.

My head spins.


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.


> he parent isn't necessarily arguing against password stores in general.

Yeah, reliazed that, my post was just my "logical" progression.


The compromise I use is to break the cycle: Use a password manager to generate strong passwords (and different ones, because breaches happen), and use a hardware token-based password for the manager itself. At least that's the compromise I'm comfortable with.


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

It's better to think about specific attack scenarios. If your keys get exfiltrated because of some local exploit (like a browser vulnerability, a malware download or physical access) then the attacker has access to your servers.


the same holds for keys with passphrases; the attacking process just has to wait until you enter it.


As I mentioned in my other comment: stealing local files does not necessarily have to happen via unrestricted-RCE (which would allow you access to the ssh agent)



It depends heavily on your threat model. Just about any key is an improvement over using passwords to authenticate. If you want protection from state-level actors, you need to be really careful and consistent.

Regarding key types:

- DSA keys (ssh-dss) suffer from several issues (fewer bits, bad RNGs in Debian, other issues), and modern versions of OpenSSH deprecate it.

- RSA is pretty standard, and generally speaking is fairly secure for key lengths >=2048. RSA-2048 is the default for ssh-keygen, and is compatible with just about everything.

- ECDSA is largely considered compromised because the constants NIST chose for the cryptosystem weren't well documented how they got them, and the assumption is that the NSA chose them to provide a "backdoor" (so it would provide the same security for a general attacker, but significantly easier for them). This was confirmed as being theoretically possible, and there is of course concern that the NSA could potentially leak those constants, instantly breaking the security of this cryptosystem.

- ED25519 is more or less the same as ECDSA, but was put together by DJB. The big advantage here is speed. EC crypto is much faster to sign, slightly slower to verify, and equivalent security can be achieved with fewer key bits.

- Notes for the future: both RSA and ED25519 become insecure against quantum computing (integer factorization and discrete log are both in BQP).

Generally, use RSA if you work with older servers that only support it, or ED25519 if you like shiny things. Otherwise it's a bit of a tossup.

Regarding using separate keys:

- I follow the philosophy that a private key should never leave the host it was generated on. If you aren't sharing keys between machines, you remove the risk that you'll accidentally share it publicly.

- Beyond that, I'd recommend at a minimum having separate work/personal keys. Keeping separate keys for each user/host you want to log into is a tad excessive, but can be useful for key revocation/rotation.

Regarding passphrases on keys:

- Yes. FDE is sometimes trivial to bypass, and you want to be protected in case someone sets your ~/.ssh folder to be synced to dropbox/samba/etc. You can use an agent to keep the decrypted keys in memory, but I'd avoid using agent forwarding.

Regarding bastion hosts:

- You didn't ask about this, but it is essential for a "best practice" setup.

- Bastion hosts are small VPS hosts that basically run sshd and have a static IP. You disallow any ssh traffic except from your bastion hosts to your servers.

- You'll want to have at least 2 bastion hosts with different hosting services, in case one isn't available.

- Run sshd on your bastion host on a port other than 22. Not for security, but for reducing log volume.

- Run fail2ban on your bastion host, even if you've disabled password authn. Again, not for security, but for reducing log volume.

- Set up fail2ban to alert when a new IP successfully logs in.

Other stuff:

- SSH can use certificates for authentication, and this can make the key distribution problem much easier to solve. I have a script that makes this easier.

- Push for everyone in your organization to use SSH keys, and only SSH keys.

- Defense in depth. All it takes is skipping one step and you expose yourself. Assume that something that was exposed has been compromised. An attacker only needs to succeed once.

tl;dr - the defaults are fine and password protect your keys.


From a pragmatic end-user perspective.

1) Disable passwords and only allow keys even for root with PermitRootLogin without-password

2) public-key authentication has somewhat unexpected side effect of preventing MITM per this security consulting firm http://www.gremwell.com/ssh-mitm-public-key-authentication


I upgraded to ed209 the other day as well.

Two questions came up, how many iterations to use via "-a ", and should I add the private key to my home folder repo in version control? I don't want to lose it in a disk crash, but don't want to give it to bithub either.


> 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/


If you use multiple identities, and want to reduce the odds of accidentally using the wrong one, then having different passwords is a good idea.


I would also recommend using two-factor authentication (see services like Duo or Twilio's Authy) along with password-protected keys.


Absolutely use 2FA, but it's no guarantee.

With large scale hacks in mind and apropos of the Yahoo hack, an attacker has miniscule chances of getting into your account, but 500 million accounts / a 6-digit auth code means with a full compromise (ie, username and plaintext passwords, which the Yahoo compromise was not), the attacker would still get into 5 accounts.

Given how much full email access is "keys to the kingdom" given password resets, thats the (tiniest) bit worrying.


Relevant xkcd: https://xkcd.com/538/


https://github.com/philipWendland/IsoApplet + some blank java cards + card reader. Something about Yubico rubs me the wrong way.


Use a GPG Card - much simpler than acquiring blank Java cards.


And what is hard exactly about acquiring blank Java cards? Not harder than ordering anything else over the Internet.


Well, finding a reliable seller in Europe seems to be hard.


We live in the age of globalization, these guys better be delivering worldwide, they ask $25 for it.

http://javacardos.com/store

Or if you have a friend that knows Russian you can use this http://www.smart-card.ru/_catalog/?search=jcop


What about for the host key of the server (assuming ssh2)?


RSA and Ed25519 only, in my opinion. Don't use DSA or ECDSA.


Most important is - keep it safe

Passphrase is strongly advised


    Is it better to use a different passphrase on each key, or does using the same one not matter much?
If the keys are for the same thing (i.e. your personal `id_rsa` and `id_ed25519`), then I'd personally be comfortable with the same passphrase. Different passphrases should be used for different purposes (e.g. you shouldn't use your personal passphrase on work-specific keys).

    How much less secure is it to not use a passphrase on a key?
Depends on the situation. I personally err on the side of caution and use a passphrase on all keys unless it's not physically possible.

If you expect to be moving your SSH keys across machines (e.g. to use your same personal key on both your laptop and your desktop), then they should absolutely be passphrase-protected, even if they're only transferred via encrypted media.

    Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?
There's not really a right or wrong answer to this besides "don't reuse the same key everywhere". I personally maintain one key (really two: one RSA, one ED25519) for all of my personal devices, and maintain a strict policy of full-disk encryption on such devices. I've occasionally maintained separate work keys so that I'm not ever in a position where I need to make my personal keys available to an employer.

Meanwhile, for situations where a server needs to connect to another machine via SSH, each such server gets its own key. That way, if a server is compromised or decommissioned, I can revoke access by key.

    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?
It makes a significant difference. More bits → exponentially more attempts required to brute-force it.

    How/Where should private keys be stored on a device using them?
Depends on the device.

A reasonable balance between security and practicality is for any portable media (including portable devices, like laptops/tablets/phones) to be encrypted (in addition to the key itself being passphrase-protected). Better security would be to extend this to non-portable media and machines as well (but this is painful to enforce on servers unless you have physical access).

The directory in which keys are stored should only be accessible to the OS user actually using those keys (so, for example, `~/.ssh` should have permissions `drwx------` when viewing with `ls -la`).

Basically, server SSH keys should be treated like you'd treat your SSL/TLS keys.

    What are some of the pros and cons from a security standpoint
...of?

    and how may doing different things affect the usability of a key?
Pretty much everything involves security v. convenience tradeoffs. Generally, the more secure, the less convenient, and vice versa. While absolute security is ideal, a lack of convenience makes it more difficult to effectively enforce (e.g. as part of a company-wide security policy) unless you're willing to put in the work to build up an effective workflow around it.


I agree with following comment.i was wrong. Thanks asdfaoeu for it.


> Private key is a "password", we need to treat it as such!

This is harmful advice in my opinion. A key has sufficient entropy to resist brute force attacks and is never directly exposed to a server. The same key between multiple servers is fine.


i can recommend this link:

Upgrade your SSH keys! https://blog.g3rt.nl/upgrade-your-ssh-keys.html?_utm_source=...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: