it-swarm.com.de

Was verursacht SSH-Probleme nach dem Neustart eines 14.04-Servers?

Warum erhalte ich beim Neustart eines Servers mit Ubuntu 14.04 die Fehlermeldung "Verbindung abgelehnt"?

Ich sehe ssh: connect to Host <IP-address-here> port 22: Connection refused aber nur für 14.04 und erst nach einem Neustart. Ich verwende 12.04 Desktop zu Hause. Wie behebe ich das?


Um die Frage klarer zu machen, hier ist, was für mich funktioniert oder nicht:

  • SSH in eine Neuinstallation von 12.04> ausloggen> SSH wieder einspielen> funktioniert
  • SSH in eine Neuinstallation von 12.04> Neustart> SSH erneut einspielen> funktioniert
  • SSH in eine Neuinstallation von 14.04> ausloggen> SSH wieder einspielen> funktioniert
  • SSH in eine Neuinstallation von 14.04> Neustart> SSH erneut einspielen> Verbindung abgelehnt

Das Problem tritt nur bei 14.04 auf und tritt erst nach einem Neustart auf. Ich habe mehrere Server, auf denen vorher 12.04 ausgeführt wurde, und alles funktioniert noch einwandfrei. Ich habe einen neuen Server, auf dem ich 14.04 verwenden möchte, und ich möchte verstehen, was falsch läuft. Irgendwelche Vorschläge?


Folgendes habe ich bisher versucht:

Sudo traceroute -p 22 -T <IP-address-here>

Traceroute funktioniert einwandfrei. Ich erhalte eine Antwort vom Server auf SSH-Port 22.

initctl list
...
ssh start/running, process 23371
...

Sieht so aus, als ob ssh auf dem 14.04-Server so eingestellt ist, dass es beim Booten startet (wie erwartet).

[email protected]:~$ ssh -vvv [email protected]<IP-address-here>
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to <IP-address-here> [<IP-address-here>] port 22.
debug1: connect to address <IP-address-here> port 22: Connection refused
ssh: connect to Host <IP-address-here> port 22: Connection refused

Edit: Hier ist das gesamtes Syslog von einem neu erstellten Rechner . Ich habe es erstellt, in SSH eingegeben und den Befehl reboot now ausgegeben. Nachdem ich darauf gewartet habe, dass es neu gestartet wird und beim zweiten Mal versucht hat, SSH zu starten, wurde ein Verbindungsfehler zurückgewiesen. Fester Neustart über das Hosting Control Panel und jetzt funktioniert die SSH-Verbindung wieder.

15
Tom Brossman

Schnelle Antwort:

SSH ist nicht das Problem. Der Befehl, den Sie zum Neustarten verwenden, ist das Problem: Führen Sie reboot now, reboot oder shutdown -r now nicht aus, um Ihr System neu zu starten.

Die Befehlssyntax ( seit 13.04 ) lautete:

reboot [OPTION]...  [REBOOTCOMMAND]

Das REBOOTCOMMAND existierte noch nie. In 12.04 wurde Ihr now einfach ignoriert, aber jetzt wird es verwendet ... und es zerstört alles.

Lange Antwort mit meinen Testergebnissen und Erklärung:

Ich habe ein ähnliches Problem mit einigen Servern, auf denen 14.04 AND in VPS ausgeführt wird (gehostet beim französischen OVH-Anbieter - OpenVZ) UND wenn reboot now auf dem Server selbst ausgeführt wird.

Wie Sie habe ich den Befehl reboot now über die Konsole ausgegeben (mit SSH angemeldet). Ein paar Sekunden nachdem ich gedrückt hatte RETURNwird meine Sitzung automatisch getrennt. Wie Sie konnte ich nach der Ausgabe dieses Befehls noch nie wieder über SSH eine Verbindung zum Server herstellen.

Also habe ich beschlossen, die von OVH bereitgestellte Konsole KVM zu öffnen. (Emulieren des direkten Zugriffs über Tastatur und Bildschirm auf einem physischen Server für diese Art von virtuellem Server).

Ich konnte eine Verbindung zu meinem Computer herstellen und sah, dass sie in den Einzelbenutzermodus wechselt und darauf wartet, dass ich drücke CTRL+D um fortzufahren oder das root-Passwort einzugeben, um in den Wartungsmodus zu wechseln. Ich drückte die Tastenkombination, um den Vorgang fortzusetzen, und konnte dann erneut SSH auf meinem System ausführen. Was war meine Überraschung zu sehen, nachdem ich uptime ausgeführt habe, dass die Betriebszeit nicht 2 oder 3 Minuten, sondern dennoch viel Zeit in Anspruch nahm: reboot now, das in einem Ubuntu 14.04 VPS ausgeführt wird, startet nicht wirklich neu, sondern fragt nur in den Single User Modus wechseln!

