Hardware Touch, Stronger SSH
Key topics
The quest for stronger SSH security has sparked a lively discussion, with commenters sharing their favorite methods for securing SSH keys, from using Yubikeys and ed25519-sk to leveraging the Secure Enclave on Apple Silicon devices. Some have found success with storing keys in password managers like KeepassXC, while others have highlighted the potential of Trusted Platform Modules (TPMs) for added security. As one commenter notes, corporate environments pose unique challenges, requiring complex setups to manage SSH certificates, but individuals have found creative workarounds, such as configuring separate `pushurl` settings in `.git/config` to simplify workflows. Amidst the varied approaches, a common thread emerges: the importance of securing SSH keys and making them portable across devices.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
4d
Peak period
41
96-108h
Avg / period
12.8
Based on 51 loaded comments
Key moments
- 01Story posted
Dec 22, 2025 at 3:23 AM EST
20 days ago
Step 01 - 02First comment
Dec 26, 2025 at 7:06 AM EST
4d after posting
Step 02 - 03Peak activity
41 comments in 96-108h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 27, 2025 at 6:19 PM EST
14 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
It only supports sk-ecdsa-sha2-nistp256 key format, however that is widely supported currently.
It makes my SSH key pretty portable across devices
This is my cue.
https://github.com/Foxboron/ssh-tpm-agent
Can git be configured to use different keys for push and pull? (You can obviously use different upstreams, but thats not as elegant.) Most git servers let you specify read vs read-write privileges (aka “deployment keys”) so you could use one key to pull updates that doesn’t need touch and another key to push (which does).
What they dropped was auth using your account name and password. You need to use a token as your password or use an extra tool like their cli client to setup auth (but it sucks if you have multiple accounts).
Would love to hear more from people getting this successfully set up at scale in corporate environments. I've seen big companies with lots of InfoSec talent not even attempt this.
(Tbh, a secure-desktop-integrated confirmation dialog would solve most issues that needed a hardware key to begin with.)
Yes, that's the exact problem at hand. If you generate your own local SSH key, the private key sits on the disk, and it can be stolen by malware (see article).
I'm asking how people set up the controls such that only hardware-based keys are signed by the CA.
This is the key advantage of hardware keys, the fact that the physical press is required prevents the keys from being exfiltrated from the machine by malware.
If you have malware capable of code execution, restricting the ability to issue one command is not going to be a meaningful control, especially with something like a physical touch which most users are just conditioned to accept, or can be trivially phished into accepting.
> plenty of time for malware to ship the cert back to a command-and-control server.
If your infrastructure cannot distinguish legitimate traffic, or you do not have a defensible network perimeter, again a physical touch is not going to be meaningful; it is not the panacea you are looking for.
I think things would be more secure with fewer prompts because i wouldn't be conditioned to just tap every time it pops up.
Secure elements prevent exfiltration. Touch requirements prevent on-device reuse by local malware.
And as a result of how they market their keys, decisions Fido keys are presented with a cost of $20 - $60. Why $60, for a simple Fido key? Because for $60 you get not only Fido, but Flippo, Froggo, x.6s8o and more-o.
The result is that most people know the name Yubikey, but don't really know Fido, or what it is. On Amazon if you search for Fido you get mostly Yubikeys. There were other brands, but Yubico appears to have snuffed them. At one point there was an open source version that worked just as well as a name brand.
As for value? If you are a big corporate type this is the cat's meow. But otherwise? What other hardware is $60? A Raspberry Pi 4? I can get little cheap USB thingies from China at 6 for a dollar.
I am not pointing at Yubico as they have done well making profits from corporations. Rather the Fido Alliance. Looking at the Fido Alliance provides a first pass at answering the question "Who Benefits?"
https://fidoalliance.org/overview/leadership/
Perhaps it is fair to ask "What benefit" as well.
Corpocracy. You gotta love it.
you can get that $5 china fido key, but are you sure it's you who owns it?
Seems like a moot point because it'd be very difficult for a rogue fido key to exfiltrate data. I'd be far more concerned about random chinese IOT gadgets, which most people don't have a problem with.
see Dual_EC_DRBG
However yes a very limited entropy in the private key is much harder to detect especially because on this kind of device you can't see the private key directly.
Getting the key out of rpi4 will be trivally easy if someone stoles it, not so much for hardware key.
I am surprised that competition didn't kept them in check, we're using them for more than a decade and the price just keeps slowly creeping in.
>https://fidoalliance.org/overview/leadership/
>Perhaps it is fair to ask "What benefit" as well.
>Corpocracy. You gotta love it.
You're really beating around the bush, trying to imply there's something shady going on, but don't articulate what it actually is. So let me ask: what's the conspiracy here? That the fido alliance is a front for an evil cabal of tech companies trying to... improve security? sell overpriced security keys?
If that is confusing here is link to the Friedman Doctrine that explains it. https://en.wikipedia.org/wiki/Friedman_doctrine
When we see a technology that appears beneficial and is not adopted, I think it is fair to wonder why that is.
For me the key points I ponder are:
- over several years I saw articles on HN that supposedly promoted Fido, but almost always they talked about Yubikeys. This continues.
- Solokeys built an open source Fido key. They were priced very low compared to Yubikeys, but functioned just as well. You could buy them on Amazon at one point (and I did)
- the Fido Alliance Accreditation fees https://fidoalliance.org/certification/authenticator-certifi...
So no. I do not see a conspiracy, I just see an array of corporations acting according to the Friedman Doctrine.
Perhaps a good question is what benefits might those corporations gain from their actions. Would Google and Apple benefit from broad adoption of Fido keys or would it somehow lessen their profits? I don't know the answer, but I know the question.
>When we see a technology that appears beneficial and is not adopted, I think it is fair to wonder why that is.
>...
>Perhaps a good question is what benefits might those corporations gain from their actions. Would Google and Apple benefit from broad adoption of Fido keys or would it somehow lessen their profits? I don't know the answer, but I know the question.
Again, I don't see any cogent arguments here aside from a vague anti-corporations sentiment along the lines of "corporations are greedy so they must be trying to oppress us at every opportunity". You mention "I think it is fair to wonder why that is", but you haven't articulate how hobbling u2f/fido/webauthn benefits the tech giants, when security is a huge pain point for them (both for their employees and their customers), and therefore they presumably benefit from it being adopted.
>- over several years I saw articles on HN that supposedly promoted Fido, but almost always they talked about Yubikeys. This continues.
Is there any evidence this was perpetuated by the fido alliance and/or their sponsors? Should we think there's a conspiracy by github because people confuse git with github?
>- Solokeys built an open source Fido key. They were priced very low compared to Yubikeys, but functioned just as well. You could buy them on Amazon at one point (and I did)
>- the Fido Alliance Accreditation fees https://fidoalliance.org/certification/authenticator-certifi...
What is this supposed to be evidence of? If anything this disproves your point that there can be competitors to yubikey.
Yes, the $60 is clear regulatory capture. It also sets back security by raising the barrier to using these devices.
Problem is really there is no good way for the prompt to have the name of actual app that asked when it is forwarded.
My personal strategy is to use keys generated this way:
ssh-keygen -t ed25519-sk
Rules:
- A generated key never leave the machine it was generated on.
- ssh agent is never used
- ProxyJump in HOME/.ssh/config or -J to have convenient access to all my servers.
- DynamicForward and firefox with foxyproxy extension to access various things in the remote network from my local machine (IPMI, internal services, IoT, ...)
- On the web no passkey, only simple 2FA webauthn.
My understanding is that more features including "storage" means more attack surface so by avoiding it you're 1/ more secure 2/ it's cheaper.
White paper on passkey says their security is equal to the security of the OS (Microsoft Windows ...) so I avoid passkeys.
> ssh-keygen(1) may be used to generate a FIDO token-backed key, after which they may be used much like any other key type supported by OpenSSH, so long as the hardware token is attached when the keys are used. FIDO tokens also generally require the user explicitly authorise operations by touching or tapping them.
> [...]
> This will yield a public and private key-pair. The private key file should be useless to an attacker who does not have access to the physical token. After generation, this key may be used like any other supported key in OpenSSH and may be listed in authorized_keys, added to ssh-agent(1), etc. The only additional stipulation is that the FIDO token that the key belongs to must be attached when the key is used.
1: https://www.openssh.org/txt/release-8.2#:~:text=The%20privat...
https://stephentanner.com/ssh-yubikey.html
Hopefully someone finds it useful.
The biggest issue I ran into was when folks wrote some tools that rely on ssh sock auth to automate connection to remote boxes. Not fun if you have to tap for every box.
Slightly different as I generate a PGP key on the computer and then load it to the Yubikey, which means I can have backup keys with the same secret keys.
I never really got "touch to use" working though, if anyone knows how to do it with GPG keys I'd really appreciate it!