Wie repariert man SSH auf einem Linux-Server? Praktischer Wiederherstellungsleitfaden

Zu beheben SSH auf einem Linux-ServerNetzwerkverfügbarkeit prüfen, bestätigen SSH Wenn der SSHD-Daemon läuft, stellen Sie sicher, dass der korrekte Port in der Firewall und den Cloud-Sicherheitsgruppen geöffnet ist, prüfen Sie die Protokolle auf Fehler, validieren Sie die Syntax und Berechtigungen der sshd_config-Datei und starten Sie den Dienst anschließend neu. Falls Sie ausgesperrt sind, verwenden Sie die Provider-Konsole oder den Rettungsmodus, um den Zugriff wiederherzustellen.

Secure Shell (SSH) ist die Lebensader jedes Linux-Servers. Wenn sie ausfällt, steht der Betrieb still. In dieser Anleitung zeige ich Ihnen, wie Sie das Problem beheben. SSH Schritt für Schritt auf einem Linux-Server, wobei Verbindungstimeouts, „Zugriff verweigert (öffentlicher Schlüssel)“, Dienstausfälle, Fehlkonfigurationen, SELinux, Fail2ban und Probleme mit Cloud-Firewalls behandelt werden, unter Verwendung sicherer, bewährter Methoden aus jahrelanger Serveradministration.

Egal, ob Sie manage Ob VPS, dedizierter Server oder Cloud-Instanz – diese Prüfungen helfen Ihnen bei der Diagnose und Behebung von Problemen. SSH Probleme schnell lösen, ohne Aussperrungen zu riskieren. Wenn Sie ein managed VPS von YouStableUnser Support kann Ihnen auch den Zugriff wiederherstellen und Ihr System absichern. SSH Konfiguration für Sie.

Schnellprüfungen für häufige SSH Fehler

1) Bestätigen Sie die Netzwerkerreichbarkeit und DNS

Falls Sie überhaupt keine Verbindung herstellen können, stellen Sie sicher, dass der Server online ist und der Hostname korrekt aufgelöst wird.

# From your local machine
ping -c3 your-server.com
dig +short A your-server.com
traceroute your-server.com  # or mtr your-server.com

If DNS ist falsch. Verbinden Sie sich über den Server öffentliche IP-Adresse anstelle des Hostnamens und Behebung DNS später.

2) Testen Sie die Port-Erreichbarkeit (Standard: 22)

Überprüfen Sie, ob die SSH Der Port ist offen und erreichbar. Einige Administratoren verschieben SSH an einen nicht standardmäßigen Anschluss.

nc -vz your-server.com 22
# or
nmap -p 22 your-server.com

Falls die Verbindung verweigert oder gefiltert wird, fahren Sie mit den Korrekturen an Firewall und Cloud-Sicherheitsgruppen fort.

3) Überprüfen Sie die SSH Der Dienst (sshd) läuft.

Wenn Sie ausgesperrt sind, verwenden Sie die Web-/VNC-Konsole des Anbieters oder einen KVM-Switch, um Befehle auf dem System auszuführen.

# Systemd-based distros (Ubuntu, Debian, RHEL, CentOS, AlmaLinux, Rocky)
sudo systemctl status ssh     # Debian/Ubuntu service name: ssh
sudo systemctl status sshd    # RHEL/CentOS/Alma/Rocky service name: sshd

# Start and enable if needed
sudo systemctl enable --now sshd || sudo systemctl enable --now ssh

# Check listening port
sudo ss -tlnp | grep sshd     # or: sudo netstat -tlnp | grep sshd

Falls es nicht reagiert, überprüfen Sie als Nächstes die Protokolle und die Konfiguration.

Beheben Sie Verbindungsfehler oder Zeitüberschreitung

Stellen Sie sicher, dass sshd am richtigen Port lauscht.

Überprüfen und korrigieren Sie die Port-Direktive in /etc/ssh/sshd_config und testen Sie anschließend die Konfiguration vor dem Neustart.

sudo grep -i '^Port' /etc/ssh/sshd_config
# Test config (no output = OK)
sudo sshd -t
# Restart service
sudo systemctl restart sshd || sudo systemctl restart ssh
# Confirm listening port
sudo ss -tlnp | grep sshd

Wenn Sie den Port geändert haben, denken Sie daran, ihn beim Verbindungsaufbau anzugeben: ssh -p 2222 user@host.

