SSH-Server funktioniert nicht (Respawns bis zum Stoppen)

Ich habe einen laufenden Ubuntu Server 10.04.1. Als ich versuchte, mich über ssh am Server anzumelden, konnte ich nicht. Stattdessen habe ich connection refusedFehler bekommen. Ich habe versucht, die Maschine anzupingen und bekam eine Antwort! Der eindeutige Grund dafür ist, dass der SSH-Daemon gestoppt ist.

Nach dem Neustart konnte ich mich über ssh auf meinem Server anmelden. Nach einiger Zeit sah ich in meinen Protokollen nach /var/log/syslogund fand die folgenden Aufzeichnungen:

Jan 16 10:57:09 myserver init: ssh main process ended, respawning
Jan 16 10:57:09 myserver init: ssh main process (2465) terminated with status 255
Jan 16 10:57:09 myserver init: ssh main process ended, respawning
Jan 16 10:57:09 myserver init: ssh main process (2469) terminated with status 255
Jan 16 10:57:09 myserver init: ssh main process ended, respawning
Jan 16 10:57:09 myserver init: ssh main process (2473) terminated with status 255
Jan 16 10:57:09 myserver init: ssh main process ended, respawning
Jan 16 10:57:09 myserver init: ssh main process (2477) terminated with status 255
Jan 16 10:57:09 myserver init: ssh main process ended, respawning
Jan 16 10:57:09 myserver init: ssh main process (2481) terminated with status 255
Jan 16 10:57:09 myserver init: ssh main process ended, respawning
Jan 16 10:57:09 myserver init: ssh main process (2485) terminated with status 255
Jan 16 10:57:09 myserver init: ssh main process ended, respawning
Jan 16 10:57:09 myserver init: ssh main process (2489) terminated with status 255
Jan 16 10:57:09 myserver init: ssh main process ended, respawning
Jan 16 10:57:09 myserver init: ssh main process (2493) terminated with status 255
Jan 16 10:57:09 myserver init: ssh main process ended, respawning
Jan 16 10:57:09 myserver init: ssh main process (2497) terminated with status 255
Jan 16 10:57:09 myserver init: ssh main process ended, respawning
Jan 16 10:57:09 myserver init: ssh main process (2501) terminated with status 255
Jan 16 10:57:09 myserver init: ssh respawning too fast, stopped

Ich habe nach einem ähnlichen Problem / einer ähnlichen Lösung gesucht. Einige Leute sagten , dass dies durch die SSH - Daemon verursacht wird versucht , bevor zu starten Vernetzung und schlagen sie vor , Änderungen ListenAddressin /etc/ssh/sshd_configsein 0.0.0.0. Ich denke, dies ist nicht die Ursache in meinem Fall, da mein Problem auftritt, nachdem das System betriebsbereit ist.

Irgendeine Idee, was das verursacht? Dies ist Ubuntu Server, und es sollte ausgeführt werden und über SSH remote zugegriffen werden können.

AKTUALISIEREN:

Hier ist das Log-Snippet, das ich gefunden habe /var/log/auth.log.

Jan 16 10:56:38 myserver sudo:     user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/vim /etc/ssh/sshd_config
Jan 16 10:57:09 myserver sudo:     user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/etc/init.d/ssh reload
Jan 16 10:57:09 myserver sshd[1465]: Received SIGHUP; restarting.
Jan 16 10:57:09 myserver sshd[2461]: Server listening on 0.0.0.0 port 22.
Jan 16 10:57:09 myserver sshd[2465]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Jan 16 10:57:09 myserver sshd[2465]: fatal: Cannot bind any address.
Jan 16 10:57:09 myserver sshd[2469]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Jan 16 10:57:09 myserver sshd[2469]: fatal: Cannot bind any address.
Jan 16 10:57:09 myserver sshd[2473]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Jan 16 10:57:09 myserver sshd[2473]: fatal: Cannot bind any address.
Jan 16 10:57:09 myserver sshd[2477]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Jan 16 10:57:09 myserver sshd[2477]: fatal: Cannot bind any address.
Jan 16 10:57:09 myserver sshd[2481]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Jan 16 10:57:09 myserver sshd[2481]: fatal: Cannot bind any address.
Jan 16 10:57:09 myserver sshd[2485]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Jan 16 10:57:09 myserver sshd[2485]: fatal: Cannot bind any address.
Jan 16 10:57:09 myserver sshd[2489]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Jan 16 10:57:09 myserver sshd[2489]: fatal: Cannot bind any address.
Jan 16 10:57:09 myserver sshd[2493]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Jan 16 10:57:09 myserver sshd[2493]: fatal: Cannot bind any address.
Jan 16 10:57:09 myserver sshd[2497]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Jan 16 10:57:09 myserver sshd[2497]: fatal: Cannot bind any address.
Jan 16 10:57:09 myserver sshd[2501]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Jan 16 10:57:09 myserver sshd[2501]: fatal: Cannot bind any address.

Es scheint, dass dieser Fehler auftrat, nachdem ich den SSH-Daemon neu geladen hatte. Sollte ich vermeiden, stattdessen zu verwenden ssh reloadund zu verwenden ssh restart?

Sie sollten nachsehen, was passiert ist, kurz bevor SSH ins Wanken gerät syslog. Wenn das Netzwerk-Subsystem ausfällt, kann dies erklären, warum der sshdFehler aufgetreten ist.

Ich würde es auch überprüfen /var/log/auth.log. Es ist sshddas Protokoll und es könnte eine bessere Fehlermeldung geben.

