This is not a good idea (and far from "awesome"). I get why he's doing it, but suggesting that weakening the security of a tool that is meant to enhance it is bad advice.
Eh... bad advice in general, but awesome advice for the case he's using it in. Like he says in the post: Don't set these values for hosts that you actually care about.
It doesn't seem like a good idea at all. SSH caches those keys because computers are more capable of flawlessly comparing long strings of random characters than humans are. The cache is so that you, presumably a human, don't need to compare the reported host key to its known value each time you connect.
I understand his specific application, and why it works for him, but including it as advice for the general SSH-consuming public is nuts.
I think "hosts that you care about" captures them all. Yes, there is too much that can go wrong, but for this tiny case the advice is useful. Let me quote GJ Sussman: "It is OK if it is not user-friendly, I am not a user".
Our fail2ban processes were using a not-insignificant amount of resources while sshd was listening on port 22. Moving to a high port shifted it to somewhere in the "dead last" range in the CPU time column.
You should never do it in general; however, it makes great sense for the specific case mentioned in the article: a test system on an internal network which frequently gets reinstalled and thus re-keyed.
Can't answer for peterjmag, but DNS spoofing is more prevalent than ever (certainly compared to when host key checking was built into the SSH spec) - I'm thinking about WiFi Hotspot login pages that pretend to live at any domain you type in, things like that.
It's host key checking that stops you typing in your root password into a different server that isn't who it says it is.
I was under the impression that connecting as root via ssh was a bad idea in general, ie. that it was better to connect as an unprivileged user and then su. What are your thoughts on that?
I always disable remote root login and password authentication. Then I create purpose-specific remote users with sudo access only to the commands they need (and never access to sudo su). This is not only more security-conscious in my mind, but also allows me to just drop a friend or coworker's public key in the authorized_keys file for a certain user to allow that person to perform the function that user was purposed for (for instance, when I'm on vacation).
This is not a good idea (and far from "awesome"). I get why he's doing it, but suggesting that weakening the security of a tool that is meant to enhance it is bad advice.