Flexible, Secure SSH with DNSSEC



  • 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!

    Read More



  • Okay, that is pretty cool. Very interested.



  • That sounds pretty slick. You got it set up yet, @scottalanmiller 😉



  • @dafyre I'll have it setup by the end of the day.



  • Hmmmmm.... Reddit users seem to think this isn't a good idea...

    https://www.reddit.com/r/sysadmin/comments/40rvgq/secure_ssh_with_dnssec/



  • I thought they talked about this on Security Now a while ago.

    All kinds of cool things happen with DNSSEC - security can be improved by orders of magnitude.



  • @anonymous said:

    Hmmmmm.... Reddit users seem to think this isn't a good idea...

    https://www.reddit.com/r/sysadmin/comments/40rvgq/secure_ssh_with_dnssec/

    Why would read Reddit? That place is full of idiots. I read like four posts and they made no sense and showed that they didn't even know what keys were.



  • Here is some points reddit users make:

    • If you're pushing this out to servers, why not push out the keys?
    • Its not hard to manage your authorized_keys file
    • If youDNS providers account gets hacked they can get access to all your servers by adding there own public key.
    • It uses a really new version of ssh so you are not going to be able to implement this unless you are running a distro that supports cutting edge stuff. (not centos/redhat)
    • It's braindead simple to manage authorized_keys in a central location using configuration management.

    What do you guys think? Any of valid points?



  • @anonymous said:

    • If you're pushing this out to servers, why not push out the keys?

    Because one you push out once and manage. The other you push out every time the keys update, change or have additions. This is what I mean by how dumb they are. I read this and was like "they have no clue." They forget that you might have more than one server or more than one user.



  • @anonymous said:

    • Its not hard to manage your authorized_keys file

    This comes from the same people who have never done it. It's a huge pain in the ass. It's not "a" file, it is one file, per user, per server. If you have 100 users and 1,000 servers, that is 100,000 files. How dumb are Reddit people?



  • @anonymous said:

    • If youDNS providers account gets hacked they can get access to all your servers by adding there own public key.

    Yes, the COULD add they own public key. IF your DNS provider gets hacked and no one says anything. At some point, you need to trust your DNS host. The whole point of DNSSEC is that you CAN trust your host, right?



  • @anonymous said:

    • It uses a really new version of ssh so you are not going to be able to implement this unless you are running a distro that supports cutting edge stuff. (not centos/redhat)

    Right, this is an up and coming technology, not an old one. I'm not even sure what the complaint here is.



  • @anonymous said:

    • It's braindead simple to manage authorized_keys in a central location using configuration management.

    That's right, it is. And this is an example of that configuration management. He's complimenting the process but wording it like a complaint.



  • How would this affect a jumpbox?



  • OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013
    

    This is the output from a fresh CentOS7 install. Seems to be at 6.1 alright?



  • Oh, needs to be 6.2



  • @anonymous said:

    How would this affect a jumpbox?

    It would make it easier to manage. All of the public side of the keys would be picked up through DNSSEC instead of pushing them out through custom scripts, Chef, Ansible or making users do it individually.



  • Upgrading OpenSSH to 6.2 seems like a pain. Anyone have a easy way to do it?



  • @anonymous said:

    Upgrading OpenSSH to 6.2 seems like a pain. Anyone have a easy way to do it?

    Wait until RHEL adds it?



  • Run Fedora?



  • @JaredBusch said:

    @anonymous said:

    Upgrading OpenSSH to 6.2 seems like a pain. Anyone have a easy way to do it?

    Wait until RHEL adds it?

    That should be CentOS 8 😞



  • @scottalanmiller said:

    @JaredBusch said:

    @anonymous said:

    Upgrading OpenSSH to 6.2 seems like a pain. Anyone have a easy way to do it?

    Wait until RHEL adds it?

    That should be CentOS 8 😞

    This is currently an emerging technology. So really, anyone trying to implement should NOT be expecting an easy way to do something.



  • Not yet, in a year or two, I'd expect it to get there.