Öffnen Sie den Port in der Server-Firewall (UFW, firewalld, iptables).

Erlauben SSH in Ihrer Host-Firewall. Ersetzen Sie 22 durch Ihren benutzerdefinierten Port, falls dieser geändert wurde.

# UFW (Ubuntu)
sudo ufw allow 22/tcp
sudo ufw status

# firewalld (RHEL/Alma/Rocky/CentOS Stream/Fedora)
sudo firewall-cmd --permanent --add-service=ssh
# If using a non-standard port:
# sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

# iptables (legacy)
sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT
sudo service iptables save || sudo iptables-save | sudo tee /etc/iptables.rules

Überprüfen Sie die Cloud-Sicherheitsgruppen und die Firewalls der Anbieter.

Bei AWS, GCP, Azure oder vielen VPS-Anbietern kann eine Netzwerk-Firewall blockieren SSH Unabhängig von der Firewall des Betriebssystems: Erlauben Sie TCP 22 (oder Ihren benutzerdefinierten Port) von Ihrer IP-Adresse oder aus vertrauenswürdigen Bereichen in der Konsole Ihres Anbieters.

Überprüfung von Fail2ban, CSF und Intrusion-Tools

Wenn Sie es mehrmals versucht haben, könnte Ihre IP-Adresse gesperrt sein. Entsperren oder vorübergehend deaktivieren Sie sie, um es zu testen.

sudo fail2ban-client status sshd
sudo fail2ban-client unban <your.ip.address>

# CSF (ConfigServer Firewall)
sudo csf -g <your.ip.address>    # find
sudo csf -dr <your.ip.address>   # remove/deny rule
sudo csf -tr <your.ip.address>   # temporary allow

Behebung von Authentifizierungsfehlern

Passwort- vs. Schlüsselauthentifizierung

Informieren Sie sich über die von sshd_config erlaubten Einstellungen. Viele Server deaktivieren Passwörter aus Sicherheitsgründen und erfordern SSH Tasten.

sudo egrep -i '^(PasswordAuthentication|PubkeyAuthentication|PermitRootLogin)' /etc/ssh/sshd_config
sudo sshd -T | egrep 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Falls Sie Passwörter vorübergehend aktivieren müssen, um den Zugriff wiederherzustellen, setzen Sie PasswordAuthentication auf „Ja“ und starten Sie den Computer neu. SSHMelden Sie sich an, aktivieren Sie dann die Schlüssel erneut und deaktivieren Sie die Passwörter wieder – das ist eine bewährte Vorgehensweise.

Beheben Sie die Fehlermeldung „Zugriff verweigert (öffentlicher Schlüssel)“, indem Sie die Berechtigungen korrigieren.

SSH ignoriert Tasten wenn die Dateiberechtigungen oder der Besitz zu offen oder fehlerhaft sind.

# As the target user (or via sudo specifying user paths)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh
ls -ld ~/.ssh; ls -l ~/.ssh/authorized_keys

# Confirm the server sees your key attempt (on the client)
ssh -vvv user@server

Stellen Sie sicher, dass sich Ihr öffentlicher Schlüssel (~/.ssh/id_rsa.pub oder id_ed25519.pub) in ~/.ssh/authorized_keys auf dem Server befindet, und zwar genau eine Zeile pro Schlüssel.

Setzen Sie ein Benutzerpasswort zurück oder fügen Sie einen Schlüssel über die Konsole hinzu.

Falls Sie vollständig ausgesperrt sind, verwenden Sie die Provider-Konsole/KVM oder den Rettungsmodus, um Ihren Schlüssel hinzuzufügen oder ein Passwort sicher zurückzusetzen.

# Create user and add a key (replace <user> and pubkey)
sudo useradd -m -s /bin/bash <user>
sudo mkdir -p /home/<user>/.ssh
echo "ssh-ed25519 AAAA... your_email" | sudo tee /home/<user>/.ssh/authorized_keys
sudo chown -R <user>:<user> /home/<user>/.ssh
sudo chmod 700 /home/<user>/.ssh
sudo chmod 600 /home/<user>/.ssh/authorized_keys
sudo usermod -aG sudo <user>  # Debian/Ubuntu
sudo usermod -aG wheel <user>  # RHEL/Alma/Rocky

Root-Anmelderichtlinien

