News for hackers. Stuff that matters.
Re:Signing .jars is not worth the effort by MertsA on Monday July 27, 2020 @07:15AM (#23963968)
What's absolutely incredibly frustrating is that it's absurdly common to ignore SSH fingerprints even if they're staring you in the face. I just spun up a Fedora 32 cloud image on RamNode over the weekend and the default image oh-so-helpfully displays the SSH fingerprints as part of the MOTD so you can verify it just looking at the login prompt on console. Except apparently the script that generates that runs before the SSH keys are regenerated on the first boot of the image, so the fingerprints displayed don't match the keys on disk. Either no one else has noticed this bug yet or nobody has been bothered enough to fix it.

There is a solution though, SSHFP records for the host. I just set them up after catching that issue just because of how frustrating blindly trusting on first use is. Now I can SSH to my servers even without anything for them being in known_hosts and it checks for SSHFP records and verifies the fingerprint and DNSSEC protects the SSHFP records.

Re:Signing .jars is not worth the effort by tptacek on Monday July 27, 2020 @08:25PM (#23970941)
SSHFP requires you to DNSSEC-sign your zones, which virtually nobody in the technology industry does, for a variety of reasons, some involving security.

A more straightforward solution that doesn't require you to hitch your wagon to a moribund infrastructure overhaul is to use SSH certificates. SSH certificate infrastructures have other benefits beyond resolving the introduction problem; for instance, they're easier to manage than keys once set up, and, perhaps most importantly, they make it possible to issue short-lifespan keys based on single signon, which is much safer than having everyone register a canonical personal key.