5 ms·
No, this is what ssh certs are for. You can use any key you want as long as you get a CA that everything trusts to sign it.
by ikiris 4y ago
No, this is what ssh certs are for.
You can use any key you want as long as you get a CA that everything trusts to sign it.
- booi 4y agohmm, where do you store the CA private key? We're just going around in circles
- deleted 4y ago[deleted]
- ikiris 4y agoin a safe at the bottom of the ocean? who cares, put an intermediate signer in a cloud somewhere that requires 2FA with multiple valid tokens, and everything is now much more secure and not tied to your specific key.
- chasil 4y agoI think it's more nuanced. SMP and hyperthreading are risky for security. Closed firmware is also concerning. Older systems without these architectural features are more difficult to abuse. I would find one of these if I needed a secure SSH CA for myself, and use OpenBSD. I probably couldn't get away with that in a larger organization.
- friendzis 4y ago> hmm, where do you store the CA private key? On another device. > We're just going around in circles Depends on attack vector. Both solutions store private key in HSM and hence protect against "attacker gains access to local memory/storage". However, ssh certs allow key to be "regenerated". HSM'd keys are subject to "device got lost/destroyed" attack, HSM'd certs are subject to "CA got compromised". Pick your poison.
- mbreese 4y agoThe point isn’t how to secure the CA’s private key. The point is that this is a separate system that is probably easier to secure. Physically, it’s probably in a data center. If you want to, you could have the CA key loaded into memory at boot time with a removable USB drive. That key should be easier to protect than a private key on an end user computer, Secure Enclave or not.