Aus Sicherheitsgründen sollte PermitRootLogin auf „Nein“ gesetzt oder das Passwort verbieten. Verwenden Sie einen Benutzer mit sudo-Rechten für die Administration. Falls Sie Root-Rechte vorübergehend aktivieren müssen, setzen Sie diese nach der Wiederherstellung zurück und sichern Sie die Anwendung mit Schlüsseln oder Zwei-Faktor-Authentifizierung.

sshd_config reparieren und schützen

Erstellen Sie Backups und überprüfen Sie die Syntax.

Vor der Bearbeitung immer eine Sicherungskopie erstellen. Syntax überprüfen, um Sperrungen zu vermeiden.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)
sudo nano /etc/ssh/sshd_config   # or your editor
sudo sshd -t                     # syntax check
sudo systemctl restart sshd || sudo systemctl restart ssh

Kennen Sie die effektiven Einstellungen und den Rollback-Plan?

Listen Sie die effektiven Einstellungen auf und halten Sie die Sitzung beim Neustart aktiv, um eine Aussperrung zu vermeiden.

sudo sshd -T | less
# If broken, revert quickly:
sudo mv /etc/ssh/sshd_config.bak.* /etc/ssh/sshd_config
sudo systemctl restart sshd || sudo systemctl restart ssh

Behebt die Diskrepanzen zwischen Host-Schlüssel und known_hosts.

Nach einer Neuinstallation oder einem erneuten Kompilieren des Servers können sich dessen Host -Schlüssel ändern, was zu Clientwarnungen führen kann. Überprüfen Sie die Fingerabdrücke über die Konsole und aktualisieren Sie anschließend die Datei known_hosts.

# On server (list fingerprints)
sudo ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

# On client (remove old entry and reconnect)
ssh-keygen -R your-server.com
ssh [email protected]

Lesen Sie auch: phpMyAdmin auf einem Linux-Server reparieren

SELinux- oder AppArmor-Interferenzen

SELinux-Port- und Kontextprobleme (RHEL/Alma/Rocky/CentOS/Fedora)

Wenn Sie das ändern SSH Port zulassen, in SELinux zulassen. Außerdem Dateikontexte für Benutzer wiederherstellen. SSH Verzeichnisse.

# Permit non-standard SSH port
sudo semanage port -l | grep ssh
sudo semanage port -a -t ssh_port_t -p tcp 2222 2>/dev/null || 
sudo semanage port -m -t ssh_port_t -p tcp 2222

# Restore contexts
sudo restorecon -Rv /etc/ssh /home/*/.ssh

# Temporary test (not a fix): set SELinux permissive
sudo setenforce 0  # Remember to re-enable: setenforce 1

AppArmor-Profile (Ubuntu/Debian)

Überprüfen Sie, ob das AppArmor-Profil für SSHD erforderliche Pfade blockiert. Prüfen Sie die Ausgabe von dmesg oder die Protokolle und passen Sie die Einstellungen an oder aktivieren Sie testweise den Beschwerdemodus.

sudo aa-status
# Switch to complain mode for testing
sudo aa-complain /etc/apparmor.d/usr.sbin.sshd

Protokolle und detaillierte Diagnose

Lesen Sie die Serverprotokolle für SSH Fehler

Logmeldungen geben oft Aufschluss über die Ursache: fehlerhafte Berechtigungen, gesperrte IP-Adresse, Konfigurationssyntax oder fehlende Schlüssel.

sudo journalctl -u ssh -e     # Debian/Ubuntu
sudo journalctl -u sshd -e    # RHEL/Alma/Rocky
sudo tail -f /var/log/auth.log /var/log/secure

Zur besseren Übersicht wird die Protokollierung vorübergehend erhöht.

Setzen Sie LogLevel DEBUG in sshd_config, starten Sie den Dienst neu, reproduzieren Sie das Problem, sammeln Sie Protokolle und stellen Sie den Wert anschließend wieder auf INFO zurück.

sudo sed -i 's/^#?LogLevel.*/LogLevel DEBUG/' /etc/ssh/sshd_config
sudo systemctl restart sshd || sudo systemctl restart ssh
# After diagnosing:
sudo sed -i 's/^LogLevel.*/LogLevel INFO/' /etc/ssh/sshd_config
sudo systemctl restart sshd || sudo systemctl restart ssh

Verwenden Sie die clientseitige Debug-Ausgabe.

Aktivieren Sie den ausführlichen Modus, um die Schlüsselaushandlung, die Authentifizierungsmethoden und die Gründe für die Verbindungsunterbrechung anzuzeigen.

