SSH ist auf jedem öffentlichen Server der meistangegriffene Dienst — und zugleich der, den man am leichtesten richtig schließt. Fast das gesamte Risiko kommt von einer Sache: Passwörtern. Nehmen Sie sie weg, dann laufen die Versuche weiter und sind bedeutungslos.
Die Konfiguration
# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers sara deploy
sudo sshd -t && sudo systemctl reload ssh
Vor dem Neuladen: Halten Sie einen funktionierenden Schlüssel bereit und ein zweites, bereits angemeldetes Terminal. Setzen Sie PasswordAuthentication no ohne installierten Schlüssel, haben Sie sich aus dem eigenen Server ausgesperrt — dann bleibt nur noch die Konsole des Anbieters.
Zeile für Zeile
- PermitRootLogin no — arbeiten Sie als benannter Benutzer mit sudo. Siehe Benutzer, sudo und niemals als root arbeiten.
- PasswordAuthentication no — die mit Abstand wertvollste Zeile hier.
- KbdInteractiveAuthentication no — schließt den zweiten Passwortweg, den man vergisst und der Passwörter still weiterhin funktionieren lässt.
- AllowUsers — eine ausdrückliche Liste. Ein neues Systemkonto, das ein Paket anlegt, kann sich nicht anmelden.
Schränken Sie ein, wo er antwortet
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
sudo ufw deny 22/tcp
Ist eine feste Büroadresse nicht möglich, ist Fail2ban die Rückfalllösung — siehe Was Fail2ban aufhält. Den Port zu verschieben ist Kosmetik; siehe Den SSH-Port ändern.
Prüfen Sie, was am Ende gilt
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers'
sshd -T gibt die wirksame Konfiguration aus, samt allem, was weiter unten in einer Include-Datei gesetzt ist. Es ist die einzige Lesart, die berücksichtigt, dass eine Distribution eine Datei in sshd_config.d legt und Sie überstimmt.