Hacker News Reader

Comment by tanderson92 | Hacker News Reader

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

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).

View on HN

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.

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.

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.

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

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.

Getting there, dependency's in: https://github.com/solokeys/solo/pull/120

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.

I basically followed drduh's guide mentioned above. In particular, for the touch feature there is this subsection: https://github.com/drduh/YubiKey-Guide#touch-to-authenticate

Reply on news.ycombinator.com