ssh -vvv -p 22 [email protected]

Notfallzugang und Wiederherstellungsoptionen

Verwenden Sie die Cloud-Anbieterkonsole oder KVM.

Die meisten Anbieter bieten eine integrierte Konsole an, die Sie vom Dashboard aus öffnen können, um den Terminalzugriff wiederzuerlangen, selbst wenn SSH ist ausgefallen. Korrigieren Sie die Firewall-Regeln, setzen Sie die sshd-Konfiguration zurück oder starten Sie den Dienst von dort aus neu.

Im Rettungs-/Einzelbenutzermodus starten

Im Rettungsmodus das Root-Dateisystem einbinden, gegebenenfalls chroot verwenden und reparieren. SSH KonfigurationBenutzer, Schlüssel und Firewall, ohne dass das Netzwerk Sie aktiv blockiert.

# Common recovery tasks
sudo nano /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl restart sshd || sudo systemctl restart ssh
# Regenerate host keys if missing
sudo ssh-keygen -A
# Reinstall server package if corrupted
sudo apt-get update && sudo apt-get install --reinstall openssh-server
sudo dnf reinstall -y openssh-server

Härten SSH Nachdem Sie es repariert haben

Verwenden Sie ausschließlich Schlüsselauthentifizierung und deaktivieren Sie Passwörter.

Schlüssel sind sicherer und verhindern die meisten Brute-Force-Angriffe. Setzen Sie „PubkeyAuthentication yes“ und „PasswordAuthentication no“, bestätigen Sie den Zugriff mit einer zweiten Sitzung und starten Sie anschließend sshd neu.

Optional: Ändern Sie die SSH Hafen (Sicherheit durch Lärmreduzierung)

Der Wechsel von Port 22 auf einen höheren Port reduziert zwar die Bot-Attacken, bietet aber keinen vollständigen Schutz. Wenn Sie den Port ändern, aktualisieren Sie SELinux, die Host-Firewall und die Cloud-Sicherheitsgruppen regelmäßig.

Fügen Sie Fail2ban und 2FA für einen stärkeren Schutz hinzu.

Aktivieren Sie Fail2ban, um Brute-Force-Angriffe zu drosseln. Erwägen Sie die Zwei-Faktor-Authentifizierung (2FA, z. B. Google Authenticator, Duo) für privilegierte Konten. Erstellen Sie stets Sicherungskopien Ihrer funktionierenden sshd_config-Dateien.

Konfiguration übernehmen manageÄnderungen und Backups

Verwenden Sie Ansible, Puppet oder Chef zur Standardisierung. SSH Einstellungen serverübergreifend. Bekannte, funktionierende Konfigurationen in der Versionskontrolle speichern. Verwalteter VPS von YouStable kann das Patchen auslagern, SSH Härtung und 24/7-Vorfallsreaktion, damit Sie sich auf Ihre Anwendungen konzentrieren können.

Häufige Fehlermuster und wie man sie behebt

Fehler: Verbindung abgelehnt

Mögliche Ursachen: SSHD läuft nicht, falscher Port, Host-Firewall blockiert oder Cloud-Sicherheitsgruppe verweigert den Zugriff. Starten Sie SSHD, öffnen Sie den Port und überprüfen Sie dies mit `ss -tlnp` und `nc/nmap`.

Fehler: Zeitüberschreitung bei der Verbindung

Netzwerkpfad- oder Firewallproblem. Überprüfen Sie die Firewalls des Anbieters, das Routing, die Sicherheitsgruppen und bestätigen Sie die öffentliche IP-Adresse. DNS Aufzeichnungen sind korrekt.

Fehler: Zugriff verweigert (öffentlicher Schlüssel)

Korrigieren Sie die Dateiberechtigungen, stellen Sie sicher, dass der korrekte öffentliche Schlüssel in authorized_keys vorhanden ist, und vergewissern Sie sich, dass die Pubkey-Authentifizierung aktiviert ist. Verwenden Sie ssh -vvv, um den angebotenen Schlüssel anzuzeigen.

Fehler: Die Remote-Host-Identifizierung hat sich geändert

Hostschlüssel wurden geändert (z. B. durch Neuaufbau). Überprüfen Sie die Fingerabdrücke über die Konsole, führen Sie dann auf dem Client `ssh keygen -R Hostname` aus und stellen Sie die Verbindung erneut her, um dem neuen Schlüssel zu vertrauen.

Häufig gestellte Fragen