Wandering Thoughts archives

When SSH needs you to decrypt your keys

Here's something nice but vaguely surprising that I just learned about how SSH handles encrypted keys. Start with the following in your .ssh/config:

Host *
  # encrypted key:
  IdentityFile /u/cks/.ssh/ids/key-ed2

Here's the question: suppose that you're not running ssh-agent and you try to ssh off to a host where you have an account that doesn't use this SSH key. Do you get prompted for the passphrase for your encrypted key? After all, your ssh client is going to try to use it to authenticate you, since it's your default key.

My naive expectation was that you would, but it turns out that I'm wrong. As you can see with 'ssh -v' (although it's not quite explicit), the SSH protocol is that the client first asks the server 'can I authenticate with this public key?' before proceeding to actually do so. When you have what I've casually called an encrypted SSH key, only the private key is actually encrypted; the public key is stored in the clear and your SSH client can send it off to the server without having to ask you for a passphrase. If the server declines the public key, that's it. Only if the server tells ssh 'sure, now prove you know the private key' does ssh need you to decrypt it and thus asks you for the key's passphrase.

In short, ssh only needs to know your key passphrase if it's about to authenticate you with it.

This has two consequences. The first is that if you get prompted to decrypt a SSH key, that's a good sign; you're about to be accepted if you can do so (well, normally, unless the server is playing funny games). This is unlike plain password prompts, where the server will demand a password even if you have no access and the remote login doesn't even exist.

The second is that it is relatively harmless to have additional encrypted SSH keys set up in your .ssh/config and offered to remote hosts. Specifically, you won't have your ssh commands interrupted to provide passphrases only to find out that you did it for nothing.

(Until I found this out just now it was a concern of mine, since I have a mix of encrypted general keys and narrow purpose unencrypted keys in .ssh/config and sometimes try things that ssh off to 'narrow purpose' destinations when I don't have ssh-agent up and active.)