Übersicht: SSH Root Login verbieten

Der direkte Root-Login über SSH ist eine der häufigsten Schwachstellen auf frisch aufgesetzten Linux-Servern. Viele Distributionen liefern OpenSSH noch immer mit aktiviertem Root-Login aus, sodass Angreifer nur ein einziges Passwort erraten müssen, um vollständige Kontrolle über das System zu erlangen.

In diesem Beitrag zeige ich, warum du den direkten Root-Login über SSH deaktivieren solltest, wie du die sshd_config sicher anpasst, welche alternativen Konfigurationen existieren und welche zusätzlichen Härungsmaßnahmen sich sinnvoll ergänzen lassen. Zum Abschluss gibt es Tipps für den Fall, dass du dich nach einer Änderung selbst aus dem Server aussperrst.

Was ist SSH Root Login?

SSH Root Login ermöglicht es, sich direkt als Root-Benutzer über SSH auf einem Linux-Server anzumelden. Dies stellt ein erhebliches Sicherheitsrisiko dar, da der Root-Account uneingeschränkte Systemrechte besitzt und ein bevorzugtes Ziel für Angreifer ist.

• Übersicht: SSH Root Login verbieten
• Was ist SSH Root Login?
• Warum Root SSH Login verbieten?
• Voraussetzungen
• SSH-Status prüfen
• SSH-Service überprüfen
• Aktuelle Root-Login-Einstellung prüfen
• Root Login deaktivieren
• Schritt 1: SSH-Konfiguration bearbeiten
• Schritt 2: Root-Login-Einstellung ändern
• Schritt 3: Konfiguration validieren
• Schritt 4: SSH-Service neu starten
• Alternative Konfigurationen
• Option 1: Root-Login nur mit SSH-Keys
• Option 2: Root-Login nur von bestimmten IPs
• Option 3: Root-Login nur für bestimmte Commands
• Konfiguration testen
• Test 1: Root-Login versuchen (sollte fehlschlagen)
• Test 2: Regulärer Benutzer-Login testen
• Test 3: SSH-Logs überprüfen
• Zusätzliche SSH-Sicherheitsmaßnahmen
• Erweiterte SSH-Härtung
• SSH-Schlüssel einrichten
• Fail2Ban installieren
• Monitoring und Troubleshooting
• SSH-Verbindungen überwachen
• Häufige Probleme lösen
• Problem: Ausgesperrt nach Konfigurationsänderung
• Problem: SSH-Service startet nicht
• Problem: SSH-Keys funktionieren nicht
• Best Practices
• Empfohlene SSH-Konfiguration
• Zusätzliche Sicherheitsmaßnahmen
• Tipps
• Fazit

Warum Root SSH Login verbieten?

• Sicherheitsrisiko: Root-Account hat vollständige Systemkontrolle
• Brute-Force-Schutz: Angreifer können nicht direkt Root-Credentials erraten
• Auditierbarkeit: Bessere Nachverfolgung von Benutzeraktionen
• Privilege Escalation: Kontrollierte Rechteerweiterung über sudo
• Best Practice: Industrie-Standard für Server-Sicherheit

Der direkte Root-Login via SSH (Secure Shell) ist eine häufige Sicherheitslücke auf Linux-Servern. Standardmäßig kann sich der Root-Benutzer direkt per SSH anmelden, was ein hohes Risiko darstellt, da Angreifer so gezielt versuchen können, sich mit dem mächtigsten Benutzerkonto Zugriff zu verschaffen. Um die Sicherheit Ihres Servers zu erhöhen, sollten Sie den Root-Login über SSH deaktivieren.

Voraussetzungen

Bevor du den Root-Login deaktivierst, stelle sicher, dass:

• Ein SSH-Daemon (OpenSSH) installiert und aktiv ist
• Du einen alternativen Benutzer mit sudo-Berechtigung hast
• Du Zugriff auf den Server über die Konsole hast (falls SSH-Probleme auftreten)
• Eine Backup-Verbindung besteht (für den Notfall)

SSH-Status prüfen

Bevor du die Konfiguration änderst, solltest du den aktuellen Zustand des SSH-Dienstes und die aktiven Einstellungen prüfen. So erkennst du, ob der Dienst überhaupt läuft und welchen Wert PermitRootLogin aktuell hat.

SSH-Service überprüfen

1
2
3
4
5
6
7
8

# Service-Status anzeigen
sudo systemctl status ssh

# SSHD-Konfiguration testen
sudo sshd -t

# Aktuelle SSH-Verbindungen anzeigen
ss -tlnp | grep :22

Aktuelle Root-Login-Einstellung prüfen

1
2
3
4
5

# Aktuelle Konfiguration anzeigen (Server)
sudo grep -i "^PermitRootLogin" /etc/ssh/sshd_config

# Alle relevanten SSHD-Parameter prüfen (effektive Werte)
sudo sshd -T | grep -Ei "(permitrootlogin|passwordauthentication|pubkeyauthentication)"

Root Login deaktivieren

