Beheben von SSH-Fehlern

Erfahren Sie, wie Sie einige der häu­figs­ten Fehler beheben können, die bei der Ver­bin­dung zu einem Server mit SSH auftreten können.

Dieser Fehler wird ausgelöst, wenn sich das SSL-Zer­ti­fi­kat für einen Server ändert. Der Fehler ist darauf ausgelegt, einen po­ten­zi­el­len "Man in the middle" Angriff zu markieren. Die meisten Leute stoßen jedoch erst nach dem Neuaufbau eines Servers auf den Fehler.

Wenn Ihr Server neu ist oder sein Image seit der letzten Ver­bin­dung neu in­stal­liert wurde, klicken Sie einfach auf "Ak­zep­tie­ren", um das neue SSL-Zer­ti­fi­kat zu ak­zep­tie­ren und fort­zu­fah­ren.

Es gibt mehrere mögliche Gründe, warum Sie den Fehler "Port 22: Con­nec­tion refused" erhalten, wenn Sie versuchen, sich über SSH mit Ihrem Server zu verbinden.

Das erste, was Sie tun sollten, ist her­aus­zu­fin­den, ob der Server Ver­bin­dun­gen zum Port 22 von einem anderen Ort im Internet erlaubt. Verwenden Sie das Tool unter http://www.infobyip.com/ssh­ser­ver­test.php, um Ihren Server zu über­prü­fen.

Wenn diese Seite in der Lage ist, sich mit Ihrem Server zu verbinden, dann liegt das Problem auf Ihrer Seite. Sie befinden sich mög­li­cher­wei­se hinter einer Firewall, die den Da­ten­ver­kehr auf Port 22 blockiert. Viele Firmen und Bil­dungs­ein­rich­tun­gen blo­ckie­ren diesen Port aus Si­cher­heits­grün­den.

Wenn die Website keine Ver­bin­dung zu Ihrem Server her­stel­len kann, befindet sich das Problem entweder auf dem Server oder zwischen dem Server und dem Internet.

Wenn es sich um eine Neu­in­stal­la­ti­on handelt, wird der SSH-Server (sshd) mög­li­cher­wei­se nicht in­stal­liert. Sie können mit folgendem Befehl über­prü­fen, ob er auf Ihrem System in­stal­liert ist:

Wenn das System mit einem Pfad wie /usr/sbin/sshd antwortet, dann wurde der SSH-Server in­stal­liert. Wenn es statt­des­sen mit einem Fehler wie /usr/bin/which antwortet: no sshd in (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/local/sbin:/usr/sbin), dann müssen Sie sowohl den SSH-Client als auch den SSH-Server in­stal­lie­ren.

Auf Ubuntu und Debian in­stal­lie­ren Sie diese Programme mit dem Befehl:

Auf CentOS in­stal­lie­ren Sie diese Programme mit dem Befehl:

Über­prü­fen Sie mit folgendem Befehl, ob der SSH-Dienst aus­ge­führt wird:

Wenn der SSHD-Prozess nicht aktiv ist, starten Sie ihn.

• Auf Ubuntu und Debian: sudo service ssh start
• Unter CentOS: sudo systemctl start sshd

Wenn der SSHD-Prozess läuft, muss er mög­li­cher­wei­se neu gestartet werden.

• Auf Ubuntu und Debian: sudo service ssh restart
• Auf CentOS: sudo systemctl restart sshd

Port 22 ist der Standard-Port für SSH-Ver­bin­dun­gen. Wenn der SSH-Daemon Ihres Servers kon­fi­gu­riert wurde, um auf einen anderen Port als Port 22 zu hören, ver­wei­gert er SSH-Ver­bin­dun­gen zu Port 22.

Um zu über­prü­fen, auf welchem Port SSH lauscht, verwenden Sie den Befehl:

