[HN Gopher] Hardware Touch, Stronger SSH
___________________________________________________________________
Hardware Touch, Stronger SSH
Author : furkansahin
Score : 52 points
Date : 2025-12-22 08:23 UTC (4 days ago)
(HTM) web link (www.ubicloud.com)
(TXT) w3m dump (www.ubicloud.com)
| olivermuty wrote:
| Filler pr jippo fluffer article aside, anyone tried to self host
| ubicloud lately? A year and a half ago it was super cumbersome,
| wondering if I should give it a new try now.
| antonkochubey wrote:
| On Apple Silicon devices with macOS 26+, SSH keys can be natively
| stored in the Secure Enclave, protected via TouchID:
| https://news.ycombinator.com/item?id=46025721
|
| It only supports sk-ecdsa-sha2-nistp256 key format, however that
| is widely supported currently.
| XiS wrote:
| Been using ed25519-sk with Yubikey for a few years now. Key is
| stored in KeepassXC and loaded in my SSH agent upon unlock.
|
| It makes my SSH key pretty portable across devices
| throwawayqqq11 wrote:
| My approach aswell. Lock down ssh-agent and restrict its
| usage as much as possible. Securing your keys is also very
| reasonable but it cant silence this naging voice in the back
| of my head that keeps reminding me of a compromised ssh-agent
| or shell, whenever i authorize privileged actions.
| Almondsetat wrote:
| You can also do something similar with any computer that has a
| TPM. It's unfortunate that people don't really know about it,
| but I guess the tools available aren't that user friendly
| Foxboron wrote:
| > It's unfortunate that people don't really know about it,
| but I guess the tools available aren't that user friendly
|
| This is my cue.
|
| https://github.com/Foxboron/ssh-tpm-agent
| Sublevel5169 wrote:
| Thank you for sharing!
| sebazzz wrote:
| SSH using GPG Yubikeys and git signing using GPG was quite a
| process to set up on Windows a few years ago. Not something I'd
| want or know how to repeat. Hopefully things have improved in the
| mean time.
| heavyset_go wrote:
| You can use SSH keys for signing now, so you don't need GPG at
| all.
| simon04 wrote:
| Using a Token2 based id_ed25519_sk_rk key, I found very helpful
| to configure a different `pushurl` in `.git/config`. This allows
| to pull via HTTPS w/o a hardware touch. [remote
| "origin"] url =
| https://github.com/freeCodeCamp/devdocs.git
| pushurl = git@github.com:freeCodeCamp/devdocs.git
| ComputerGuru wrote:
| GitHub dropped http authentication so this only works for
| public repos (not that the UX or security of http auth for git
| is nice).
|
| 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).
| baobun wrote:
| You configure separate entriea in your ssh conf.
| Host gh-auth Hostname github.com
| Identityfile blah User git
|
| pushurl = gh-auth:freeCodeCamp/devdocs.git
| solatic wrote:
| This is how you handle it as an individual developer, but in a
| corporate environment things get real difficult, real fast. You
| need to set up your VMs and Git host to only trust certificates
| signed by an SSH certificate authority, and you need to work with
| users to submit the public key from the hardware-backed key to IT
| (controlling the CA) to get the public key signed and a
| certificate issued. Establishing trust when dealing with remote
| workers is hard unless you have both the budget and leadership
| patience to pay for overnight shipping, and even then, most
| people don't have access to tamper-proof packaging. Furthermore,
| for SSH CA support, GitHub requires Enterprise Cloud, GitLab
| requires Premium and self-hosted instances are not supported.
|
| 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.
| connicpu wrote:
| I can't speak to actually setting it up, but where I work we
| have an IT-provided yubikey ssh-agent that handles getting all
| that stuff set up, and we just paste the public key from our
| individual yubikeys into our authorized ssh keys with our on-
| prem-hosted bitbucket server. However almost everyone I know
| quickly gets sick of touching the yubikey for every git remote
| operation and just generates their own local SSH key to use for
| git since doing so is not forbidden. It's definitely not High
| Security, but since our git is on-prem and can only be accessed
| from within the corporate VPN the risks are probably lower than
| if we were using something shared on the public internet.
| solatic wrote:
| > almost everyone I know quickly gets sick of touching the
| yubikey for every git remote operation and just generates
| their own local SSH key to use for git since doing so is not
| forbidden
|
| 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.
| ComputerGuru wrote:
| The obvious solution is an ssh-agent integration that caches
| the touch-derived key for up to N hours or until the
| workstation is locked (as a proxy for user-is-away event),
| AND integrates with secure desktop (a la UAC) to securely
| show a software-only confirmation prompt/dialog for
| subsequent pushes within the timeout window.
|
| (Tbh, a secure-desktop-integrated confirmation dialog would
| solve most issues that needed a hardware key to begin with.)
| DetectDefect wrote:
| If you aready have an SSH CA, why not just issue ephemeral
| certs lasting for several seconds or minutes? What risk would
| be addressed by adding hardware keys into the mix?
| solatic wrote:
| How do you prevent malware running on the pwned laptop from
| asking for an ephemeral cert to be issued? How do you know a
| human being is in the loop? Usually ephemeral sessions are up
| to 15 minutes (also to deal with misaligned clocks and
| unhappy users) - plenty of time for malware to ship the cert
| back to a command-and-control server.
|
| 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.
| lmz wrote:
| > 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.
|
| Secure elements prevent exfiltration. Touch requirements
| prevent on-device reuse by local malware.
| DetectDefect wrote:
| > How do you prevent malware running on the pwned laptop
| from asking for an ephemeral cert to be issued?
|
| 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.
| 8n4vidtmkvmk wrote:
| I'd be fished in a heartbeat. I have to tap my key like
| 10 times every morning and then several times more
| throughout the day due to random logouts. Could be my
| IDE, a broken SSH connection or internal site that
| randomly decides to request it again and of course the
| popup gives no indication to where the request came from.
| It's ridiculous.
|
| I think things would be more secure with _fewer_ prompts
| because i wouldn 't be conditioned to just tap every time
| it pops up.
| talkingtab wrote:
| In my opinion only, Yubico has done no favors to the Fido by
| their marketing. A result of trying to make Yubikey synonymous
| with Fido, it has become unclear what Fido does.
|
| 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.
| machinationu wrote:
| while you are right, security is generally not cheap.
|
| you can get that $5 china fido key, but are you sure it's you
| who owns it?
|
| I was recently looking for a security key, and eventually I did
| pay the yubico tax, because saving $20 by getting another one
| seemed unwise given the stakes.
| gruez wrote:
| >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.
| the8472 wrote:
| Couldn't they ship pre-compromised? Storing the RNG seed
| and private key at the factory.
| ComputerGuru wrote:
| Devil's advocate: How do they map that data to a user
| when you are buying through a maze of resellers?
| machinationu wrote:
| they dont, they try against all the keys, there are at
| most a few billion of them
|
| see Dual_EC_DRBG
| petee wrote:
| One issue i see is that it's a sealed package; it wouldn't
| be immediately apparent if someone added extra
| hardware/functionality.
|
| More likely though I'd expect you'd just get some form of a
| clone device
| master_crab wrote:
| Most Government organizations mandate FIPS Yubikey's that are
| outrageously priced.
|
| Yes, the $60 is clear regulatory capture. It also sets back
| security by raising the barrier to using these devices.
| PunchyHamster wrote:
| You're paying for brand and the fact they make key exfiltration
| very hard.
|
| 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.
| layer8 wrote:
| Run-off-the-mill smart cards have had non-extractable keys
| for decades. They only cost cents in manufacturing.
| gruez wrote:
| >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'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?
| talkingtab wrote:
| This is not a conspiracy. This is just corporations acting in
| their best interest. Exactly the same as MicroSoft acted in
| their best interest as described here: https://en.wikipedia.o
| rg/wiki/United_States_v._Microsoft_Cor....
|
| 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.
| gruez wrote:
| >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.
|
| >...
|
| >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.
| machinationu wrote:
| How will this work with agents?
| shim__ wrote:
| That's the neat part, it doesn't
| PunchyHamster wrote:
| Now that's just incorrect
| PunchyHamster wrote:
| You just get a prompt.
|
| Problem is really there is no good way for the prompt to have
| the name of actual app that asked when it is forwarded.
| guerby wrote:
| I bought several "Security Key NFC by Yubico": their cheapest
| model, no storage or fancy stuff.
|
| 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.
| PunchyHamster wrote:
| The more expensive one works as smart card so you can both
| generate and keep the key as hardware only. Works for SSH and
| GPG too
| smileybarry wrote:
| The generated FIDO keys with "[...]-sk" are hardware-only
| too, the "key" you load is only an "identifier" associating
| the onboard passkey, allowing you to add it on multiple
| computers but still requiring the FIDO key present to use[1]:
|
| > 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._
|
| IMO the baseline Security Key ($20) series is now enough,
| unless your setup uses PGP, legacy SSH that doesn't support
| these key types, or if you're using a real certificate for
| e.g. code signing.
|
| 1: https://www.openssh.org/txt/release-8.2#:~:text=The%20priv
| at...
| tasn wrote:
| This is how I've been doing it: https://stosb.com/blog/using-
| openpgp-keys-for-ssh-authentica...
|
| 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!
| ratdragon wrote:
| ssh-add -c (confirm) can somehow mitigate the "misuse of ssh-
| agent in the background" the article is talking about
| clait wrote:
| Could someone please explain to me why this would be better than
| storing the key with 1Password and biometric authentication?
___________________________________________________________________
(page generated 2025-12-26 23:01 UTC)