Im Folgenden deaktivieren wir den direkten Root-Login vollständig. Die Änderung erfolgt in der Hauptkonfigurationsdatei des SSH-Daemons unter /etc/ssh/sshd_config. Arbeite die Schritte nacheinander ab und validiere die Konfiguration, bevor du den Dienst neu startest.

Schritt 1: SSH-Konfiguration bearbeiten

1
2
3
4
5

# Backup der aktuellen Konfiguration erstellen
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

# Konfigurationsdatei bearbeiten (Server)
sudo nano /etc/ssh/sshd_config

Schritt 2: Root-Login-Einstellung ändern

Suche nach dieser Zeile:

1

#PermitRootLogin yes

Ändere sie zu:

1

PermitRootLogin no

Schritt 3: Konfiguration validieren

1
2
3
4
5

# Syntax der SSHD-Konfiguration prüfen
sudo sshd -t

# Bei Erfolg: keine Ausgabe
# Bei Fehlern: Fehlermeldung wird angezeigt

Schritt 4: SSH-Service neu starten

1
2
3
4
5
6
7
8
9
10

# Moderne Systeme (systemd)
sudo systemctl restart ssh

# Ältere Systeme
sudo service ssh restart

# Status nach Neustart prüfen
sudo systemctl status ssh
# Hinweis: Auf RHEL/CentOS/Alma/Rocky heißt der Dienst meist "sshd"
# sudo systemctl status sshd

Alternative Konfigurationen

Option 1: Root-Login nur mit SSH-Keys

1
2

# In /etc/ssh/sshd_config
PermitRootLogin prohibit-password

Diese Einstellung erlaubt die Anmeldung als Root ausschließlich mit einem hinterlegten SSH-Schlüssel. Passwort-basierte Logins werden abgewiesen. Das ist ein guter Kompromiss, wenn du beispielsweise automatisierte Wartungs-Skripte brauchst, die als Root laufen sollen, aber weiterhin Brute-Force-Angriffe auf das Root-Passwort ausschließen willst. Achte darauf, dass ausschließlich vertrauenswürdige Public Keys in /root/.ssh/authorized_keys liegen und der private Schlüssel sicher verwahrt wird.

Option 2: Root-Login nur von bestimmten IPs

1
2
3
4
5
6

# In /etc/ssh/sshd_config
PermitRootLogin no

# Zusätzlich Match-Block für spezielle IPs
Match Address 192.168.1.100
    PermitRootLogin yes

Mit einem Match Address-Block lässt sich der Root-Login auf einzelne, explizit freigegebene IP-Adressen beschränken. Das ist beispielsweise sinnvoll, wenn Wartungsarbeiten von einem festen Administrations-Netzwerk aus durchgeführt werden. Beachte, dass Match-Blöcke am Ende der sshd_config stehen müssen und alle darauffolgenden Direktiven nur für die Bedingung gelten. Ein neuer Match all-Block oder das Dateiende beendet den Gültigkeitsbereich.

Option 3: Root-Login nur für bestimmte Commands

1
2

# In /etc/ssh/sshd_config
PermitRootLogin forced-commands-only

Diese restriktivste Variante erlaubt Root-Logins nur dann, wenn im zugehörigen SSH-Public-Key in /root/.ssh/authorized_keys ein command="..."-Eintrag gesetzt ist. Der Login ist also an einen fest definierten Befehl gebunden, der automatisch ausgeführt wird, anstatt eine interaktive Shell zu öffnen. Das eignet sich für automatisierte Backup- oder Monitoring-Jobs, die mit Root-Rechten laufen müssen, ohne dass ein menschlicher Angreifer die Shell übernehmen könnte.

Konfiguration testen

Nachdem du die Konfiguration geändert und den Dienst neu gestartet hast, solltest du die Änderungen in einer eigenen Sitzung testen. Wichtig: Halte dabei deine bestehende SSH-Verbindung offen, damit du im Fehlerfall nicht ausgesperrt bist.

Test 1: Root-Login versuchen (sollte fehlschlagen)

1
2
3
4
5

# Von anderem Terminal/System
ssh root@server-ip

# Erwartete Ausgabe:
# Permission denied (publickey,password)

Test 2: Regulärer Benutzer-Login testen

1
2
3
4
5
6

# Mit regulärem Benutzer anmelden
ssh username@server-ip

# sudo-Zugriff testen
sudo whoami
# Sollte "root" ausgeben

Test 3: SSH-Logs überprüfen

1
2
3
4
5
6
7

# Aktuelle SSH-Verbindungsversuche anzeigen
sudo journalctl -u ssh -f
# oder (je nach Distribution)
sudo journalctl -u sshd -f

# Oder traditionelle Logs
sudo tail -f /var/log/auth.log

Zusätzliche SSH-Sicherheitsmaßnahmen

Das Deaktivieren des Root-Logins ist nur der erste Schritt. OpenSSH bietet eine Reihe weiterer Direktiven, mit denen sich der Dienst gezielt härten lässt. Die folgenden Einstellungen ergänzen die Grundkonfiguration sinnvoll und erschweren Angreifern das Leben zusätzlich.

