4 ms·
To expand on this. If you store your public SSH key in DNSSEC, I'm assuming that the use-case is either: 1. Pull the public key from DNS to add to ~/.ssh/autho
by pyre 12y ago
To expand on this. If you store your public SSH key in DNSSEC, I'm assuming that the use-case is either:
1. Pull the public key from DNS to add to ~/.ssh/authorized_keys
2. Implement an sshd runtime that checks the DNS record rather then (or in addition to) ~/.ssh/authorized_keys
Sure, it's "just" the public key so you're not providing the private key to the world-at-large, but if the NSA controls DNSSEC, then they can change the public key to one that is paired with a private key that they control. Now they have access to all systems that the public key could access. This is basically adding DNSSEC as an attack vector to your ~/.ssh/authorized_keys file, which seems like a bad idea.
Please correct me if I'm missing something about how DNSSEC and SSH keys would be used together.
- danyork 12y agoThe idea would be to enable you to verify the public key of a server to which you are connecting for the first time. RFC 4255 outlines this use case: http://tools.ietf.org/html/rfc4255 http://tools.ietf.org/html/rfc4255 When you first connect and get the SSH fingerprint, how many people truly validate through some other mechanism that this is the correct public key to use for some system? (I have on some systems but I know I have just accepted the public key on other systems.) The idea is to use DNSSEC and the SSHFP record to provide a mechanism to validate the SSH public key. Do note this is not a new idea. This RFC was published back in 2006.