Wenn Sie Ihre SSH-Kon­fi­gu­ra­tio­nen kürzlich be­ar­bei­tet haben, über­prü­fen Sie die Syntax der Datei mit:

Es gibt mehrere mögliche Firewall-Szenarien, die zu diesem SSH-Fehler führen können, ein­schließ­lich:

• Wenn Sie kürzlich eine Firewall auf Ihrem Server in­stal­liert oder ak­tua­li­siert haben, haben Sie mög­li­cher­wei­se aus Versehen den SSH-Zugriff auf Port 22 blockiert (oder nicht erlaubt).

• Wenn Ihr Server kürzlich neu gestartet wurde, wurden Ihre Firewall-Regeln mög­li­cher­wei­se beim Booten nicht geladen, um den Da­ten­ver­kehr auf Port 22 zu er­mög­li­chen.

Wenn Sie ufw als Firewall auf Ihrem Server verwenden, können Sie alle Ihre ufw-Regeln mit folgendem Befehl auflisten:

Sie können den Zugriff über SSH mit folgendem Befehl zulassen:

Um zu sehen, ob Sie eine iptables-Regel verwenden, die den SSH-Verkehr blockiert, geben Sie den Befehl ein:

Sie können auch alle Ihre iptables-Regeln mit folgendem Befehl auflisten:

Um eine iptables-Regel zu löschen, be­ar­bei­ten Sie die Datei /etc/sysconfig/iptables und laden Sie dann die iptables-Kon­fi­gu­ra­ti­on mit diesem Befehl neu:

Der Fehler "Netz­werk­feh­ler: Soft­ware­be­ding­ter Ver­bin­dungs­ab­bruch" tritt auf, wenn Ihr Desktop-Computer die Ver­bin­dung un­er­war­tet beendet. Dies kann passieren, wenn Sie ein In­ter­net­pro­blem haben, ein­schließ­lich eines kurzen Ver­bin­dungs­pro­blems.

Es kann auch passieren, wenn der Server nicht mehr lauscht. Ihr Desktop sendet mehrere Pakete an den Server, bevor er die Ver­bin­dung aufgibt und die Sitzung beendet.

Wenn eine SSH-Sitzung mit "Write failed: broken pipe" oder "Network error: Con­nec­tion reset by peer", beendet wird, bedeutet dies, dass die Sitzung ab­ge­lau­fen ist.

Das Timeout kann auf Ihrem Computer, auf dem Server oder auf einer Firewall da­zwi­schen auftreten. Die SSH-Sitzung wird au­to­ma­tisch ge­schlos­sen, wenn sie zu lange im Leerlauf bleibt.

Die Lösung besteht darin, Ihren SSH-Client so ein­zu­stel­len, dass er "Keepalive-Pakete" sendet. Dies sind kleine Da­ten­pa­ke­te, die in re­gel­mä­ßi­gen Abständen au­to­ma­tisch versendet werden. Dadurch wird dem Netzwerk mit­ge­teilt, dass Ihre Ver­bin­dung noch aktiv ist.

Linux oder Unix

Wenn Sie einen Linux- oder Unix-Desktop verwenden, um sich mit Ihrem Server zu verbinden, be­ar­bei­ten Sie /etc/ssh/ssh/sshd_config und fügen Sie­fol­gen­des hinzu:

Speichern und schließen Sie die Datei, und starten Sie dann SSH neu, damit die Än­de­run­gen wirksam werden.

Führen Sie eine Tra­ce­rou­te zu Ihrem Server mit dem Befehl aus:

Wenn Ihr Server bei­spiels­wei­se http://example.com, autet der Befehl:

Dadurch wird die KVM-Konsole geöffnet, mit der Sie auf Ihren Server zugreifen können, als ob Sie an einer phy­si­schen am Computer an­ge­schlos­se­nen Tastatur sitzen würden.

Wenn Sie den Server neu starten möchten, können Sie dies von der KVM-Konsole aus mit dem Befehl tun: