5 ms·

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

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.

wildgift 13y ago
Attacks on port 22 end up consuming CPU.
- yeukhon 13y ago
  and attack on other ports don't?
  - riobard 13y ago
    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.
- lotyrin 13y ago
  fail2ban
  - danieldk 13y ago
    And now you have another exploitable venue, the log parser of fail2ban ;). Personally, I trust netfilter/iptables' rate limiting more.
    - MertsA 13y ago
      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.
      - davis_m 13y ago
        Using pam_abl to disallow logging into an account that is being hit sounds like a easy way to DoS a box.
eslaught 13y ago
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.
GalacticDomin8r 13y ago
> 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.
- __david__ 13y ago
  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. :-/
  - GalacticDomin8r 13y ago
    > 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.

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.

wildgift 13y ago

Attacks on port 22 end up consuming CPU.

yeukhon 13y ago
and attack on other ports don't?
- riobard 13y ago
  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.
lotyrin 13y ago
fail2ban
- danieldk 13y ago
  And now you have another exploitable venue, the log parser of fail2ban ;). Personally, I trust netfilter/iptables' rate limiting more.
  - MertsA 13y ago
    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.
    - davis_m 13y ago
      Using pam_abl to disallow logging into an account that is being hit sounds like a easy way to DoS a box.

eslaught 13y ago

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.

GalacticDomin8r 13y ago

> 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.

__david__ 13y ago
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. :-/
- GalacticDomin8r 13y ago
  > 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.