3 ms·

I have SSH with key auth everywhere, so I have no security worries. But when sshd ends up pegging an entire core, and I can't login myself anymore, then fail2b

I have SSH with key auth everywhere, so I have no security worries. But when sshd ends up pegging an entire core, and I can't login myself anymore, then fail2ban (or even whitelisting IP ranges for ssh) becomes necessary.

hh3k0 9y ago
It would most probably never end up pegging an entire core if you use key auth and have conventional logins deactivated, no? I mean, why would people even try.
- sophacles 9y ago
  Keys, like passwords, can be leaked, so it's possible there are databases of leaked keys out in the world, because unlike PGP or SSL certs, ssh keys don't have a revocation mechanism built in. So they could just try all the known leaked keys - like they try known leaked or default passwords. Then there was this: https://jblevins.org/log/ssh-vulnkey https://jblevins.org/log/ssh-vulnkey (tl;dr - there was a bug in debian that caused ssh-keygen to only produce a very small number of keys rather than keys distributed across the whole keyspace). After that became public the bots were all about trying those keys for a few years after. To this day it's recommended to not used keys from that set. Point being - the bots will try because it the tiny marginal cost is not high enough to stop the attempt.
- kuschku 9y ago
  They simply try password auth, and fail with a message that password auth is off. Constantly. All the time.
  - purple-again 9y ago
    Set up a non standard port. This will stop over night.
    - kuschku 9y ago
      It has stopped now (I simply removed port 22 from the whitelist except for connections originating with my home ISP, which is a local ISP where abuse reports actually work)
      - dcbadacd 9y ago
        Have you tried port knocking as a way of temporarily whitelisting the right IPs?
vbezhenar 9y ago
That would be problematic, but I never encountered that. I'm using cheapest VPS with public IP and without any additional protections. I just checked and its load average is 0.00, so load is non-existant.
- deleted 9y ago
  [deleted]

hh3k0 9y ago

It would most probably never end up pegging an entire core if you use key auth and have conventional logins deactivated, no? I mean, why would people even try.

sophacles 9y ago
Keys, like passwords, can be leaked, so it's possible there are databases of leaked keys out in the world, because unlike PGP or SSL certs, ssh keys don't have a revocation mechanism built in. So they could just try all the known leaked keys - like they try known leaked or default passwords. Then there was this: https://jblevins.org/log/ssh-vulnkey https://jblevins.org/log/ssh-vulnkey (tl;dr - there was a bug in debian that caused ssh-keygen to only produce a very small number of keys rather than keys distributed across the whole keyspace). After that became public the bots were all about trying those keys for a few years after. To this day it's recommended to not used keys from that set. Point being - the bots will try because it the tiny marginal cost is not high enough to stop the attempt.
kuschku 9y ago
They simply try password auth, and fail with a message that password auth is off. Constantly. All the time.
- purple-again 9y ago
  Set up a non standard port. This will stop over night.
  - kuschku 9y ago
    It has stopped now (I simply removed port 22 from the whitelist except for connections originating with my home ISP, which is a local ISP where abuse reports actually work)
    - dcbadacd 9y ago
      Have you tried port knocking as a way of temporarily whitelisting the right IPs?

vbezhenar 9y ago

That would be problematic, but I never encountered that. I'm using cheapest VPS with public IP and without any additional protections. I just checked and its load average is 0.00, so load is non-existant.

deleted 9y ago
[deleted]