Ubuntu 18.04 SSH VPS wird ständig getrennt

771
MattR

Ich habe ein Virpus VPS, auf dem Ubuntu 18.04 läuft. Seit ich es vor ein paar Wochen bekam, hatte ich Probleme, über SSH verbunden zu bleiben. Ich bin in der Lage, eine Verbindung herzustellen, aber die Verbindung wird scheinbar zufällig getrennt (in unterschiedlichen Intervallen). Nachdem ich die Verbindung getrennt habe, muss ich normalerweise eine Minute warten, bis ich wieder da bin. Ich habe den Bildschirm verwendet, um die Bildschirmsitzung aufrechtzuerhalten, und wenn ich einmal angekommen bin, kann ich mich ohne Probleme wieder mit dem Bildschirm verbinden.

Ich habe es in drei verschiedenen Netzwerken auf drei verschiedenen Computern getestet, zwei mit Windows 10 und einem mit CentOS. Unter Windows habe ich versucht, PuTTY, WinSCP, eine Python-SSH-Bibliothek namens paramiko und Git Bash für Windows zu verwenden. Bei CentOS habe ich gerade den CLI-Befehl ssh verwendet. Alle mit den gleichen Ergebnissen. Ich habe SSH-ing in verschiedenen Benutzerkonten ausprobiert, aber das Problem bleibt bestehen. Ich habe es sogar mit ConnectBot auf meinem Handy (Android 6) versucht. Kein Glück.

PuTTY sagt: "Netzwerkfehler: Software hat Verbindungsabbruch verursacht"

CentOS CLI sagt: packet_write_wait: Connection to 198.167.140.11 port 22: Broken pipe

Ich habe versucht, Keepalives in PuTTY einzustellen, aber das hat keine Auswirkungen. Sobald ich die Verbindung verliere, kann ich den Server nicht einmal von einem anderen Host aus pingen. IE, wenn ich SSH-ing in den Server von Maschine A bin, dann werde ich getrennt, dann gehe ich sofort zu Maschine B und versuche, den Server zu pingen, ich erhalte keine Antwort. Das scheint mir die Schuld des Servers zu sein. Wenn ich die Verbindung jedoch manuell (sauber) trenne, kann ich es pingen.

Das Virpus-Supportteam gibt an, dass meine SSH-Einstellungen in Ordnung sind und dass sie in der Lage waren, eine Verbindung (auf einer Linux-Box) mindestens eine Stunde lang problemlos aufrechtzuerhalten. Danach wurde die Verbindung manuell getrennt. Mit anderen Worten, sie können das Problem nicht replizieren.

Bei dem Versuch, das Problem zu lösen, wurde die öffentliche IP des Servers geändert, was jedoch nicht behoben wurde. Ihr nächster Schritt war die Umstellung auf einen anderen Knoten, der ein wenig zu funktionieren schien, aber jetzt habe ich immer noch das gleiche Problem. Sie sagten mir, alles was sie jetzt tun könnten, war auf einen anderen Knoten umzusteigen. Da sie das schon getan haben, denke ich, dass das nichts reparieren wird.

Hat jemand einen Vorschlag? Ich kann alle Konfigurationsinformationen posten, nach denen Sie fragen, ich weiß nur nicht, was ich posten soll.

UPDATE :

Wie angefordert, hier ist die Ausgabe von ufw status:

Status: active  To Action From -- ------ ---- 22/tcp ALLOW Anywhere 22 ALLOW Anywhere 80/tcp ALLOW Anywhere 443/tcp ALLOW Anywhere 443 ALLOW Anywhere 80 ALLOW Anywhere 80,443/tcp ALLOW Anywhere 22/tcp (v6) ALLOW Anywhere (v6) 22 (v6) ALLOW Anywhere (v6) 80/tcp (v6) ALLOW Anywhere (v6) 443/tcp (v6) ALLOW Anywhere (v6) 443 (v6) ALLOW Anywhere (v6) 80 (v6) ALLOW Anywhere (v6) 80,443/tcp (v6) ALLOW Anywhere (v6) 

Und als gutes Maß ist hier die Ausgabe von iptables -L: https://pastebin.com/GdScv2rv

AKTUALISIEREN:

Ich habe die Datei auth.log durchgesehen und festgestellt, dass ich die folgenden Meldungen ständig nacheinander habe:

Nov 10 03:47:04 <hostname> sshd[17618]: Failed password for root from <ip_address> port 44738 ssh2 Nov 10 03:47:05 <hostname> sshd[17618]: Received disconnect from <ip_address> port 44738:11: [preauth] 

