ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Flexible, Secure SSH with DNSSEC

    IT Discussion
    6
    23
    2.7k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      Alex Sage
      last edited by Alex Sage

      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

      1 Reply Last reply Reply Quote 4
      • S
        scottalanmiller
        last edited by

        Okay, that is pretty cool. Very interested.

        1 Reply Last reply Reply Quote 1
        • D
          dafyre
          last edited by

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

          A 1 Reply Last reply Reply Quote 0
          • A
            Alex Sage @dafyre
            last edited by

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

            1 Reply Last reply Reply Quote 0
            • A
              Alex Sage
              last edited by

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

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

              S 1 Reply Last reply Reply Quote 0
              • D
                Dashrender
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • S
                  scottalanmiller @Alex Sage
                  last edited by

                  @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.

                  1 Reply Last reply Reply Quote 1
                  • A
                    Alex Sage
                    last edited by Alex Sage

                    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?

                    S 5 Replies Last reply Reply Quote 0
                    • S
                      scottalanmiller @Alex Sage
                      last edited by

                      @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.

                      1 Reply Last reply Reply Quote 0
                      • S
                        scottalanmiller @Alex Sage
                        last edited by

                        @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?

                        1 Reply Last reply Reply Quote 1
                        • S
                          scottalanmiller @Alex Sage
                          last edited by

                          @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?

                          1 Reply Last reply Reply Quote 2
                          • S
                            scottalanmiller @Alex Sage
                            last edited by

                            @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.

                            1 Reply Last reply Reply Quote 0
                            • S
                              scottalanmiller @Alex Sage
                              last edited by

                              @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.

                              1 Reply Last reply Reply Quote 0
                              • A
                                Alex Sage
                                last edited by

                                How would this affect a jumpbox?

                                S 1 Reply Last reply Reply Quote 0
                                • A
                                  Alex Sage
                                  last edited by

                                  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?

                                  1 Reply Last reply Reply Quote 0
                                  • A
                                    Alex Sage
                                    last edited by

                                    Oh, needs to be 6.2

                                    1 Reply Last reply Reply Quote 0
                                    • S
                                      scottalanmiller @Alex Sage
                                      last edited by

                                      @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.

                                      1 Reply Last reply Reply Quote 0
                                      • A
                                        Alex Sage
                                        last edited by

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

                                        JaredBuschJ 1 Reply Last reply Reply Quote 0
                                        • JaredBuschJ
                                          JaredBusch @Alex Sage
                                          last edited by

                                          @anonymous said:

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

                                          Wait until RHEL adds it?

                                          S 1 Reply Last reply Reply Quote 1
                                          • coliverC
                                            coliver
                                            last edited by

                                            Run Fedora?

                                            1 Reply Last reply Reply Quote 1
                                            • 1
                                            • 2
                                            • 1 / 2
                                            • First post
                                              Last post