28

I have a customer that now requires us to change every password every 90th day due to their interpretation of GDPR. That's fine for the web-based system we develop for them because we can just implement those rules. But they also require us to change the passwords on our SSH keys used to access the servers, which is, well, not fine.

  1. Is it possible to change the password on an existing SSH key?

  2. If not, are there any tools we can use to handle this? I'm thinking:

    a. Create new keys.
    b. Distribute all public keys to existing servers.
    c. Remove existing public keys.
    d. Archive old private keys .

    I've read some posts here about Puppet, but as I understand it they aim to only solve the problem with distributing the public keys among the servers and not creating new keys every nth day? Should I go further with my research into Puppet?

  3. What is the community standard when it comes to password retention and ssh keys? How do you do it?

mr D
  • 280
  • 1
  • 3
  • 5
  • 7
    This topic seems to be better discussed on [security.se]. The basic question already [has an answer there](https://security.stackexchange.com/questions/66936/expiration-enforce-change-of-passphrase-for-private-ssh-keys). – Gerald Schneider Sep 18 '18 at 08:03
  • 33
    This is actually not required by the GDPR. If anything, the GDPR requires you to follow best practices. And the best practice today is _not_ to expire passwords. Forces password expiry was a best practice around the turn of the century, but was discredited well before the GDPR was even proposed. – MSalters Sep 18 '18 at 10:16
  • 2
    SSH can use certificates, maybe that could be used to achieve something like that? – Edheldil Sep 18 '18 at 10:52
  • Yes, like @Edheldil said, use certificates instead of raw keys, as you can add expiration dates to them. Search for netflix solution about that; they shared their internal setup where they do ssh authentication with certificates valid for 5 minutes (this applies just to authentication, opened connections stay open). – Patrick Mevzek Sep 18 '18 at 12:01
  • Ok. The customer wants you to change your *password* in every 90 days. What if you don't use password? You can say the customer some like this: *"Our co-workers are using mainly strong cryptography, so we can easily fulfill this requirement"* or similar. Have some rootpassword in deeply hidden somewhere, for the case if something would go badly with your keys, and a monthly remember to change it, and all other user can use key-only authentication. – peterh Sep 18 '18 at 19:16
  • 9
    @GeraldSchneider, the basic question is "My customer is an idiot. How do I give them what they want with a minimum of effort on my part?". That's a ServerFault question, not an InfoSec question. – Mark Sep 18 '18 at 22:46
  • Changing the password of an SSH key wouldn't do anything from the server's point of view, really, because the passwords apply to the user's _private_ keys, whereas the server only has the user's _public_ key. Do you mean that users are being forced/asked to use new keys every 90 days? – code_dredd Sep 18 '18 at 23:13

6 Answers6

37

The customer is wrong here and does not understand what they're talking about. Changing the passphrase on a private key is a very bad idea, because it has very counter-intuitive security properties.

Normally, users think of passwords that they have changed as "no longer secret". They might become throwaway passwords for low-value sites, online handles/nicknames, punchlines to jokes, etc., and any paper on which they're written might become scrap that's exposed.

For a passphrase used to encrypt a private key , that's not how it works! The passphrase must be kept secret forever unless all privileges associated with the key have been revoked (and the following doesn't apply to ssh keys, but if the passphrase is for a key used not just for signing, but for receiving private messages, then forever really means forever). This is because of the possibility that the encrypted private key file has been obtained by an attacker or stored somewhere (like in a backup) where it might be obtained by an attacker in the future. If the passphrase is ever revealed, it's then compromised.

In some sense, a private key that has gone through N passphrases in its lifetime is 1/N as secure, since knowledge of anyone one of the past passphrases is sufficient to compromise the key if the attacker has had access to the encrypted private key file.

Now, back to your problem.

If the customer had not latched onto this "ssh passwords" misconception and dug in on it, the right thing to do would be just never bringing it up to them, and follow best practices for key handling yourself. But now that they have, you probably have to do something to satisfy them. You could try explaining how passphrases encrypting private keys have different security properties from passwords, but given how wrong the customer is about a lot of things here (password expiration is a bad idea in general) I doubt that's going to work.

That leaves you with the task of automating a system for distributing new keys. I would strongly discourage you from automating a system of generating the new keys centrally, since private keys should never be moved between machines. Instead, you should have processes/reminders/scripts to make it easy for the employees/contractors on your side who need access to generate new private keys and publish the corresponding public keys, and have the public key distribution system (Puppet or otherwise) that you use push these out to the systems they need to access.