Ich hatte gerade das gleiche Problem an meiner 12.04 Box. Dh die gleichen Symptome. Leider passierte es immer, wenn ich die ListenAddressKlausel mit den inetund inet6-Adressen in einführte sshd_config. Kurz gesagt, dies scheint ein Symptom für eine fehlerhafte Form zu sein sshd_config- obwohl die Protokolldateien so etwas nicht aussagten.

Fehlerbehebung sshd

Was ich in solchen Fällen im Allgemeinen sehr nützlich finde, ist zu beginnen, sshdohne es dämonisieren zu lassen. Das Problem in meinem Fall war, dass weder etwas Sinnvolles gezeigt syslognoch auth.loggezeigt wurde.

Als ich es vom Terminal aus startete, bekam ich:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Viel besser! Mit dieser Fehlermeldung konnte ich sehen, was falsch ist, und es beheben. Keine der Protokolldateien enthielt diese Ausgabe.

Hinweis: Zumindest unter Ubuntu $(which sshd)ist dies die beste Methode, um die sshdAnforderung eines absoluten Pfades zu erfüllen . Andernfalls werden Sie die folgende Fehlermeldung erhalten: sshd re-exec requires execution with an absolute path. Die -p 10222Marken sshdhören an diesem alternativ Port, die Konfigurationsdatei überschreiben - dies ist so , dass es nicht mit potenziell laufen kollidiert sshdInstanzen. Stellen Sie sicher, dass Sie hier einen freien Port auswählen.

Diese Methode hat mir schon oft bei der Suche nach Problemen geholfen, sei es bei der Authentifizierung oder bei anderen Problemen. Um eine wirklich ausführliche Ausgabe zu erhalten stdout, verwenden Sie $(which sshd) -Ddddp 10222(beachten Sie den Zusatz dd, um die Ausführlichkeit zu erhöhen). Weitere Informationen zur Fehlerbehebung finden Sie unter Güteprüfung man sshd.

Der Hauptvorteil dieser Methode besteht darin, dass Sie die sshdKonfiguration überprüfen können , ohnesshd den Standardport neu starten zu müssen. Normalerweise sollte dies nicht die bestehenden SSH-Verbindungen stören, aber ich habe es gesehen. Auf diese Weise kann die Konfigurationsdatei überprüft werden, bevor - möglicherweise - der Zugriff auf einen Remoteserver gesperrt wird (z. B. bei einigen VPS und sogar bei physischen Servern, bei denen ich zusätzliche Gebühren für den Out-of-Band-Zugriff entrichten muss) zur Maschine).

Dies scheint das Ergebnis des Fehlers # 687535 zu sein, der kürzlich in natty behoben wurde und als vorgeschlagenes Update sowohl auf maverick als auch auf lucid hochgeladen wurde.

https://bugs.launchpad.net/ubuntu/lucid/+source/openssh/+bug/687535

Ich möchte alle dazu ermutigen, dorthin zu gehen, den Testfall auszuprobieren (nach TESTFALL suchen) und Ihre Ergebnisse vor und nach der Installation des vorgeschlagenen Fixes zu veröffentlichen. Dies hilft dem SRU-Team bei der Entscheidung, ob die Überprüfung durchgeführt wurde, und gibt sie als Update frei.

In /etc/ssh/sshd_config, stellen Sie sicher , dass alle Ja und keine Optionen in Kleinbuchstaben sind. Wenn Sie beispielsweise festlegen, PermitRootLogin Nowird ssh nicht gestartet. Es muss tatsächlich so sein PermitRootLogin no.

Ich hatte nach dem Neustart ein ähnliches Problem mit einem Ubuntu 11.10-Image auf einem Linode. SSH-Dienst würde in Syslog produzieren:

Mar 18 06:31:33 servername kernel: init: ssh main process ended, respawning
Mar 18 06:31:33 servername kernel: init: ssh main process (3419) terminated with status 255
Mar 18 06:31:33 servername kernel: init: ssh main process ended, respawning
Mar 18 06:31:33 servername kernel: init: ssh main process (3422) terminated with status 255
Mar 18 06:31:33 servername kernel: init: ssh respawning too fast, stopped

Es handelt sich um eine Testbox mit einer Betriebszeit von ca. 60 Tagen. Auf diesem Weg habe ich also irgendwo etwas installiert, das am Ende von sshd_config angehängt ist:

ClientAliveInterval 60
ClientCountAliveMax 60

Durch das Kommentieren dieser Zeilen konnte ssh beginnen.

Ubuntu ssh konnte nicht gestartet werden und Syslog lieferte "init: ssh main process (2044) terminated with status 255"

/ usr / sbin / sshd -Ddp 10222

Sicher hat bei mir gearbeitet, um den Zeilenfehler sshd_config zu ermitteln

habe das gleiche Problem, obere Lösung funktioniert nicht, aber ich habe eine Lösung dafür.

root@imt:~# sshd
sshd re-exec requires execution with an absolute path
ssh localhost
ssh: connect to host localhost port 22: Network is unreachable

Der Pfad ist gemäß Dokument in Ordnung, daher führe ich sshd manuell aus.

root@imt:~# /usr/sbin/sshd 
/var/run/sshd must be owned by root and not group or world-writable

Die Berechtigung / var / run / sshd lautet.

root@imt:~# ls -ld /var/run/sshd
drwsrwsrwt 2 root root 40 Jan  5 12:58 /var/run/sshd

root@imt:~# chmod 755 /var/run/sshd

dann ist es in Ordnung. starte ssh localhost und überprüfe.

root@imt:~# ssh localhost 
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 64:93:fd:ab:4c:f9:7b:8a:86:60:22:f7:56:fa:ea:cc.
Are you sure you want to continue connecting (yes/no)? yes