4 ms·
> The amount of people who understand terms like 'grok', but don't know how to use SSH certificates is effectively zero. I don’t want to be antagonistic but th
by mmalone 7y ago
> The amount of people who understand terms like 'grok', but don't know how to use SSH certificates is effectively zero.
I don’t want to be antagonistic but that’s just not true. I’ve talked to a lot of people about this. Maybe 10% of people I’ve talked to know how to use ssh certs. These are technical people who are very smart and know what they are doing, and know what “grok” means. That’s why I wrote the post.
If you already knew the info in the post then cool! Sorry to waste your time.
- teh_klev 7y agoYou got my attention. I've got ~25 years Unix/Linux experience under my belt and didn't know about SSH certs and now I do. So appreciated.
- mmalone 7y ago<3
- archi42 7y agoSimilar here: Even though I was somewhat aware ssh could do some PKI magic, I didn't CONSIDER deploying it. But I'll try to get our sysadmins to use it. Having U2F/FIDO support seems like THE big bonus to me (also I'd like to replace that ancient HTTP basic auth on our intranet with something more user friendly and add U2F as well). So huge thanks for the article! OTOH, key deployment depends on the situation and size. We have a single office (=> no network bottlenecks), our /home lives on a central NFS and machines pull their users from LDAP. When I joined the company, after I got my account, I ran `ssh-keygen`, set my keyphrase and could connect to any machine. If someone quits, the LDAP user is removed. Regarding TOFU: I think we have some admin.git which contains all machines, and their public keys are distributed from there. So no TOFU for us. With PKI this central repo of machines wouldn't magically go away, the script would be just someone else's/your's (and it would be technically cleaner). Also, when reusing hostnames the deployment system could reuse the sshd keys instead of creating new ones.