
Flexible, secure SSH with DNSSEC - jgrahamc
https://blog.cloudflare.com/flexible-secure-ssh-with-dnssec/
======
aexaey
The whole tower of Hanoi in pubkeygrab.sh script, complete with two greps and
a sed could be replaced with just sed:

    
    
      unbound-host -v -D -t TXT ${USER}_pubkey.example.com \
       | sed 's/.*has TXT record "\(ssh-.*\)" (secure)/\1/p;d'
    

Or, even without sed, reducing to one-liner:

    
    
      dig +short +dnssec +sigchase txt $1_pubkey.example.com
    

EDIT: to address "wtf" concern by ryanlol, we can use a custom trust anchor:

    
    
      dig +short +dnssec +sigchase +trusted-key=/etc/my.key txt $1_pubkey.example.com

------
ryanlol
Wait, what the fuck? Is this for real?

Here's the sample code cloudflare posted:

    
    
      foo:~$ cat /usr/local/bin/pubkeygrab.sh
      #!/bin/sh
      
      USER=$1
      
      /usr/sbin/unbound-host -v -D -t TXT ${USER}_pubkey.example.com \\
           | /usr/bin/grep -v "no TXT record" \\
           | /usr/bin/grep ' (secure)' \\
           | /usr/bin/sed 's/.* "\(.*\)" (secure)/\1/'
    
    

They aren't actually doing any authentication besides DNSSEC , giving the
people managing the TLD and your registrar root access to your server doesn't
seem like such a good idea.

I seriously hope I'm missing something here, but with cloudflares security
track record that seems pretty unlikely.

Edit: Made the mistake of assuming that grep was actually supposed to do
something here, it doesn't actually do anything at all.

~~~
davidpelaez
The registrar only has your public key and Cloudflare handles the private one
for you. If you distribute the public key to your servers as part of the
validation this means that your largest risk is actually a breach in
Cloudflare.

I really really trust them, they have an impressive history of contributions
to the web and commitment to security. If your servers are behind another
access control layer, like a corporate VPN, this shouldn't be a big concern,
since they would have to disclose breaches anyway.

Finally, I think this interesting because basically DNSSEC gives you an easy
way to distribute data globally in a secure way with a TTL. This is the best
benefit compared to using certificates for access control where revocation is
usually very painful.

Consider this an initial look on how to use those benefits of DNS. I agree
another layer of security would be great. Think something like asymmetric
signature of the actual TXT record so that DNSSEC helps control expiration and
then the other key validates origin. You are using DNSSEC only for the
benefits of TTL validation.

~~~
davidpelaez
I'd like to clarify that there's a _major_ issue to consider. Here's my
comment on the article explaining:

Cloudflare delivers signatures for records that last more than the TTL of the
record. This has the problem of replay attacks. If one employee that had
access at some points configures a machines DNS to return an old DNS response
it will be valid until the expiration of the signature, hence having access
for more time than the actual TTL.

I just checked and Cloudflare generates signatures expiring +2 days in the
future. This means that I have a TTL of 5 minutes on my record but the client
is receiving old queries, authentication would pass without a problem for as
long as the RRSIG is valid.

Ideally Cloudflare should sign every record with the same frequency as the
records TTL, that would solve the issue.

After finding this out I think you should _not_ use Cloudflare's DNSSEC
because revoking access to a user wouldn't be 100% effective until the RRSIG
expiration date given the replay attack scenario.

