== 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_:

.pn prewrap on
>  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 https://github.com/siebenmann/]] in _.ssh/config_ and sometimes
try things that ssh off to 'narrow purpose' destinations when I
don't have _ssh-agent_ up and active.)