5 ms·

Can you use pyu2f with ssh? It’d be great to have a ssh binding to fido2, with full support for new algos and resident keys, instead of gpg/pkcs11.

dfox 8y ago
I don't think that there is existing solution for that, but it should not be too hard to implement one.
- ecesena 8y ago
  Yeah, I'm just afraid about people having to install ssh plugins vs gpg which is widely accepted and packaged. :/
tialaramex 8y ago
This can't work technically without a new SSH auth method. The SSH public key auth method goes like this: 1. Client "I want to do SSH public key auth. I can prove I know the corresponding private key for key X" 2. Server (typically checks authorized_keys file to decide) may say "OK, yes, prove that" 3. Client signs per session data with key to prove possession [it may use the proxy technology to have this done by a different client]. But a FIDO2 / CTAP key needs things to go the other way around 1. Client "I want to try FIDO2" 2. Server "OK, here is a Cookie. Can you prove you know the associated private key?" 3. Client uses CTAP protocol to verify that the Yubikey recognises this cookie and gets back a proof, sends it to server. In the current world SSH clients know which keys they know, so they can begin by telling the server, but in the FIDO world the Security Key is deliberately too dumb to even know this, it has to be prompted with a cookie. This is because of a correlation attack [edit: maybe that's the wrong word? The attack is a bad guy figures out who you are based on seeing you connect with this key in many places], which was not considered a big threat for SSH but is clearly a problem on the Web. So FIDO SecurityKeys are engineered to resist correlation by being so dumb that even they don't know if they know your Facebook keys, until Facebook says "Hi, do you know the keys that go with this cookie?" when you try to log in as you. You can somewhat defend against correlation attack in SSH if it worries you by the way, by explicitly configuring a particular public key for each connection and forbidding the client from trying other keys (which it will by default) using IdentitiesOnly and IdentityFile in OpenSSH.
- ak217 8y ago
  SSH supports multiple methods of authentication, including challenge-response authentication, which is specifically designed for the kind of exchange that FIDO2/CTAP uses.
  - tialaramex 8y ago
    Blergh. RFC 4256, which I'd guess is what you're thinking about, aka keyboard-interactive - is completely unsuitable for this purpose and certainly wasn't "specifically designed" for it. In fact RFC 4256 pretty much spells out what it's for, it lets you use PAM to augment your authentication policies by changing what the remote user types into their console. You can add a One Time Password check or whatever. It is full of requirements like "A command line interface (CLI) client SHOULD print the name and instruction (if non-empty), adding newlines" which have nothing whatsoever to do with the actual problem for Security Keys. Of course you could _add_ a new SSH authentication method, but the existing RFC 4256 "challenge-response" approach is completely inappropriate.
    - ak217 8y ago
      Good to know, thanks, I didn't know challenge-response support in sshd was specifically tied to RFC 4256. With that said, I suspect it could be retrofitted for this purpose.

dfox 8y ago

I don't think that there is existing solution for that, but it should not be too hard to implement one.

ecesena 8y ago
Yeah, I'm just afraid about people having to install ssh plugins vs gpg which is widely accepted and packaged. :/

tialaramex 8y ago

This can't work technically without a new SSH auth method. The SSH public key auth method goes like this: 1. Client "I want to do SSH public key auth. I can prove I know the corresponding private key for key X" 2. Server (typically checks authorized_keys file to decide) may say "OK, yes, prove that" 3. Client signs per session data with key to prove possession [it may use the proxy technology to have this done by a different client]. But a FIDO2 / CTAP key needs things to go the other way around 1. Client "I want to try FIDO2" 2. Server "OK, here is a Cookie. Can you prove you know the associated private key?" 3. Client uses CTAP protocol to verify that the Yubikey recognises this cookie and gets back a proof, sends it to server. In the current world SSH clients know which keys they know, so they can begin by telling the server, but in the FIDO world the Security Key is deliberately too dumb to even know this, it has to be prompted with a cookie. This is because of a correlation attack [edit: maybe that's the wrong word? The attack is a bad guy figures out who you are based on seeing you connect with this key in many places], which was not considered a big threat for SSH but is clearly a problem on the Web. So FIDO SecurityKeys are engineered to resist correlation by being so dumb that even they don't know if they know your Facebook keys, until Facebook says "Hi, do you know the keys that go with this cookie?" when you try to log in as you. You can somewhat defend against correlation attack in SSH if it worries you by the way, by explicitly configuring a particular public key for each connection and forbidding the client from trying other keys (which it will by default) using IdentitiesOnly and IdentityFile in OpenSSH.

ak217 8y ago
SSH supports multiple methods of authentication, including challenge-response authentication, which is specifically designed for the kind of exchange that FIDO2/CTAP uses.
- tialaramex 8y ago
  Blergh. RFC 4256, which I'd guess is what you're thinking about, aka keyboard-interactive - is completely unsuitable for this purpose and certainly wasn't "specifically designed" for it. In fact RFC 4256 pretty much spells out what it's for, it lets you use PAM to augment your authentication policies by changing what the remote user types into their console. You can add a One Time Password check or whatever. It is full of requirements like "A command line interface (CLI) client SHOULD print the name and instruction (if non-empty), adding newlines" which have nothing whatsoever to do with the actual problem for Security Keys. Of course you could _add_ a new SSH authentication method, but the existing RFC 4256 "challenge-response" approach is completely inappropriate.
  - ak217 8y ago
    Good to know, thanks, I didn't know challenge-response support in sshd was specifically tied to RFC 4256. With that said, I suspect it could be retrofitted for this purpose.