Innerhalb weniger Minuten nach der Inbetriebnahme eines mit dem Internet verbundenen Servers gehen die ersten automatisierten Anmeldeversuche über den SSH-Port ein. Dieser Artikel behandelt die wichtigsten Sicherheitsmaßnahmen und erläutert, wie Sie überprüfen können, ob die Konfiguration tatsächlich wirksam ist. Die Grundlagen von SSH werden im Artikel „Linux Secure Shell (SSH)“ erläutert.

Wir haben die Schritte auf Systemen mit AlmaLinux 10.2, Ubuntu 24.04 und Debian 12 getestet, und zwar auf virtuellen Maschinen, die aus den jeweiligen Cloud-Images der Distributionen installiert wurden. Führen Sie die Befehle als Root-Benutzer oder mit „sudo“ aus.

Bevor Sie Änderungen vornehmen

• Lassen Sie eine funktionierende SSH-Verbindung offen, bis Sie die neue Konfiguration in einer neuen Verbindung getestet haben. Ein Neustart des sshd-Dienstes bricht bereits bestehende Verbindungen nicht ab, sodass Sie im Falle eines Fehlers die Situation beheben können.
• Überprüfen Sie vor jedem Neustart die Syntax: sudo sshd -t. Wenn keine Ausgabe erfolgt, ist die Datei in Ordnung.
• Wissen Sie, wie Sie ohne SSH auf den Server zugreifen können (auf einem VPS über die Konsole des Control Panels), für den Fall, dass Sie sich versehentlich aussperren sollten?

Wo werden die Einstellungen gespeichert?