Aus diesem Grund habe ich gelernt, in meinem VPS niemals einen Neustart anzufordern, sondern ihn über den Befehl anzufordern, der auf der Verwaltungsoberfläche des Hosters bereitgestellt wird.

Somit gibt es kein Problem mit Ihrer SSH-Installation. Das Problem ist, wenn Sie reboot now eingeben. Tatsächlich habe ich es später auch getestet, wenn Sie reboot (nur das Wort, keine Option) eingegeben hätten, hätte es getan, was Sie vorhatten: den Server neu zu starten.

Wenn Sie reboot mit einem Argument (aus der Manpage) verwenden, rufen Sie den Befehl shutdown mit den angegebenen Argumenten auf. Und tatsächlich, wenn ich shutdown now ausführe, habe ich das gleiche Verhalten: Das System wird nicht neu gestartet, sondern wechselt in den Einzelbenutzermodus.

Bemerkung: Es sieht so aus, als ob dies das beabsichtigte Verhalten ist, da die Meldung, die auf dem Bildschirm erscheint, nachdem Sie diesen Befehl ausgeführt haben, ungefähr so ​​aussagt:

Das System wird in den Wartungsmodus versetzt

Wartungsmodus oder Einzelbenutzermodus, dies ist dasselbe, ein Runlevel mit mehr als einer Shell, keinem Netzwerk, keinen Netzwerkprozessen, ...

Dies kann verwirrend sein, aber beachten Sie, dass die korrekte Verwendung von shutdown zum Beispiel lautet: shutdown -h now, um das System jetzt anzuhalten, oder shutdown -r now, um es jetzt neu zu starten. Mir war nicht bewusst, dass shutdown now das System nur in den Einzelbenutzermodus versetzen würde. Normalerweise mache ich init S, um das zu erreichen.

17
Benoit

Eine weitere mögliche Ursache ist der Verlust der SSH-Portregelkonfiguration durch ufw. Dies ist mir mindestens ein oder zwei Mal aufgefallen, als die Firewall-Konfiguration nach dem Anwenden von Updates und dem Neustart den Zugriff auf den Server blockierte. Durch die Verwendung der VPS-Konsolenfunktion meines Hosting-Providers konnte ich auf den Computer zugreifen und das Problem diagnostizieren. Das folgende Beispiel zeigt das Problem (dh kein Eintrag für Port 22):

[email protected]:~$ Sudo ufw status verbose
[Sudo] password for user:
Status: active
Logging: on (low)
    Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80,443/tcp (Nginx Full)    ALLOW IN    Anywhere
25/tcp                     ALLOW IN    Anywhere
143                        ALLOW IN    Anywhere
110                        ALLOW IN    Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN    Anywhere
995/tcp (Dovecot Secure POP3) ALLOW IN    Anywhere
25/tcp (Postfix)           ALLOW IN    Anywhere
465/tcp (Postfix SMTPS)    ALLOW IN    Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN    Anywhere (v6)
25/tcp (v6)                ALLOW IN    Anywhere (v6)
143 (v6)                   ALLOW IN    Anywhere (v6)
110 (v6)                   ALLOW IN    Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN    Anywhere (v6)
995/tcp (Dovecot Secure POP3 (v6)) ALLOW IN    Anywhere (v6)
25/tcp (Postfix (v6))      ALLOW IN    Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN    Anywhere (v6)

Um den Port wieder zu aktivieren, gehen Sie wie folgt vor:

[email protected]:~$ Sudo ufw allow ssh
Rule added
Rule added (v6)
2
John Rix

Ich komme vielleicht zu spät, und es mag offensichtlich sein, aber für mich hat es funktioniert, die Konfigurationsdatei /etc/ssh/sshd_config zu überprüfen: Das Ausführen des Dämons mit /etc/init.d/ssh start oder einer anderen Kombination hat gezeigt, dass der Dienst ausgeführt wurde, obwohl er ausgeführt wurde war nicht, aber wenn ich die ausführbare Datei mit ihrem absoluten Pfad starte (in meinem Fall /usr/sbin/sshd), sah ich, dass am Ende der Konfigurationsdatei ein "0B" angehängt wurde, das beim Starten einen Fehler verursachte und es löste das Problem.

2
tama