Modern yubikeys support sk-* type SSH keys which allow storing the SSH private key in the yubikey itself so that it's not possible to export / steal it, even in case of a laptop compromise. The UX is great in some aspects (I have to touch the yubikey when SSHing, giving me high confidence that I'm taking the correct action) and poor in others (setup & configuration, compatibility, lack of UI indications when waiting for the touch).
It would be great to look into supporting these key types. This would probably encompass a few tasks:
Identify which parts of our infra do or do not support this key type (ex: Github does, older Ubuntu versions don't)
Identify possible fallbacks workaround or how to coexist when accessing supported/unsupported infra
Create documentation for end users, do user testing
Do automation to set it up automatically / in a guided way
Mandate it as the primary/exclusive option (similar to notifying users about unprotected private keys)
Trishank noted that there were possibly other options related to key storage but the main thing I appreciate about this mechanism is that it requires a physical touch for usage of the SSH key. I think there may be some other ways to achieve the same thing (e.g. with secure enclave on macOS (1, 2). The main advantage of these types of mechanism is the "2fa-like" requirement to do a physical confirmation touch when signing in with the key. This provides strong security and protection against unintentional exposure. For example, the new workspaces dev environments set up SSH agent forwarding by default and this would mean that keys wouldn't be straightforwardly stolen/used if a workspace is a compromised.
Modern yubikeys support
sk-*type SSH keys which allow storing the SSH private key in the yubikey itself so that it's not possible to export / steal it, even in case of a laptop compromise. The UX is great in some aspects (I have to touch the yubikey when SSHing, giving me high confidence that I'm taking the correct action) and poor in others (setup & configuration, compatibility, lack of UI indications when waiting for the touch).It would be great to look into supporting these key types. This would probably encompass a few tasks:
Trishank noted that there were possibly other options related to key storage but the main thing I appreciate about this mechanism is that it requires a physical touch for usage of the SSH key. I think there may be some other ways to achieve the same thing (e.g. with secure enclave on macOS (1, 2). The main advantage of these types of mechanism is the "2fa-like" requirement to do a physical confirmation touch when signing in with the key. This provides strong security and protection against unintentional exposure. For example, the new workspaces dev environments set up SSH agent forwarding by default and this would mean that keys wouldn't be straightforwardly stolen/used if a workspace is a compromised.