Hacker News new | ask | show | jobs
by solatic 182 days ago
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.

2 comments

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

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

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

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

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.

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