6 ms·
I store my authorized_keys in DNS TXT records, that are DNSSEC signed, with a validating resolver on the box. I then just use "/usr/bin/hesinfo %u ssh" as my Au
by dotwaffle 4y ago
I store my authorized_keys in DNS TXT records, that are DNSSEC signed, with a validating resolver on the box. I then just use "/usr/bin/hesinfo %u ssh" as my AuthorizedKeysCommand in OpenSSH.
I wrote a little tool that allowed you to "#include" other DNS records etc, but "hesinfo" is generally easily installable/available so it's just easier.
- aliqot 4y agoIs there some way I can purchase you a pint?
- dotwaffle 4y agoIt would be rude of me to decline such an offer ;)
- bshep 4y agoI would love a HOWTO link. Also, can the DNS server be public facing? Any issues with the authorized keys being public (AFAICT there isnt but i am not a security expert)?
- theblazehen 4y agoThere are none. In fact yours is already public: https://github.com/bshep.keys https://github.com/bshep.keys
- bombcar 4y agoThere is technically one minor one, which really isn't one - but you should be aware of. Someone can take your authorized keys and add them to a box they control, and trick you into logging in. However, this would trigger the "new host" warning SSH gives you, and you can minimize this by minimizing which hosts you allow your private keys to be used on. And if someone is so actively trying to attack you they probably have more direct methods available.
- dcow 4y agoWhat? How? What does putting my authorized keys file on another host do in terms of tricking me to log in? Authorized keys only matters on the host you are using when you type `ssh <some.host>`. The ssh client compares the public key of the remote host to the list in your `authorized_keys` file and, only if there is a match, skips serving you TOFU. EDIT: I mixed up authorized_keys and known_hosts. But, the remote server doesn't need your authorized_keys file to grant you access so not sure the visibility of authorized_keys matters.
- cubesnooper 4y agoYou’re thinking of known_hosts, not authorized_keys.
- lapser 4y agoThis wouldn't matter anyway because the server can just give you access regardless of the auth provided.
- archi42 4y agoUnless your keys are generated with low entropy (like the Debian CVE-2008-0166), publishing the public key file should not be an issue; that's from a cryptographic pov. & as bombcar said, obviously if you ignore "unknown host" warnings, you can be tricked into logging into an attacker-controlled machine. Often key files also contain "user@host" for the user&host the key was generated by&on. This identifier is then leaked, and you might want to avoid that. On my personal (and very objective! /s) paranoia scale this a 8/10. I'd definitely point it out to a customer during a pentest, but wouldn't really care if they "fixed" this (most of the time there is a lot of stuff that's more serious than knowing that the devops person is 'bro2000@jims-laptop').
- dotwaffle 4y agoSSHFP records largely solves the host key problem, but yes, the user is the weak point in the chain there.
- encryptluks2 4y agoA public key can be an identifier. Depending on what other information you share online or if a key is reused on GitHub it can be used to identify other places you visit and other artifacts associated with you. If your goal is anonymity then keeping you public keys secret or not attached to other personal information like a domain name is ideal. Almost all registrars are going to have a way to reveal your true identity.
- colechristensen 4y agoHesiod, now there’s a name I haven’t heard in a long time https://en.m.wikipedia.org/wiki/Hesiod_(name_service) https://en.m.wikipedia.org/wiki/Hesiod_(name_service)
- snowstormsun 4y agodoesn't this approach run into caching problems?
- strobegoodsong 4y agoPlease write a blog on this
- dotwaffle 4y agoA blog on this.
- dotwaffle 4y agoAnd I may well do. But it's probably not the best idea to do this on a larger scale, there are valid reasons why this is not a good thing to recommend -- if you miss one part (DNSSEC signing, or running a local validating resolver) you can end up with a vulnerable system.
- candiddevmike 4y agoThis method puts a lot of reliance on DNSSEC working and trusting that it is preventing spoofing. I personally wouldn't rely on this in production, there are too many stories about DNSSEC cutovers rendering the domain unresolvable for hours+. Imagine not being able to get to your servers too...!
- dotwaffle 4y agoMy DNS zones are not hosted on those servers, Google Cloud DNS does the dnssec signing, and there is a breakglass key installed on there too that when used automatically sends alerts out.
- witcH 4y agoa fine bit of wizardry, thanks for sharing.
- tptacek 4y agoI know people do this, but I can't get my head around it. SSH is end-to-end secure even if the entire DNS hierarchy is corrupted. The DNSSEC PKI is controlled at its roots by governments, and one level of branches down by a set of companies not known for integrity and especially strong security practices. Why would you give any of these entities any influence over your authorized keys?
- Fnoord 4y agoDNSSEC is top-down securing chain, DNSCrypt bottom-up. Each has their pros and cons. Relying on your government to keep you secure can be a valuable factor, depending on your threat model.
- tptacek 4y agoOk, these are words, but again I'm not talking about DNS security here, I'm talking about SSH key distribution. Why would you elect to have your key distribution controlled by the DNS PKI? What's the upside? The downside is, an actor with control over the DNS PKI (there are many of those; see, for instance, every DOJ seizure of a domain) gets a degree of control over your SSH authorized keys. Seems... bad?
- deleted 4y ago[deleted]
- gunapologist99 4y agoAgreed completely. The threat model for DNSSEC is vast; why would you diminish the security of a perfectly good end-to-end model in SSH keys or certificates, as long as you control 100% of that infrastructure. Introducing any outside actors at all objectively diminishes the security of the whole model by becoming another link in the chain, even if that link isn't necessarily the weakest (and I certainly believe it would be, because both DNSSEC and the public Certificate Authority industry are object lessons for the abject failure of highly centralized global, government-wide, or even just company-wide security), but simply increasing any of the surface area is enough to decrease the security of the system.
- iambvk 4y agoWhat is the benefit?
- bongobingo1 4y agoI think, 1) You don't have to ssh-copy-id to new boxes, which is nice. 2) You can de-auth a key for all machines by changing the DNS record. This would depend on some propagation time but perhaps you can point the resolver at your nameserver directly which would avoid that.
- chociej 4y agoYou could simply choose a short TTL, or your tool could check for e.g. "some-name._sshkeys.whatever.tld" as well as "_revoked.some-name._sshkeys.whatever.tld" to handle revocation instantly
- bongobingo1 4y agoYou could also just stick it behind a https GET and probably skip a bunch of bother.
- xorcist 4y agoNow you've just moved your authentication to the SSL PKI. In that case, use the SSL certs directly. You'd have add support OpenSSH of course, or just convert the certificates to SSH format, but it would be architecturally much simpler. As to the original question here, the benefit compared to other PKI alternatives (including the SSH PKI in the original question) is that revocation is much easier.
- egberts1 4y agoYes. Hesiod is safer than DNS TXT once secured by DNSSEC, because I envision mass blocking of DNS TXT in the near future.
- dotwaffle 4y agoGood luck with that. DNS TXT records are used for a lot of infrastructure right now, from DMARC/SPF/DKIM to DNS-01 validation through LetsEncrypt afaik.
- egberts1 4y agoYes, and that too will change … again.
- dotwaffle 4y agoHesiod uses txt records. I am using IN class records too, as I do not have a DNS provider that supports HS class... But that's fine, it works!