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 – RoraΖ Apr 4 '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 4 '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 4 '15 at 21:30
  • 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 5 '15 at 13:11
  • 1
    When generating a new key, consider using using stronger key derivation methods for your key (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 5 '15 at 14:53

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.


@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:


for i in $*
    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"
       echo "Key replacement failed for $i"

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;
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
  • 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 5 '15 at 5: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 5 '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 5 '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 5 '15 at 15:49
  • 4
    You might want to use ssh-copy-id instead of catting the new key manually. – blujay Apr 7 '15 at 3:23

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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