Erweiterte SSH-Härtung

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# In /etc/ssh/sshd_config weitere Sicherheitseinstellungen:

# Passwort-Authentifizierung deaktivieren (nur SSH-Keys)
PasswordAuthentication no
PubkeyAuthentication yes

# Leere Passwörter verbieten
PermitEmptyPasswords no

# SSH-Port ändern (Security by Obscurity)
Port 2222

# Login-Versuche begrenzen
MaxAuthTries 3
MaxStartups 3

# Root-Login komplett verbieten
PermitRootLogin no

# Benutzer-/Gruppen-Beschränkungen
AllowUsers username1 username2
AllowGroups sshusers

# Timeout-Einstellungen
ClientAliveInterval 300
ClientAliveCountMax 2

SSH-Schlüssel einrichten

1
2
3
4
5
6
7
8

# SSH-Schlüsselpaar generieren (auf Client)
ssh-keygen -t ed25519 -C "user@hostname"

# Public Key auf Server kopieren
ssh-copy-id username@server-ip

# Oder manuell:
cat ~/.ssh/id_ed25519.pub | ssh username@server-ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Fail2Ban installieren

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# Ubuntu/Debian
sudo apt install fail2ban

# CentOS/RHEL/Alma/Rocky
sudo dnf install -y fail2ban

# Konfiguration für SSH
sudo tee /etc/fail2ban/jail.local > /dev/null <<EOF
[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log   # Debian/Ubuntu
#logpath = /var/log/secure    # RHEL/CentOS
maxretry = 3
bantime = 3600
EOF

# Fail2Ban starten
sudo systemctl enable --now fail2ban

Monitoring und Troubleshooting

Auch mit einer gehärteten Konfiguration solltest du regelmäßig prüfen, wer sich auf deinem Server anmeldet und ob es Anzeichen von Angriffsversuchen gibt. Die folgenden Befehle helfen dir dabei, den SSH-Betrieb zu überwachen und typische Probleme einzugrenzen.

SSH-Verbindungen überwachen

1
2
3
4
5
6
7
8
9
10
11

# Aktive SSH-Sitzungen anzeigen
who

# Detaillierte SSH-Sitzungsinfo
w

# SSH-Login-Historie
last | head -20

# Fehlgeschlagene Login-Versuche
sudo grep "Failed password" /var/log/auth.log | tail -10

Häufige Probleme lösen

Problem: Ausgesperrt nach Konfigurationsänderung

1
2
3
4

# Lösung über Konsole/VNC/IPMI
# Originalkonfiguration wiederherstellen (Server)
sudo cp /etc/ssh/sshd_config.backup /etc/ssh/sshd_config
sudo systemctl restart ssh

Problem: SSH-Service startet nicht

1
2
3
4
5
6

# Konfigurationsfehler finden
sudo sshd -t

# SSH im Debug-Modus starten
sudo systemctl stop ssh || sudo systemctl stop sshd || true
sudo /usr/sbin/sshd -D -d

Problem: SSH-Keys funktionieren nicht

1
2
3
4

# Berechtigungen der SSH-Verzeichnisse prüfen
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

Best Practices

Empfohlene SSH-Konfiguration

1
2
3
4
5
6
7
8

# Minimale sichere SSH-Konfiguration
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
ClientAliveInterval 300
Protocol 2

Zusätzliche Sicherheitsmaßnahmen

• Verwende SSH-Schlüssel statt Passwörter
• Ändere den Standard-SSH-Port (22)
• Implementiere Fail2Ban oder ähnliche Tools
• Aktiviere UFW/iptables Firewall-Regeln
• Regelmäßige Überwachung der SSH-Logs
• Verwende 2FA für SSH-Verbindungen

Tipps

• Teste Änderungen immer mit einer zweiten SSH-Verbindung
• Erstelle vor Änderungen ein Backup der sshd_config
• Dokumentiere alle SSH-Konfigurationsänderungen
• Überwache SSH-Logs auf verdächtige Aktivitäten
• Verwende starke, einzigartige SSH-Schlüssel
• Aktualisiere OpenSSH regelmäßig

Fazit

Das Deaktivieren des SSH Root Logins ist ein grundlegender Sicherheitsschritt für jeden Linux-Server. Es beseitigt das einfachste Angriffsszenario – das Erraten des Root-Passworts über SSH – und zwingt alle administrativen Tätigkeiten durch einen regulären Benutzer mit sudo zu laufen. Das erhöht nicht nur die Sicherheit, sondern verbessert auch die Nachvollziehbarkeit, da Rechteerweiterungen protokolliert werden.

In Kombination mit SSH-Schlüsseln statt Passwörtern, Fail2Ban und einer durchdachten Firewall-Regelung reduziert das Risiko erfolgreicher Angriffe erheblich. Wichtig ist, dass du Änderungen immer mit einer zweiten, offenen SSH-Sitzung absicherst und ein Backup der sshd_config bereithältst. Wer zusätzlich auf aktuelle OpenSSH-Versionen achtet und die Logs regelmäßig kontrolliert, betreibt einen deutlich robusteren Serverbetrieb.