Hacker News Reader

Comment by __david__ | Hacker News Reader

Turning off passwords and only using keys also mitigates the standard brute force attacks that happen. Frankly I'd much rather do that then have my server on a non-standard port.

View on HN

Bots frequently exploit changes that were recently fixed upstream. Not perhaps 0-days, but maybe a couple days after the original fix. How up-to-date do you really keep your SSH server? On the off chance the attacker gets to an exploit faster than you get around to updating your machine, then keys won't keep you safe. Using a non-standard port in that scenario might very well save you from the botnets, if the GP's argument about the dimensionality of attacks is correct.

Attacks on port 22 end up consuming CPU.

and attack on other ports don't?

The assumption is that bots don't usually scan other ports: way too inefficient for them to scan all ports for every potential target host.

fail2ban

And now you have another exploitable venue, the log parser of fail2ban ;).

Personally, I trust netfilter/iptables' rate limiting more.

Even better yet is pam_abl. If any IP or user fails authentication faster than a configured rate pam_abl will block logging into that user or any authentication attempts coming from the same IP address and it's all nicely tied into PAM so you don't have to worry about yet another fail2ban vulnerability or someone spoofing some important IP address and tricking your server into blocking it.

Using pam_abl to disallow logging into an account that is being hit sounds like a easy way to DoS a box.

> Frankly I'd much rather do that then have my server on a non-standard port.

Frankly, the problems with key security and management are much worse than are being discussed. Using only keys is fine as long as your keys are secure and you know which is which and control all access and immediately remove any key which needs to be. In a complex environment, this is extremely difficult and more prone to security breaches than password access.

I don't know. In complex environments that try to use passwords, I've observed that the password spreads until everyone knows it and then nobody can change it because "everyone already knows it and it would be a pain". Keys allow fine grained access and can theoretically be way more secure.

On the other hand, the last place I consulted for had their private key for production checked in to the main git repo, unencrypted. :-/

> Keys allow fine grained access and can theoretically be way more secure.

This is true but as often is theory and "life" don't agree about the practice. This is exactly my point. If you could enforce a non-blank password on keys then I would change my tune at least a bit.

Reply on news.ycombinator.com