5 ms·

When I still ran my own server it was a pretty heavy load, like 30% or so. Much more than a minor nuisance. But it was a SPARC server with 1 core at a few hund

When I still ran my own server it was a pretty heavy load, like 30% or so. Much more than a minor nuisance. But it was a SPARC server with 1 core at a few hundred MHz and no crypto acceleration. As you can tell this is a while ago :) So yeah I guess these days it's much less of an issue. But the number of possible attempts will have increased too of course.

akerl_ 4y ago
I figured I might as well go pull up some numbers from my personal systems. I've got 3 internet-facing VMs that expose SSH to the world. For the past 30 days, I've seen a combined total of 86k SSH attempts. I've not bothered to filter out my own legitimate sessions, given that they're in the ballpark of ~3 connections a day tops. Total load on each of these systems has stayed below 0.5, and that's including the other actual work the servers do. I don't have a great way to pull out sshd specifically, but it's safe to say that these servers haven't had their operations affected at all by the nefarious attempts. For what it's worth, the one thing I'm doing that could potentially impact the resource consumption is hardcoding cipher/keyexchange/MAC selections. Given that I control 100% of the legitimate clients for these SSH daemons, I've hardcoded the settings as follows: Ciphers chacha20-poly1305@openssh.com KexAlgorithms curve25519-sha256@libssh.org MACs hmac-sha2-512-etm@openssh.com HostKey /etc/ssh/ssh_host_ed25519_key Over 95% of the spam connection attempts get dropped before my server ever does any crypto, because the connecting system doesn't support that KeyExchange choice.
- 5e92cb50239222b 4y ago
  > I don't have a great way to pull out sshd specifically If it's using systemd, try systemctl status sshd If CPU accounting is turned on, you'll see how much CPU time was used by sshd, plus when it was last restarted, which at least gives you something to work with. If not, you can enable it with: systemctl edit sshd then adding: [Service] CPUAccounting=yes and restarting the daemon.
  - GekkePrutser 4y ago
    This is really useful, thanks!
  - akerl_ 4y ago
    TIL! Thanks for sharing
  - loeg 4y ago
    TIL about systemctl edit, thanks. Note to others: if you want to override an existing setting, rather than just add new settings, you'll need to use 'systemctl edit --full'.

akerl_ 4y ago

I figured I might as well go pull up some numbers from my personal systems. I've got 3 internet-facing VMs that expose SSH to the world. For the past 30 days, I've seen a combined total of 86k SSH attempts. I've not bothered to filter out my own legitimate sessions, given that they're in the ballpark of ~3 connections a day tops. Total load on each of these systems has stayed below 0.5, and that's including the other actual work the servers do. I don't have a great way to pull out sshd specifically, but it's safe to say that these servers haven't had their operations affected at all by the nefarious attempts. For what it's worth, the one thing I'm doing that could potentially impact the resource consumption is hardcoding cipher/keyexchange/MAC selections. Given that I control 100% of the legitimate clients for these SSH daemons, I've hardcoded the settings as follows: Ciphers chacha20-poly1305@openssh.com KexAlgorithms curve25519-sha256@libssh.org MACs hmac-sha2-512-etm@openssh.com HostKey /etc/ssh/ssh_host_ed25519_key Over 95% of the spam connection attempts get dropped before my server ever does any crypto, because the connecting system doesn't support that KeyExchange choice.

5e92cb50239222b 4y ago
> I don't have a great way to pull out sshd specifically If it's using systemd, try systemctl status sshd If CPU accounting is turned on, you'll see how much CPU time was used by sshd, plus when it was last restarted, which at least gives you something to work with. If not, you can enable it with: systemctl edit sshd then adding: [Service] CPUAccounting=yes and restarting the daemon.
- GekkePrutser 4y ago
  This is really useful, thanks!
- akerl_ 4y ago
  TIL! Thanks for sharing
- loeg 4y ago
  TIL about systemctl edit, thanks. Note to others: if you want to override an existing setting, rather than just add new settings, you'll need to use 'systemctl edit --full'.