It seems the required entitlements to access the Secure Enclave changed and broke the build for Catalina and above so it didn’t work for me. SEKey (also written in Rust) does this and it definitely worked…at some point. It’s such a great idea in fact that people have done it. Now, the Secure Enclave, sounds like a great idea. Key security is one of the whole reasons I’m here so I won’t settle for anything less than keys being protected by some sort of secure enclave. ![]() The result was a new library I called `sshcerts`. I kept a lot of the parsing code, but added a new private key module, certificate verification and signing, dozens of tests, an example that emulates `ssh-keygen -Lf`, among other things. Since I was going to be making such core changes to the library, I forked and rewrote most of it. The closest was `sshkeys`, a library which supports parsing SSH certificates but doesn’t validate them. In Rust but there isn’t much SSH certificate tooling. If the CA key is compromised, it’s even worse than stealing a user’s key because it can issue certificates for *any* user.Įven though it sounds like this is even worse than just using chef, these are programming issues, not systems issues, so I was willing to continue on. Now I need to secure a CA key *and* the local user key. A certificate has a list of authorized principals (users you can log in as) but not hosts. There is decent tooling for Go and Python, but not Rust. I need to write my own SSH certificate authority. Looking more into SSH certificates I now had the following issues: Even smaller if I can issue the certificate to be valid only for a certain server. Issuing a certificate for 2-5 seconds makes the window for abuse is very small. SSH certificates are great but they aren’t generally used in home deployments because certificate features like expiration, serial numbers, principals, allowed extensions, aren’t generally important to smaller deployments and just add complexity.Īlso while, certificates don’t solve the key security issue, it does solve the logging issue, if I use ultra short lived certificates. I know this is basically textbook “Use chef” but I’m not there, yet. Updating anything about logging needs to be updated everywhere or logging breaks. It also appears the full context is spread across multiple lines.Įvery host will need to report these logs, meaning every host needs telegraf. I.e bad password looks very different from bad key. The log format is complex, and seems to change significantly for slightly different connections. Maybe I’m just bad at log parsing but looking at the sshd logs gives me two problems: I wasn’t too broken up about this though because this solution didn’t solve my other biggest problem: centralized logging. Even though the Yubikey has 20 (!) extra slots for keys, SSH doesn’t see them.Įven if I weren’t, I might want to use them for mTLS certificates in the future meaning I’d have to erase my SSH keys, or just kick the key security can down the road to when I get there. I’m already using the authentication slot on my Yubikey for code signing, so I’d need a separate Yubikey. You can load a key on it, set some flags and it just works! I experimented with this but quickly ran into show stoppers. However it turns out SSH now supports smart cards for authentication. ![]() So do I just bite the bullet and use SSH keys as above? I could use OpenPGP and a Yubikey but that feels to me gross and add dependence on OpenPGP. Then I still need to enter a password though so the benefit didn’t feel there (even though it is).Ĭloud infrastructure has joined the fight. Now I really should be using keys, but then I need to update all the hosts, and where am I going to put the key to keep it secure? The best would be to encrypt the key and keep it in ~/.ssh. I have my own infrastructure that I need to access remotely using SSH and when it was just a couple servers in my closet, a password was fine.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |