Bulgarian mirror 10 Gbps

PuTTY wish ssh2-openssh-certkey-fallback

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

If you use a public key with an OpenSSH certificate as your user authentication key, it might be useful to have an easy way to treat it as being two keys in one: the version with the certificate, and the same key with the certificate removed. (The same private key works to generate signatures for either one.)

For example, you might set up a single private key that you use to log in everywhere; some of your destination hosts might accept it by virtue of a CA having signed it, and others might accept the same key because you directly entered it in their authorized_keys or equivalent. (The latter kind of host might not even be running an SSH server that speaks the certificate formats at all.) In that situation, it might be convenient to configure all your client connections the same way, so that PuTTY would offer the certified and uncertified versions of the same key and let each server decide which one it wants to accept.

In the current state of the certificates implementation, the only easy way to do that is to load both versions of the key into Pageant.

It would be possible to add a special-purpose 'automatic fallback' mode, in which any certified key that PuTTY received through any channel at all would be automatically offered to the server in both versions, whether it was in Pageant, or loaded from a certified PPK file, or created at run time via the detached certificate config option (so that the detached certificate was treated as optional).

I don't currently (as of 2022-07-30) plan to do this proactively, but I record the possibility here to see if anyone else thinks it would be useful.

(It would have to be a configurable option, because some servers will disconnect after too many authentication attempts, and each public key you offer counts as one. Also, some certificates are semantic, e.g. come with a particular forced command baked in; in that context, the certified and uncertified public keys aren't interchangeable.)