14 ms·
Tangentially related: One can store SSH server host keys in DNS and tell the client to make use of them. (OpenSSH supports `VerifyHostKeyDNS=yes`.) This is an a
by manuel_w 4y ago
Tangentially related: One can store SSH server host keys in DNS and tell the client to make use of them. (OpenSSH supports `VerifyHostKeyDNS=yes`.) This is an alternative to the client asking the user to confirm the server host key, which many people just blindly confirm.
I asked GitLab if they could make use of that, but it hasn't received much attention so far:
* https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/10376 https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/10376
- Nextgrid 4y agoYou'd need DNSSEC for this right? If not can't an MITM still intercept the DNS lookup and substitute their own key? In fact, even if the original domain does support DNSSEC, can a userspace program such as the SSH client actually tell whether the record it just resolved was resolved using a DNSSEC-aware resolver?
- aaronmdjones 4y agoYes, you would need a DNSSEC-validating resolver, and no, ssh(1) can't confirm if the answer was actually validated or not. There's an "ad" (Authenticated Data) flag in the DNS reply header that a resolver can set to 1 to indicate that it validated the answer, but an MITM can also just set that to 1. The client would have to do its own validation, and ssh(1) doesn't. Therefore, you can only safely use this if you use a DNSSEC-validating resolver, and you trust the resolver (e.g. you administer it yourself), and you have a trusted path between you and it (e.g. it's on your LAN).
- devman0 4y agoTrusted path could also be DoH or DoT as well, but yeah, not just 53/udp in the clear over the internet.
- 3np 4y agoAn example to work around this would be to run a validating resolver (for example unbound) on localhost of each host and have it forward to whatever DNS server you use today. If you're on Ubuntu, you most likely have a local resolver running already.
- dgl 4y agoOn Ubuntu the default is to use systemd-resolved, which is actually a validating stub resolver. You just need to set DNSSEC=true (see man resolved.conf) and it will work*. *: this is the definition of "work" that also means it won't resolve anything if anything is wrong with DNSSEC validation, but if you want to be secure you need it to fail closed.
- d110af5ccf 4y agoPerhaps a solution such as dnscrypt-proxy and configuring it to forward requests that match certain patterns to a validating resolver on the local network would work? Requests that didn't match could be forwarded to some other resolver that wasn't configured to validate.
- skissane 4y agoThere should be an option for "validate but still return invalid data, just reflect validity in the AD bit". Is there? That way most things will still work even DNSSEC is broken, and apps with higher security requirements can opt-in to "fail if invalid", by passing setting the AD bit on queries, and checking if it is still there on responses.
- yrro 4y agoI believe that is DNSSEC=allow-downgrade which is also the default.
- skissane 4y ago> and no, ssh(1) can't confirm if the answer was actually validated or not. Isn’t this a gap in the API? res_query/etc should provide some way to find out if the response is validated or not. That would require either (1) a validating resolver running locally, or (2) a remote validating revolver, accessed over a secure protocol (such as DoT or DoH), which the system administrator has elected to trust. But the system should be able to tell applications, via some API, whether (1) or (2) hold or not
- dgl 4y agoThis is [was; the quote in the parent was edited] incorrect, the response includes `header.ad`, which on Linux is controlled by both what the resolver responds with and `option trust-ad` in /etc/resolv.conf, so the administrator can choose if they trust their resolver via "trust-ad".
- skissane 4y agoThanks for clarifying, that makes more sense. I was just going by what the person I was replying to was saying. The man pages on my Linux box are too old to mention the trust-ad option, although newer Linux man pages do. glibc defines a RES_TRUSTAD bit which is equivalent, so applications can choose to request and trust the AD bit even if resolv.conf isn't configured to do so. However, that doesn't appear to be documented anywhere other than the header file and the NEWS file in the glibc distribution. Both RES_TRUSTAD and trust-ad were added in glibc 2.31 (released Feb 2020).
- aaronmdjones 4y agoYes, I mentioned the AD header. However, I stand by my statement that ssh(1) cannot confirm whether the answer was actually validated because an MITM could have set that flag. EDIT: I meant for this to be a reply to my sibling comment.
- skissane 4y agoIf ssh is using the GNU C Library’s resolv functions, and it isn’t setting RES_TRUSTAD, then glibc will automatically clear the AD bit unless the sysadmin has configured the trustad option in resolv.conf. A competent sysadmin would only do that in cases where MITM is impossible - either a local validating resolver, or DoT/DoH to a remote validating resolver. It is true that ssh has to trust the sysadmin to be competent and not enable that option in cases where MITM is possible, but I think that’s a general assumption for security that the sysadmin is doing the right thing, otherwise there are numerous other possible insecure configurations which might break ssh’s security. To double foolproof it, ssh_config could come with its own trustad setting independent of resolv.conf, so you’d have to set both.
- capableweb 4y agoIn that vein, is there something that could allow me to manage authorized_keys via DNS? Let's say I own capableweb.com, I'd love it if sshd could just read all records from keys.capableweb.com and use those as valid public keys. I have bunch of personal servers, and bunch of keys in use, many of the servers are not automated (they're pets, not cattle), so when I rotate keys, it's sometimes a hassle. Mostly asking just because it'd be fun.
- knewter 4y agoA tiny bash script and a cronjob
- dgl 4y agoAs mentioned elsewhere in this thread, actually using SSHFP in a secure way is difficult. Far better is to use SSH host certificates, then your known_hosts can simply have a @cert-authority * some-cert in it. (See https://www.lorier.net/docs/ssh-ca.html https://www.lorier.net/docs/ssh-ca.html)
- toast0 4y agoYou might consider checking in an authorized_keys file? Not as fun as dns, but maybe easier. You can use ssh-keyscan to build the file.
- benmanns 4y agoIf you trust GitHub you could curl https://github.com/capableweb.keys https://github.com/capableweb.keys on startup
- Queue29 4y agoSimilar idea: This runs as a cron/systemd timer and updates your authorized_keys from your GitHub account. https://github.com/shoenig/ssh-key-sync https://github.com/shoenig/ssh-key-sync
- samber 4y agohttps://github.com/samber/sync-ssh-keys/ https://github.com/samber/sync-ssh-keys/
- matheusmoreira 4y agoIt's also possible to distribute PGP keys this way. Probably a much better solution than the keyserver mess. https://www.pgp.guide/pgp_dns/ https://www.pgp.guide/pgp_dns/
- throwawaaarrgh 4y agoPlease don't put security stuff in DNS. DNS isn't secure and DNSSEC is a travesty. Just take the records it gives "under advisement" and confirm it over TLS or another secure transport protocol.
- 3np 4y agoCan you be more specific in your criticism of DNSSEC?
- karlshea 4y agoThis is the tptacek bat signal
- whyever 4y agohttps://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/
- teddyh 4y agoAnd yet here we are, eight years later, DNSSEC adoption still growing.
- mike_d 4y agoThe rate of DNSSEC signed zones is growing, but the number of recursive resolvers that hard fail on validation failures is static or going down. Unfortunately the user experience for a DNSSEC signature failure is so bad, the only option if you run a large ISP or corporate network is to just use the answer you get anyway.
- teddyh 4y agoSince (regrettably, for other reasons), many people seem to be moving to use centralized resolvers which all, incidentally, do validate DNSSEC strictly, I doubt whether “number of recursive resolvers” is a valid proxy for “number of users using DNSSEC validation in practice” anymore. In fact, I see a lot of people advocating for using centralized resolvers, and not even once have I seen a counter-argument in the form of DNSSEC validation being a problem.
- gorgoiler 4y agoThis is fun but a more practical solution would be for “ssh host” to GET the host’s public key from https://host/.well-known/ https://host/.well-known/. The OpenSSH daemon could host it for you if you could fit a tiny, vuln free httpd inside it — not an enormously onerous task given that the codebase already includes the implementation of a robust TCP daemon. Add ACME support and you’ve moved the TOFU MITM attack from being possible on every-new-client-connection to also having to coincide with the once-every-X-days for the HTTPS certificate renewal. It’s a lot of new functionality which probably isn’t cool for the OpenSSH codebase, but it’s a pragmatic solution to plugging the gap between mankind’s universally deployed PKI and ssh’s ephemeral peer-to-peer verification.
- CGamesPlay 4y agoDoesn't SSH already support using TLS keys for authentication? So, we can skip the whole HTTPS part of the equation.
- AndyMcConachie 4y agoMaking SSH authentication dependent on HTTPS seems like a really bad idea.
- kedihacker 4y ago