« If you read this blog on a regular basis, you probably use the little tool called SSH, especially its ubiquitous and most popular implementation OpenSSH.

Maybe you’re savvy enough to only use it with public/private keys, and therefore protect yourself from dictionary attacks. If you do then you know that in order to configure access to a new host, you need to make a copy of a public key available to that host (usually by writing it to its disk). Managing keys can be painful if you have many hosts, especially when you need to renew one of the keys. What if DNSSEC could help?

With version 6.2 of OpenSSH came a feature that allows the remote host to retrieve a public key in a customised way, instead of the typical authorized_keys file in the ~/.ssh/ directory. For example, you can gather the keys of a group of users that require access to a number of machines on a single server (for example, an LDAP server), and have all the hosts query that server when they need the public key of the user attempting to log in. This saves a lot of editing of authorized_keys files on each and every host. The downside is that it's necessary to trust the source these hosts retrieve public keys from. An LDAP server on a private network is probably trustworthy (when looked after properly) but for hosts running in the cloud, that’s not really practical.

DNSSEC is helpful here. That's right: now that we can verify responses from a DNS server, we can safely store public keys in DNS records!

So let's say we administer example.com and want to give Alice and Bob access to machines foo, bar and baz in that domain. We'll store their respective public keys in TXT1 records named alice_pubkey.example.com and bob_pubkey.example.com.

The requirements are:

    the machines need to run OpenSSH server version 6.2 or later
    they also need a DNSSEC validating resolver (we'll use unbound-host)
    Alice and Bob's keys need to be less than 256 characters long (ECDSA or Ed25519 keys will work)
    DNSSEC needs to be correctly set up on the domain example.com (surprise!)

[...]

AuthorizedKeysCommand /usr/local/bin/pubkeygrab.sh
AuthorizedKeysCommandUser pubkeygrab

[...]

If you remove the TXT records, Alice and Bob’s access should be revoked, and they should be unable to login, once the TTL of the TXT record is expired. However, note that when the output of pubkeygrab.sh is empty, sshd reverts to the usual AuthorizedKeysFile option to find a public key. So if Alice and Bob are cheeky and want to keep their access after you removed their TXT records, they just need to copy their public key into that file any time before you ban them. If you don't want that, make sure they can't write in that file either »