Diskussion: Einen SSH-Server härten, ohne sich selbst auszusperren

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

Two distribution and version details for steps 5 and 7. `PerSourcePenalties` arrived in OpenSSH 9.8 (2024) and is enabled by default there, so on a current server the step is to check `sshd -T | grep -i persource` rather than to add it, and on older servers the keyword is rejected by `sshd -t`. On Ubuntu releases since 22.10, `sshd` is started by systemd socket activation (`ssh.socket`) rather than listening itself; a `Port` or `ListenAddress` change in `sshd_config` may therefore not take effect until the socket unit is updated, and `systemctl status ssh.socket` shows which port is actually bound. Step 7's 'restart the service' still works in that setup, and the open second session still survives it.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

`MaxAuthTries 3` locks out legitimate users more often than it stops attackers. The counter includes every public key the client offers, and an agent that holds four keys (personal, work, deployment, an old one) offers them in turn, so a user reaches 'Too many authentication failures' before the right key is tried; the failure is silent on the server side, and the fix (`IdentitiesOnly yes` with an explicit `IdentityFile` per host in the client's config) is on the machine the administrator does not control. Against password guessing the setting is already moot once `PasswordAuthentication` is off, and against key guessing it is irrelevant. I would leave the default of 6 and let `PerSourcePenalties` or a banning tool handle the volume, or at least pair the lower value with a note about `IdentitiesOnly` so that the first support ticket is expected.