In addition: One thing that might convince the customer to drop this is mentioning that there is fundamentally no way to enforce that the new private key have a different passphrase than the old one, or even that it have a passphrase at all.

R.. GitHub STOP HELPING ICE
  • 707
  • 4
  • 14
  • 11
    As noted, the proper way to do this is _manually_ and charging said customer for the _manual_ labor may be sufficient deterrent. – bishop Sep 19 '18 at 19:40
  • 3
    As good way to pitch "don't do this" to the customer would be to say "of course, the process for employees to update their keys has to include the absolute guarantee that the old keys will be permanently deleted, to ensure that an old public/private key pair doesn't fall into the wrong hands. If you are not able to guarantee this, then we won't be able to proceed with this plan." – Max Williams Sep 20 '18 at 09:34
19

The answer to your first question: "Is it possible to change the password on an existing SSH key?" is yes. With openssh that is as simple as ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

The problem is that the password is in/on the private key file, which is a simple format that doesn't have support for an expiry date. Also a large part of the concept of key based authentication in ssh is that the private key is not centrally managed, it should only exist on the user's workstation which makes it nigh impossible to enforce a password expire policy on the private key.

Instead: in every environment I've been in before the password policy is on the user account object, not on the method used to access said account. When a password is expired or an account locked, all access methods get locked out including the ssh key.

Add multi-factor authentication when you need more security on an account.

But I'm curious what other people have done to address your valid concerns.

HBruijn
  • 72,524
  • 21
  • 127
  • 192
  • 6
    Also, if PW rotation is to protect against theft/bruteforcing of a pw, key rotation should involve rotating keys instead of passwords on keys as to protect against key loss/theft. If an attacker grabs your old private key with the old password, they still can get in – BlueCacti Sep 18 '18 at 11:07
  • @BlueCacti Though it should be noted that forced password rotations are really meaningless if the original passwords/phrases were already based on a selection process with a high amount of entropy. Changing one password that could take 1M years to brute-force for another password that could take the same amount wouldn't really improve anything. – code_dredd Sep 18 '18 at 23:16
  • @code_dredd I'm not here to discuss the use of password rotation. I'm pretty much against it as well. I just want to point out, in relation to OP's question, that in this case it'd make more sense to rotate keys than to rotate passwords on keys – BlueCacti Sep 19 '18 at 13:28
  • @BlueCacti I was only stating a few things to add to what you had said. I'm not discussing anything. – code_dredd Sep 19 '18 at 15:15
  • 2
    +1 for multi-factor auth. then use a well known app/plugin to generate codes. That way you can tell your client the password changes every X seconds. Including link here as possible implementation, not an endorsement of any kind. https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-16-04 – Philippe Sep 19 '18 at 21:51
8

One possibility that may or may not be sufficient is using an SSH user CA, which allows you to set a lifetime on the signed key. Whatever automation you put around key signing can refuse to sign for more than 90 days. Then, add the public key for your user CA to TrustedUserCAKeys in /etc/ssh/sshd_config and set AuthorizedKeysFile to none.

Mark
  • 81
  • 1
6

Using AuthorizedKeysCommand some expiry mechanism could be implemented on the server side. From simple checking the file timestamp to something more complicated.

danblack
  • 1,179
  • 10
  • 14
  • The public key does not change when you change password on the private key, does it? So how would it check that the password was changed? – Edheldil Sep 18 '18 at 10:49
  • 1
    You can't. As you suggest, changes to the private key passphrase have zero impact on the public key. They could even remove their passphrase altogether. You can only check to see if the entire public key has changed or not. – guzzijason Sep 18 '18 at 13:33
4

You could use a tool like Hashicorp's Vault to create short lived, signed SSH keys. Each user would get a new key every day (or so). You would authenticate to Vault to get the certificate using whatever you use today, like an LDAP server.

The effort of setting this up is not immense, but in my experience larger that what @Mark refered to in his comment. You are basically replacing one problem (clueless client requirements) with another (shard management).

But it does enable a few other scenario like easily generating in-house X509 certs and managing database passwords, application secrets in text file. You judge the effort and ROI.

Also note that the open source version does not have DR capabilities (it has everything else).

ixe013
  • 928
  • 2
  • 7
  • 25
1

You can use a key agent that incorporates time-based one time passwords (TOTP). Now your "password" changes every minute.

Everyone else here is right, though: This is silly.

Michael
  • 173
  • 9