The JHU ACM has many machines that users might want to SSH into. The JHU ACM also occasionally reinstalls those machines for various reasons, which changes their SSH keys. And I’m usually not near the office anymore to verify for myself that the keys I’m seeing are correct.<\/p>\n
The ACM happens to do DNSSEC on their domain, though, and I run a validating resolver, so I can use SSHFP records as a trusted source of SSH fingerprints.<\/p>\n
On my end I added this line to And (It even knows the difference between a DNSSEC-authenticated response and the other kind, and it will still ask you whether the key is OK if the matching SSHFP record is unauthenticated and the key isn’t in (Remove the ~\/.ssh\/config<\/code>:<\/p>\nVerifyHostKeyDNS yes<\/pre>\n
ssh<\/code> checks the key it sees against SSHFP records (falling back to known_hosts<\/code> if there aren’t any), giving\u00a0the usual loud warning about any discrepancies it may come across.<\/p>\nknown_hosts<\/code>. You can make it ask even on authenticated SSHFP records by setting VerifyHostKeyDNS<\/code> to ask<\/code> instead.)<\/p>\nThat’s all well and good… what about the other end?<\/h1>\n
ssh-keygen<\/code> can generate SSHFP records for a given key file when run with the -r<\/code> option. We wrapped it in a script, which you can run on the machine in question to get a zonefile snippet (and which only looks at public key files, and so doesn’t need to be run as root):<\/p>\n#!\/bin\/sh\r\n# Generate a zone file snippet for SSHFP records for the host this is run on.\r\n\r\nset -e\r\n\r\n# This is in increasing order of algorithm ID in the SSHFP records.\r\nfor algo in rsa dsa ecdsa ed25519; do\r\n keyfile=\"\/etc\/ssh\/ssh_host_${algo}_key.pub\"\r\n if test -f \"$keyfile\"; then\r\n if ! ssh-keygen -r \"`hostname`\" -f \"$keyfile\" | awk '\r\n {\r\n # Do not bother with SHA1 fingerprints - only process SHA256 ones.\r\n # Reformat the lines so the whitespace matches common zone file layout.\r\n if ($5 == \"2\")\r\n print $1 (length($1) < 8 ? \"\\t\" : \"\") \"\\t\" $2 \"\\t\" $3 \"\\t\" $4, $5, $6\r\n }' | grep SSHFP # the grep is just to check whether there was any output\r\n then\r\n if test x\"$algo\" = xed25519; then\r\n echo \"; placeholder for SSHFP record for `hostname` ed25519 key\"\r\n # Complain on stderr about ed25519 SSHFP records not yet being supported\r\n # so the output of this script can be sensibly directed into a zone file.\r\n cat >&2 <<\"EOF\"\r\n\r\nThere is an ed25519 key, but ssh-keygen did not turn it into an SSHFP\r\nrecord. It is probably not a new enough version to support doing so -\r\nif this is the case, remember to regenerate the records once it is.\r\nEOF\r\n else\r\n echo \"unable to generate SSHFP record for $keyfile\" >&2\r\n # ssh-keygen puts some error messages on stdout (shame!), so re-run\r\n # the failing invocation to get that output and throw away stderr.\r\n ssh-keygen -r \"`hostname`\" -f \"$keyfile\" 2>\/dev\/null\r\n exit 1\r\n fi\r\n fi\r\n fi\r\ndone<\/pre>\nif ($5 == \"2\")<\/code> if you also want SHA1 SSHFPs, which older versions of ssh<\/code> might need. The ugly conditionals involving ed25519 are because at the time the script was written, Debian stable’s OpenSSH didn’t support SSHFP for ed25519, Debian testing’s did, we had machines running both, and the OpenSSH tools could stand to do much<\/em> better when it comes to error exit codes and to what goes to stdout and what goes to stderr. The script is also available as\u00a0\/afs\/acm.jhu.edu\/group\/admins.pub.ro\/scripts\/gen-sshfp-records<\/code>.)<\/p>\n