Monkeysphere: Verify server SSH keys through the OpenPGP web of trust | Hacker News Reader

Monkeysphere: Verify server SSH keys through the OpenPGP web of trust

web.monkeysphere.info

47 pointsplanckscnst10 comments

You can also publish fingerprints of your host key in DNS[1]. And then

    ssh -o "VerifyHostKeyDNS ask" host.example.com

Alternatively, put

    VerifyHostKeyDNS ask

in your ssh config. Obviously, this would work better with much maligned here DNSSEC.

[1] http://tools.ietf.org/html/rfc4255

Practical question - let's say you spin new EC2 on AWS. This results in VM generating new host sshd key for this instance as part of bootstrapping new instance process.

How do you place host sshd key in DNS records without first connecting to this instance and getting the key, action which requires you to check/verify host sshd key (which is NOT in DNS yet)?

so it looks a bit like chicken and egg thing ...

What am I missing?

The way I can think of is using IAM credentials to allow modification of a Route53 record using the AWS CLI from the newly spun server. You will need to write a short script that you could push to the new instance either through EC2 MetaData or UserData fields.

If there is a demand I could try whipping up a CloudFormation template to do it.

Either create the ssh host key outside and set it inside the image or integrate the new host into your configuration management and report the sshd host key back and export it to the zone database. Of course your AMI could also just automatically populate the DNS entry via some shared secret or API ...

I don't know about EC2 but Linode provide you with a web based console you can use to set stuff up.

I'm a bit confused about this. I merely glanced at the RFC, so maybe I missed that:

I guess most people connect to a server by name (using DNS lookups, vs. direct IP addresses).

If my query for example.com is redirected somehow, wouldn't it be fairly trivial (ignoring DNSSEC right now) to present a valid fingerprint via DNS as well?

The RFC acknowledges this problem, which is why it kindly suggests you use DNSSEC ;-)

As another commenter mentioned, it all depends on who your attacker is. A MITM ssh attack won't necessarily forge your DNS request (maybe your router is compromised?), so even without DNSSEC there might be some use in enabling this.

While I think you're right, in the sense that an attacker who can forge your DNS request for ssh.example.com to direct your SSH from 192.168.1.111 to 192.168.1.200 might have the ability to manipulate the TXT entry of your public key signature in the DNS records, it's a matter of who you think your attacker could be.

Security is all relative, but I'm quite sure it would be possible for your to just sign your public key signature (which is what the article covers), and presumably you've kept your private key a real secret, so that isn't forge-able (unless your enemy has cracked your 2046/4096-bit RSA key).

Thanks for the tip, was unaware of that option.

Monkeysphere is very cool. The biggest issue for me has been that it can be slow to verify keys. Also getting coworkers to use it is a pain since they usually have their own habits.

Reply on news.ycombinator.com