Remix.run Logo
bakugo 16 hours ago

AI slop article based on a flawed premise. It's 2026, the process of correctly securing an SSH server has exactly two steps:

1. Disable password auth, only public key auth should be enabled

2. Block public access to SSH entirely, use a VPN instead (Tailscale & co. make this trivial)

And 2 is entirely optional for most people reading SSH guides who just want a server to host their hobby project. Let's be real, you're probably not reading the auth logs anyway so they don't need to be clean, and if someone discovered an OpenSSH public key auth bypass vulnerability, they absolutely wouldn't waste it on you. Just let those dumb scanners go at it all day, they're not getting in.

And a little tangent: fail2ban is 100% placebo and does nothing except clean up the logs a bit. I don't understand why it's still a common recommendation for beginners, it's a relic from the past when bruteforcing was still a concern because people used password auth.

yjftsjthsd-h 14 hours ago | parent | next [-]

> And a little tangent: fail2ban is 100% placebo and does nothing except clean up the logs a bit. I don't understand why it's still a common recommendation for beginners, it's a relic from the past when bruteforcing was still a concern because people used password auth.

I assume it's suggested precisely because people use passwords. Which, granted, they shouldn't.

bigstrat2003 2 hours ago | parent | prev [-]

Yep, the only thing you need to do is to disable password auth. They aren't going to be able to crack your SSH key no matter how many times they try.