5 ms·

For a different approach (this approach is mentioned briefly at the beginning of the post, and dismissed with "I did not like that very much"), see also drduh's

For a different approach (this approach is mentioned briefly at the beginning of the post, and dismissed with "I did not like that very much"), see also drduh's Yubikey guide: https://github.com/drduh/YubiKey-Guide#ssh https://github.com/drduh/YubiKey-Guide#ssh Note that the PIV approach used in the OP does not support RSA4096, while the OpenPGP approach does (since Yubikeys support RSA4096 in OpenPGP mode but not in PIV mode).

deleted 8y ago
[deleted]
akerl_ 8y ago
One upside of PIV-for-SSH rather than GPG-for-SSH is that the Yubikey support for PIV touch requirements / PIN lockouts is more powerful. You can set the PIN to lock after $n fails, and require reset after $n admin PIN fails, and you can set it to require physical touch to auth/sign/etc. That carries over for SSH: in the most strict touch-mode, a separate touch is required for each authentication attempt. This requirement holds true even if you were to forward your SSH agent to the remote host: SSHing from there to another system would require another physical touch.
- tanderson92 8y ago
  I also have configured my Yubikey 4 to require a physical touch for every SSH auth attempt even in GPG-for-SSH. The PIN stuff also carries over to my knowledge -- at least, I need to use my user PIN to unlock my SSH key for the first attempt (subsequent ones require a touch). It's possible that the configuration I am using is not well-known, but it appears to match exactly the PIV case you describe. Except perhaps the n=3 is fixed for GPG-for-SSH (not sure about this) and you think n=/=3 is a valuable configuration option? (not sure about the SSH agent forwarding as I haven't tested that, would be surprised if it worked without a physical touch) Basically I don't see the differences you describe in day to day usage at all.
  - ecesena 8y ago
    Independent and out of curiosity, do you ever have to run things like a cmd over ssh in parallel across multiple servers? Just curious to understand if a “long touch” or something that “unlocks” your private key temporarily would be interesting. Disclaimer: I work on Solo key, we’re thinking to what’s the best way to support ssh.
    - LIV2 8y ago
      There is a touch policy called "cached" which allows signing operations for 15 seconds after a touch so you can do many connections at once
    - tanderson92 8y ago
      I don’t do that and it wouldn’t be useful for me personally, but I’m just a single data point. What's much more important for me is the underlying capabilities -- a key which supports rsa4096 is great, a key which supports curve25519 in some fashion would be incredible.
      - ecesena 8y ago
        Getting there, dependency's in: https://github.com/solokeys/solo/pull/120 https://github.com/solokeys/solo/pull/120
  - akerl_ 8y ago
    Would you be willing to share the way you've configured the GPG setup? Definitely curious for making it work like this. The last time I looked at it, I could make it require touch/PIN the first time the GPG key was used, but after it got loaded into gpg-agent, it continued to work for the lifetime of the agent w/o PIN/touch. That said, I'm entirely willing to admit the possibility I missed the right flags to do what I wanted. I do like n =/= 1 in general (I've provisioned some yubikeys where the person using the key doesn't have the admin PIN, and so I like to give myself a bit more buffer before I have to meet up with them to unlock the key, but for my own keys, n == 3 would be totally fine.

deleted 8y ago

[deleted]

akerl_ 8y ago

One upside of PIV-for-SSH rather than GPG-for-SSH is that the Yubikey support for PIV touch requirements / PIN lockouts is more powerful. You can set the PIN to lock after $n fails, and require reset after $n admin PIN fails, and you can set it to require physical touch to auth/sign/etc. That carries over for SSH: in the most strict touch-mode, a separate touch is required for each authentication attempt. This requirement holds true even if you were to forward your SSH agent to the remote host: SSHing from there to another system would require another physical touch.

tanderson92 8y ago
I also have configured my Yubikey 4 to require a physical touch for every SSH auth attempt even in GPG-for-SSH. The PIN stuff also carries over to my knowledge -- at least, I need to use my user PIN to unlock my SSH key for the first attempt (subsequent ones require a touch). It's possible that the configuration I am using is not well-known, but it appears to match exactly the PIV case you describe. Except perhaps the n=3 is fixed for GPG-for-SSH (not sure about this) and you think n=/=3 is a valuable configuration option? (not sure about the SSH agent forwarding as I haven't tested that, would be surprised if it worked without a physical touch) Basically I don't see the differences you describe in day to day usage at all.
- ecesena 8y ago
  Independent and out of curiosity, do you ever have to run things like a cmd over ssh in parallel across multiple servers? Just curious to understand if a “long touch” or something that “unlocks” your private key temporarily would be interesting. Disclaimer: I work on Solo key, we’re thinking to what’s the best way to support ssh.
  - LIV2 8y ago
    There is a touch policy called "cached" which allows signing operations for 15 seconds after a touch so you can do many connections at once
  - tanderson92 8y ago
    I don’t do that and it wouldn’t be useful for me personally, but I’m just a single data point. What's much more important for me is the underlying capabilities -- a key which supports rsa4096 is great, a key which supports curve25519 in some fashion would be incredible.
    - ecesena 8y ago
      Getting there, dependency's in: https://github.com/solokeys/solo/pull/120 https://github.com/solokeys/solo/pull/120
- akerl_ 8y ago
  Would you be willing to share the way you've configured the GPG setup? Definitely curious for making it work like this. The last time I looked at it, I could make it require touch/PIN the first time the GPG key was used, but after it got loaded into gpg-agent, it continued to work for the lifetime of the agent w/o PIN/touch. That said, I'm entirely willing to admit the possibility I missed the right flags to do what I wanted. I do like n =/= 1 in general (I've provisioned some yubikeys where the person using the key doesn't have the admin PIN, and so I like to give myself a bit more buffer before I have to meet up with them to unlock the key, but for my own keys, n == 3 would be totally fine.