37

So I mistook input fields and now my SSH key passphrase is visible to the world, and I can't even remove it.

Now as far as I understand, this is not an immediate security concern, since the passphrase only protects against the case of my private key itself getting disclosed. Since that hasn't happened (they key only exists on hardware I own), I at most have to change the passphrase in case it happens in the future, I don't have to change to a different SSH key everywhere I've used it.

Is that correct? Keeping in mind that all of this is for private projects and a hypothetical breach could at most be annoying and embarassing.

  • 6
    Yes that's accurate. [Change SSH key password with ssh-keygen](http://www.cyberciti.biz/faq/howto-ssh-changing-passphrase) – RoraΖ Apr 04 '15 at 16:31
  • 2
    That's unfortunate. I once typed a password into a browser address bar having search engine results about it immediately displayed. This was the consequence of a slow starting browser that stole input focus while I was shelling into a server. – bvj Apr 04 '15 at 19:21
  • 24
    @bvj If your password is something that yields more than zero search results, you're *probably* doing something wrong. – Guntram Blohm Apr 04 '15 at 21:30
  • @GuntramBlohm Agreed. – bvj Apr 04 '15 at 22:17
  • 15
    @GuntramBlohm if you did something along the lines of correct horse battery staple (i.e. 4 random words but not those 4 specific words), I'd expect there to be a decent chance of getting results, just not in that order with no intervening words (and check: "shelf brain jogs green" (without quotes) comes back with about 104 million results on google; at least some of which have one word skipped) – Foon Apr 05 '15 at 13:11
  • 1
    When generating a new key, consider using [using stronger key derivation methods for your key](http://security.stackexchange.com/q/39279/2630) (bcrypt in OpenSSH >= 6.5, PBKDF2 with higher iteration counts for older versions). Without careful handling, your key will only be protected with by a KDF with a lousy one-round MD5. – Lekensteyn Apr 05 '15 at 14:53
  • 1
    @GuntramBlohm: The number of results is irrelevant; the point is that his password was transmitted to the search engine over the internet. – Lightness Races in Orbit Apr 05 '15 at 17:35
  • I can help you. Quick, tell me the passphrase so I can change it! – Patrick M Apr 06 '15 at 04:19

2 Answers2

47

Technically, changing your passphrase is sufficient if you don't also believe that your (password-protected) private key has also been leaked.

Realistically, you might just want to replace your SSH key with a new one. They're so cheap they might as well be free, and it removes you from worrying about whether anyone has, is, or will be able to get a copy of the private key with the compromised passphrase. Remember, if somebody grabs a copy of your key that you backed up months before you leaked (and changed) your passphrase, the passphrase still gives them access to that key - which is the same as you're using today under a new passphrase.

So just change your key. It's good practice and best practices.

Edit:

@David-Z has suggested that the time involved in replacing the key is a cost to be considered. I maintain that, since we're talking about keys, that's also negligible, as you can automate the process. The following script took me about 15 minutes to write and test:

#!/bin/bash

for i in $*
do
    cat newkey.pub | ssh -i oldkey username@$i "cat >> ~/.ssh/authorized_keys"
    ssh -i newkey username@$i "sed -n '/my_old_key/!p' < ~/.ssh/authorized_keys > ~/.ssh/authorized_keys_tmp && mv ~/.ssh/authorized_keys_tmp ~/.ssh/authorized_keys"
    if [ $? -eq 0 ]; then
       echo "Successful key replacement for $i"
    else
       echo "Key replacement failed for $i"
    fi
done

This script will:

  1. Use the old key to append the new key to the remote authorized_keys
  2. Use the new key to remove the old key from the remote authorized_keys

The beauty is that if anything went wrong pushing the new key out, the removal of the old key will fail since it uses the new key, so you're less likely to shoot yourself in the foot.

You'll need to cache your passphrases with ssh-agent so that it doesn't prompt you for these uses of ssh; then just run it with the servers you want to update on the command line:

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-GWE6uxZxn9IS/agent.2016; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2017; export SSH_AGENT_PID;
echo Agent pid 2017;
$ ssh-add oldkey
Enter passphrase for oldkey: 
Identity added: oldkey (oldkey)
$ ssh-add newkey
Enter passphrase for newkey: 
Identity added: newkey (newkey)
$ ./chssh.sh server1 server2 server3
Successful key replacement for server1
Successful key replacement for server2
Successful key replacement for server3
$ 
gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 3
    There is a time cost associated with replacing the key, which could be non-negligible if you use that key for many different servers. You're probably right that in most cases, someone who is moderately security-conscious would consider the time cost an acceptable tradeoff for negating the risk of leaking an old version of the key. But I don't think it's necessarily a snap decision, i.e. not so cheap as to be practically free. – David Z Apr 05 '15 at 05:22
  • @DavidZ, ssh keys aren't just more secure, they enable automation as well. See my update to the answer; still pretty damn cheap. – gowenfawr Apr 05 '15 at 14:20
  • 2
    @gowenfawr You forget about other services such as Github, Bitbucket, Launchpad, Gerrit Code Review, gitolite configurations, ... SSH is not just used for shell access. – Lekensteyn Apr 05 '15 at 14:46
  • 2
    What @Lekensteyn mentioned is exactly what I had in mind. Or half of it anyway. The other half involves tracking down all the servers that you use the key on, which can't be automated (unless you are very meticulous about recording each time you upload the key). – David Z Apr 05 '15 at 15:49
  • 4
    You might want to use `ssh-copy-id` instead of catting the new key manually. –  Apr 07 '15 at 03:23
19

Changing the passphrase of an existing key can be done with:

ssh-keygen -p

...you are however not done by now. You also have to take consider copies of your old keys, these need to be removed or it should be treated as compromised. Think of backups, but also data on filesystems (copy-on-write filesystems such as ZFS and btrfs could keep a copy somewhere on the storage backend).

Changing your passphrase is a short-term solution if you believe that your keyfile file can be leaked. If you cannot be sure that all copies of your old private key are gone, then you should consider changing your private key file.

Do not forget about all services where your public key is attached too. Leaking your key is one issue, breaching other systems would be a bad side-effect.

Lekensteyn
  • 5,898
  • 5
  • 37
  • 62