upvote

points

by cyberax13 hours ago |
comments
upvoteby Dragging-Syrup12 hours ago|
next
[-]
I’m sorry to be pedantic, that’s not exactly true. I agree in the sense that extracting hw based keys is next to impossible, but if your machine is compromised, there isn’t much stopping malware from using your hw based key (assuming 1. Left plugged in, 2. Unlocked with either ssh-agent or gpg-agent, and 3. You don’t have touch to auth turned on). Reduced risk? Absolutely. No risk? Absolutely not.
reply
upvoteby traceroute662 hours ago|
parent|
next
[-]
> there isn’t much stopping malware from using your hw based key

Except the three pretty major things that do stop malware that you mentioned ;)

Perhaps especially "3. You don’t have touch to auth turned on".

reply
upvoteby bloppe12 hours ago|
parent|
prev|
next
[-]
Never apologize for pedantry here
reply
upvoteby cyberax12 hours ago|
parent|
prev|
next
[-]
Sure. They can use my key while my machine is compromised, but even then I won't _need_ to rotate it after the compromise is cleared.

It still would be a good idea just to make sure that it's easier to analyze logs, but it's not strictly needed.

reply
upvoteby hsbauauvhabzb12 hours ago|
parent|
prev|
[-]
And if you want to be even more pedantic, shell access with a touch based key just means the attacker has to wait for you to auth, which makes touch based systems largely a waste of effort on the defenders part.
reply
upvoteby traceroute662 hours ago|
parent|
next
[-]
> shell access with a touch based key just means the attacker has to wait for you to auth

And if you want to be EVEN more pedantic, on most touch-based keys, you have to touch within 10–15 seconds otherwise it times out.

So it is not a waste of effort at all. First the need to touch at all eliminates a large chunk of attacks. Second the need to touch within 10–15 seconds eliminates a whole bunch more.

There would have to be some heavy-duty alignment of ducks going on to get past a touch requirement.

Even more if the target has touch AND PIN enabled.

reply
upvoteby entrope2 hours ago|
parent|
prev|
[-]
The touch based key I use only responds once per touch. If someone compromises the machine it's plugged into, the action I expected to complete won't complete. This means the compromise becomes immediately visible.
reply
upvoteby kkl11 hours ago|
prev|
[-]
Part of the threat model for an Engineering team is that people come and go. They move teams which have different levels of access. They leave the organization, in most cases, on good terms. I want to set up infrastructure where I don't need to remember that your SSH pubkey is baked into production configuration after you leave the company.

There are several options for setting up per-connection keys that are dispensed to users through the company SSO. That setup means you don't need to maintain separate infrastructure for (de-)provisioning SSH keys.

reply
upvoteby cyberax10 hours ago|
parent|
[-]
This is completely solved by SSH certificates. You still have the same private key in the hardware, but instead of using the public key directly, you issue temporary (~1 hour) SSH key certificates. I even automated it using an SSH proxy.

The target machines then just need to put the CA cert in the authorized_keys files.

reply
upvoteby lelanthran5 hours ago|
parent|
[-]
> The target machines then just need to put the CA cert in the authorized_keys files.

The word "just" is doing a lot of work there. You update authorized_keys every hour for your entire fleet?

reply
upvoteby winstonwinston3 hours ago|
parent|
next
[-]
No, the ssh CA model works like this: servers trust one CA, and the CA signs user keys. No more distributing individual public keys to every machine.

It is the user machine that needs new certificate signed by the CA once the short-lived one expires.

reply
upvoteby lelanthran1 hours ago|
parent|
[-]
Understood. Not a bad idea.
reply
upvoteby pyvpx4 hours ago|
parent|
prev|
[-]
Sounds like a job for dnssec and sshfp records

Ahh, now you have three problems…hrm

reply