Dies ist, während ich als ein anderer Benutzer (nicht root) ssh'd bin, aber Sudo-Befehle ausführt. Das <ip_address>stimmt nicht mit meinem Host oder dem Remote-Server überein.

Es scheint auch, dass jemand versucht, mich brutal zu erzwingen, weil ich eine Reihe von Nachrichten in einer Reihe wie diese bekomme:

Nov 12 12:21:12 <hostname> sshd[20367]: Invalid user demo from <ip_address> port 49709 Nov 12 12:21:15 <hostname> sshd[20367]: pam_unix(sshd:auth): check pass; user unknown Nov 12 12:21:15 <hostname>sshd[20367]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<ip_address> Nov 12 12:21:17 <hostname> sshd[20367]: Failed password for invalid user demo from 193.105.134.97 port 49709 ssh2 Nov 12 12:21:17 <hostname> sshd[20367]: Disconnecting invalid user demo <ip_address> port 49709: Change of username or service not allowed: (demo,ssh-connection) -> (root,ssh-connection) [preauth] 

Es gibt ungefähr 1500 und alle verwenden unterschiedliche Benutzernamen. Ich habe die IP-Adressen in blockiert ufw.

Es gibt auch eine Reihe von Failed password for root fromIP-Adressen, die mit keiner meiner Adressen übereinstimmen.

1
Firewalling fällt in den Sinn; Was sind Ihre SSAL-Keepalive-Einstellungen? Machen Sie aktiv Sachen, während Sie getrennt werden? Diese "anderen Netzwerke", mit denen Sie getestet haben - was macht diese "anders"? tink vor 5 Jahren 0
In PuTTY ist "Sekunden zwischen Keepalives" auf 3000 eingestellt. Ich wurde vor 10 Sekunden getrennt. "TCP-Keepalives aktivieren" wird markiert, "Nagle-Algorithmus deaktivieren" wird markiert. Ja, es scheint tatsächlich öfter zu passieren, wenn ich aktiv Sachen mache. Ein Netzwerk ist mein Heimnetzwerk hinter einem Router, der sich hinter einem Modem befindet (auf Anfrage kann ich weitere Details angeben). Ein anderes ist mein Netzwerk bei der Arbeit, das auf einer Domäne ist. Ich habe nicht viele Details zu dieser. Der dritte befindet sich (vermutlich) in einem Rechenzentrum, da er mein Webhost-Anbieter ist. Als ich mein Telefon benutzt habe, habe ich Wifi ausgeschaltet. MattR vor 5 Jahren 0
Möglicherweise ein Firewall-Problem. können Sie die Ausgabe von "ufw status" zu Ihrer Frage hinzufügen (wenn Ihr Server UFW verwendet, aber AFAIK ist dies auf Ubuntu-Servern Standard) (ansonsten "iptables -L"). Ich hatte ein ähnliches Problem, bei dem die FW-Regeln nur 5 Verbindungen pro Minute von einer bestimmten IP-Adresse zulassen und ein Skript von mir (auf meinem PC) mehr versuchen würde. Diese Art der Regel sollte jedoch keine bestehende Terminalsitzung trennen. xenoid vor 5 Jahren 0
@xenoid Ich habe der Frage die Ausgabe dieser Befehle hinzugefügt. MattR vor 5 Jahren 0
OK, also kein Firewall-Problem. Alles in den SSH-Protokollen (/var/log/auth.log)? xenoid vor 5 Jahren 0
Es gibt eine Tonne. Worauf muss ich achten? Oder soll ich es auf Google Drive hochladen und hier verlinken? MattR vor 5 Jahren 0
@xenoid Ich habe ein paar Infos aus auth.log hinzugefügt. Lass mich wissen was du denkst. MattR vor 5 Jahren 0
Böse Leute, die versuchen, einzusteigen, sind hier irrelevant (aber wenn Ihr System nicht fail2ban ausführt, sollten Sie es in Betracht ziehen, um es in Schach zu halten ...). Nach was Sie suchen sollten, sind Nachrichten, die Ihre IP oder ID zum Zeitpunkt der Verbindungsabbruch angeben. xenoid vor 5 Jahren 0
Vielleicht hast du recht. Ich habe fail2ban installiert und auch ein paar mehr gemacht, um SSH zu sichern, und es scheint, als hätte es Auswirkungen gehabt. Ich bin seit 11 Stunden verbunden und habe gezählt. MattR vor 5 Jahren 0

0 Antworten auf die Frage