Die Hauptkonfigurationsdatei ist /etc/ssh/sshd_config, doch auf allen drei Testsystemen steht am Anfang dieser Datei die Zeile „Include /etc/ssh/sshd_config.d/*.conf“. Da sshd bei einer Konfiguration das erste Vorkommen berücksichtigt, überschreiben die Dateien in diesem Verzeichnis die Hauptdatei.

Dies könnte für Überraschung sorgen: Auf Rechnern, die aus Cloud-Images installiert wurden, legt „cloud-init“ hier eine Datei namens „50-cloud-init.conf“ ab, die beispielsweise die Zeile „PasswordAuthentication no“ enthält. Im Test blieb die am Ende der Hauptdatei „sshd_config“ eingetragene Einstellung „PasswordAuthentication yes“ wirkungslos, da die Drop-in-Datei diese Einstellung zuvor festgelegt hatte.

Speichern Sie daher Ihre eigenen Einstellungen in einer separaten Datei in diesem Verzeichnis, deren Name im Verzeichnis vor dem „cloud-init“-Dateinamen steht, zum Beispiel:

sudo nano /etc/ssh/sshd_config.d/10-biztonsag.conf

Was letztendlich gültig ist, müssen Sie nicht anhand der Dateien erraten: Der Befehl „sshd -T“ gibt die tatsächlich verwendeten Werte aus.

sudo sshd -T | grep -E '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication) '

Die Standardwerte im Test unter AlmaLinux 10 und Ubuntu 24.04: port 22, „permitrootlogin without-password“ (der Root-Benutzer kann sich nur mit einem Schlüssel anmelden), „passwordauthentication no“ (dies wurde von cloud-init festgelegt).

1. Zugang per Schlüssel, Passwort sperren

Der wichtigste Schritt: Melden Sie sich mit einem Schlüssel anstelle eines Passworts an und deaktivieren Sie die Anmeldung per Passwort. Auf Ihrem eigenen Computer:

ssh-keygen -t ed25519
ssh-copy-id felhasznalo@szervercime

Versuchen Sie, sich in einem neuen Terminal ohne Passwort anzumelden. Sollte dies gelingen, fügen Sie auf dem Server in die Datei „10-biztonsag.conf“ Folgendes ein:

PasswordAuthentication no
KbdInteractiveAuthentication no

Anschließend:

sudo sshd -t && sudo systemctl restart sshd     # Ubuntu, Debian: ssh

Bei einem Passwortversuch gibt der Server daraufhin folgende Meldung aus: „Permission denied (publickey…)“. Die Schlüsselverwaltung unter Windows wird ebenfalls in der Anleitung zur SSH-Verbindung mit dem VPS beschrieben.

2. Sperrung des Root-Zugriffs

Erstellen Sie zunächst einen eigenen Benutzer mit sudo-Rechten und versuchen Sie, sich damit anzumelden (siehe: Benutzer anlegen und sudo-Rechte vergeben). Anschließend:

PermitRootLogin no

Im Test zeigte der Befehl „sshd -T“ nach der Eintragung der Zeile in die Datei „10-biztonsag.conf“ bereits den Wert „permitrootlogin no“ an. Wenn Sie statt der vollständigen Sperrung des Root-Zugangs lediglich den Root-Zugang per Passwort ausschließen möchten, ist „PermitRootLogin prohibit-password“ (auch als „without-password“ bezeichnet) die richtige Einstellung; dies ist auch der Standardwert der Testsysteme.

3. Ändern des SSH-Ports

Das Ändern des Ports macht ein schwaches Passwort nicht sicherer, jedoch werden in den Protokollen deutlich weniger automatisierte Zugriffsversuche verzeichnet. Tragen Sie den neuen Port in die Drop-in-Datei ein und belassen Sie den Port 22 so lange, bis Sie den neuen Port getestet haben:

Port 22
Port 2255

Die weiteren Schritte variieren je nach Distribution.

AlmaLinux, Rocky Linux: SELinux und firewalld

SELinux erlaubt es sshd nur, auf Ports vom Typ „ssh_port_t“ zu lauschen. Wenn Sie dies nicht berücksichtigen, wird sshd zwar gestartet, lauscht jedoch nicht auf dem neuen Port; im Protokoll erscheint die Meldung „Bind to port 2255 … failed: Permission denied“. Der Befehl „semanage“ ist im Paket „policycoreutils-python-utils“ enthalten, das auf dem Cloud-Image nicht installiert war:

sudo dnf install policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2255
sudo systemctl restart sshd

Wenn firewalld läuft (sudo firewall-cmd --state), aktivieren Sie bitte auch den neuen Port:

sudo firewall-cmd --permanent --add-port=2255/tcp
sudo firewall-cmd --reload

Ubuntu 24.04: Socket-Aktivierung

Unter Ubuntu 24.04 wird Port 22 nicht vom ssh-Dienst, sondern von ssh.socket überwacht. Im Test zeigte der Befehl „systemctl restart ssh“ nach der Portänderung keine Wirkung; weiterhin war nur Port 22 aktiv. Der Port ändert sich erst nach einem „daemon-reload“ und einem Neustart des Sockets:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Falls ufw aktiviert ist (im Test war dies standardmäßig nicht der Fall), geben Sie den Port frei: sudo ufw allow 2255/tcp.

Debian

Unter Debian reicht ein Neustart aus: „sudo systemctl restart ssh“.

Überprüfung

sudo ss -tlnp | grep sshd

Stellen Sie von einem neuen Terminal aus eine Verbindung zum neuen Port her (ssh -p 2255 felhasznalo@szervercime). Wenn dies funktioniert, kann die Zeile „Port 22“ gelöscht und Port 22 in der Firewall geschlossen werden.

4. Begrenzung der Anmeldeversuche

Fail2ban überwacht die Protokolle und sperrt IP-Adressen, von denen zahlreiche fehlgeschlagene Anmeldeversuche ausgehen, vorübergehend über die Firewall. Die Installation sowie mögliche Fallstricke (beispielsweise, dass auf AlmaLinux „firewalld“ laufen muss, da die Sperrung sonst wirkungslos ist) werden im Artikel „Installation und Konfiguration von Fail2ban“ beschrieben. Auf cPanel-Servern übernehmen cPHulk und CSF/LFD dieselbe Funktion.

Die Anzahl der Anmeldeversuche innerhalb einer Verbindung wird durch den Parameter „MaxAuthTries“ begrenzt (der Standardwert betrug im Test 6), beispielsweise „MaxAuthTries 3“.

5. Aktualisierungen

Die Sicherheitspatches für OpenSSH werden mit den Systemaktualisierungen bereitgestellt (im Test war auf AlmaLinux 10 OpenSSH 9.9 und auf Ubuntu 24.04 die Version 9.6 installiert). Aktivieren Sie die automatischen Sicherheitsaktualisierungen, siehe: Systemaktualisierung: dnf, apt und automatische Aktualisierungen.

aWh-Server

Bei den KVM-VPS-Servern liegen alle oben genannten Einstellungen in Ihrer Hand. Bei unserem cPanel-Hosting-Paket läuft SSH auf Port 4231, und der Zugriff ist nur mit einem Schlüssel möglich; Informationen zum Hochladen des Schlüssels finden Sie im Artikel „Erstellen oder Hochladen eines SSH-Schlüssels auf einen cPanel-Server“.