☰

Nach dem erfolgreichen Austausch von Schlüsseln zu Ubuntu aus einigen Netzwerken kann die SSH-Verbindung nicht hergestellt werden

tag-icon • tag-icon ssh
Nach dem erfolgreichen Austausch von Schlüsseln zu Ubuntu aus einigen Netzwerken kann die SSH-Verbindung nicht hergestellt werden

Nachdem ich von einem Land in ein anderes geflogen bin, kann ich jetzt keine SSH-Verbindung mehr zu mehreren meiner Digital Ocean Ubuntu-Server herstellen. Ich kann mich jedoch immer noch über die Konsole anmelden und per SSH von einer Box zur anderen wechseln (sie befinden sich alle im selben physischen Rechenzentrum).

Wenn Sie ssh mit -vvvv ausführen und damit den Zeitbefehl ausführen, lautet die letzte Debugmeldung:

debug2: channel 0: open confirm rwindow 0 rmax 32768
Write failed: Broken pipe

Die Zeit läuft nach 1 Minute und 37 Sekunden ab.

Hier ist das Debug-Protokoll ab dem Zeitpunkt, an dem die SSH-Schlüsselauthentifizierung erfolgreich war:

debug1: Authentication succeeded (publickey).
Authenticated to 128.199.170.168 ([128.199.170.168]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env PATH
debug3: Ignored env MARKPATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env XPC_FLAGS
debug3: Ignored env PS1
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env GREP_OPTIONS
debug3: Ignored env LOGNAME
debug3: Ignored env SCALA_HOME
debug3: Ignored env SECURITYSESSIONID
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
Write failed: Broken pipe

Die Verbindung ist nicht besonders langsam, meine Shell ist Bash (und ich kann mich immer noch über die Konsole und andere Netzwerk-SSHs anmelden). Nichts scheint die SSH-Verbindung zu blockieren, da ich sehe, dass eine Authentifizierung mit öffentlichem Schlüssel stattfindet.

Ich weiß nicht, welche Pipe, in die geschrieben wird, defekt ist. Meine Verbinung erfolgt über OSX, aber ich hatte bis zu meinem Flug in die USA keine Probleme.

Folgendes wird auth.logbeim Anmeldeversuch angezeigt:

May 17 12:28:01 db1 CRON[24931]: pam_unix(cron:session): session opened for user root by (uid=0)
May 17 12:28:01 db1 CRON[24931]: pam_unix(cron:session): session closed for user root
May 17 12:28:02 db1 sshd[24955]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
May 17 12:28:04 db1 sshd[24955]: Accepted publickey for tomo from 24.210.28.151 port 63202 ssh2: DSA 3a:[redacted]
May 17 12:28:04 db1 sshd[24955]: pam_unix(sshd:session): session opened for user tomo by (uid=0)

Tcpdump-Erfassung des Datenverkehrs von Port 22 während eines Verbindungsversuchs:

    $ sudo tcpdump -i en0 port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:00:40.917870 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [S], seq 3430788632, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1286503697 ecr 0,sackOK,eol], length 0
19:00:41.211348 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [S.], seq 4135716624, ack 3430788633, win 28960, options [mss 1460,sackOK,TS val 898678531 ecr 1286503697,nop,wscale 8], length 0
19:00:41.211415 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1, win 4117, options [nop,nop,TS val 1286503989 ecr 898678531], length 0
19:00:41.215051 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1:22, ack 1, win 4117, options [nop,nop,TS val 1286503992 ecr 898678531], length 21
19:00:41.484824 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 22, win 114, options [nop,nop,TS val 898678606 ecr 1286503992], length 0
19:00:41.488532 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1:42, ack 22, win 114, options [nop,nop,TS val 898678609 ecr 1286503992], length 41
19:00:41.488616 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 42, win 4116, options [nop,nop,TS val 1286504260 ecr 898678609], length 0
19:00:41.490182 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], seq 22:1470, ack 42, win 4116, options [nop,nop,TS val 1286504261 ecr 898678609], length 1448
19:00:41.490183 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1470:1614, ack 42, win 4116, options [nop,nop,TS val 1286504261 ecr 898678609], length 144
19:00:41.491254 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], seq 42:1490, ack 22, win 114, options [nop,nop,TS val 898678609 ecr 1286503992], length 1448
19:00:41.592287 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1490, win 4096, options [nop,nop,TS val 1286504362 ecr 898678609], length 0
19:00:41.760341 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1490:1674, ack 22, win 114, options [nop,nop,TS val 898678676 ecr 1286504260], length 184
19:00:41.760401 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1674, win 4090, options [nop,nop,TS val 1286504527 ecr 898678676], length 0
19:00:41.762375 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1614, win 136, options [nop,nop,TS val 898678676 ecr 1286504261], length 0
19:00:41.762409 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1614:1638, ack 1674, win 4096, options [nop,nop,TS val 1286504529 ecr 898678676], length 24
19:00:42.027042 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1674:1826, ack 1638, win 136, options [nop,nop,TS val 898678743 ecr 1286504529], length 152
19:00:42.027103 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1826, win 4091, options [nop,nop,TS val 1286504789 ecr 898678743], length 0
19:00:42.028104 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1638:1782, ack 1826, win 4096, options [nop,nop,TS val 1286504790 ecr 898678743], length 144
19:00:42.300304 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1826:2546, ack 1782, win 148, options [nop,nop,TS val 898678812 ecr 1286504790], length 720
19:00:42.300357 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2546, win 4073, options [nop,nop,TS val 1286505053 ecr 898678812], length 0
19:00:42.302441 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1782:1798, ack 2546, win 4096, options [nop,nop,TS val 1286505055 ecr 898678812], length 16
19:00:42.600776 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1798, win 148, options [nop,nop,TS val 898678888 ecr 1286505055], length 0
19:00:42.600843 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1798:1850, ack 2546, win 4096, options [nop,nop,TS val 1286505349 ecr 898678888], length 52
19:00:42.857852 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1850, win 148, options [nop,nop,TS val 898678952 ecr 1286505349], length 0
19:00:42.858552 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2546:2598, ack 1850, win 148, options [nop,nop,TS val 898678952 ecr 1286505349], length 52
19:00:42.858584 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2598, win 4094, options [nop,nop,TS val 1286505604 ecr 898678952], length 0
19:00:42.859131 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1850:1918, ack 2598, win 4096, options [nop,nop,TS val 1286505605 ecr 898678952], length 68
19:00:43.124310 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2598:2650, ack 1918, win 148, options [nop,nop,TS val 898679019 ecr 1286505605], length 52
19:00:43.124374 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2650, win 4094, options [nop,nop,TS val 1286505867 ecr 898679019], length 0
19:00:43.124473 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1918:2434, ack 2650, win 4096, options [nop,nop,TS val 1286505867 ecr 898679019], length 516
19:00:43.394690 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2650:2702, ack 2434, win 159, options [nop,nop,TS val 898679086 ecr 1286505867], length 52
19:00:43.394774 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2702, win 4094, options [nop,nop,TS val 1286506134 ecr 898679086], length 0
19:01:04.685580 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2434:2582, ack 2702, win 4096, options [nop,nop,TS val 1286527239 ecr 898679086], length 148
19:01:04.966270 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2702:2738, ack 2582, win 170, options [nop,nop,TS val 898684479 ecr 1286527239], length 36
19:01:04.966378 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2738, win 4094, options [nop,nop,TS val 1286527514 ecr 898684479], length 0
19:01:04.967018 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2582:2702, ack 2738, win 4096, options [nop,nop,TS val 1286527514 ecr 898684479], length 120
19:01:05.269214 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 2702, win 170, options [nop,nop,TS val 898684555 ecr 1286527514], length 0
19:01:06.027067 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2738:2790, ack 2702, win 170, options [nop,nop,TS val 898684744 ecr 1286527514], length 52
19:01:06.027144 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2790, win 4094, options [nop,nop,TS val 1286528563 ecr 898684744], length 0
19:01:06.027497 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286528563 ecr 898684744], length 460
19:01:06.603432 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286529135 ecr 898684744], length 460
19:01:07.552730 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286530077 ecr 898684744], length 460
19:01:09.250116 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286531762 ecr 898684744], length 460
19:01:12.442790 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286534930 ecr 898684744], length 460
19:01:18.634929 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286541067 ecr 898684744], length 460
19:01:24.068621 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286546451 ecr 898684744], length 460
19:01:34.714519 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286557019 ecr 898684744], length 460
19:01:45.384050 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286567587 ecr 898684744], length 460
19:01:56.051835 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286578155 ecr 898684744], length 460
19:02:06.715163 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286588723 ecr 898684744], length 460
19:02:17.355823 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286599291 ecr 898684744], length 460
19:02:28.042962 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286609859 ecr 898684744], length 460
19:02:38.690971 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [R.], seq 3162, ack 2790, win 4096, length 0

Einige andere Dinge, die ich versucht habe:

  • Reduzierung der MTU auf dem Server, möglicherweise ein Fehler in PMTU: sudo ip link set mtu 1280 dev eth0
  • Reduzierung der MTU auf 1280 in OS X für meine WLAN-Schnittstelle
  • Reduzierung des ServerAliveIntervals auf 30, wobei die Verbindung immer noch abläuft, aber keine unterbrochene Pipe vorhanden ist
  • Ausführen von SSH mit „cat“ statt „bash“ oder Bash, aber ohne geladenes Profil/RC
  • IP-Adresse der OS X-WLAN-Schnittstelle manuell einstellen statt über DHCP

Antwort1

In der Paketverfolgung sehen wir, dass zu Beginn des Flusses Pakete mit maximaler Größe in beide Richtungen ausgetauscht werden. Dies hat keine Probleme verursacht, es gibt also nichts, was auf ein MTU-Problem hindeutet.

Später während der Verbindung sehen wir, dass ein Paket vom Client an den Server mit den relativen Sequenznummern 2702:3162 niemals eine ACK vom Server erhält.

Mein erster Gedanke ist, dass dieser Paketverlust durch eine fehlerhafte Middlebox (also NAT, Firewall oder ähnliches) verursacht wird.

Ich habe von NAT-Boxen gehört, die mit TOS-Änderungen während einer TCP-Verbindung nicht umgehen können. Das Problem in Ihrem Fall tritt auf, nachdem der Client anzeigt, dass TOS geändert wurde. Da tcpdump die TOS jedoch nicht anzeigt, kann ich nicht mit Sicherheit sagen, ob das genau der Punkt ist, an dem das Problem auftritt.

Zu Testzwecken können Sie versuchen, -o ProxyCommand='nc %h %p'so zu verwenden, dass der SSH-Client die TCP-Verbindung nicht direkt steuert. Sie können auch die IPQoSOption ausprobieren. Wenn die Änderung der TOS das Problem ist, sollte die Angabe von -o IPQoS=cs0oder -o IPQoS=0funktionieren, aber jede andere Einstellung würde fehlschlagen. Dies liegt daran, dass SSH während der Authentifizierung 0 als QoS verwendet und dann nach der Authentifizierung zum gewählten QoS wechselt. Wenn Sie QoS auf 0 setzen, gibt es keine Änderung des QoS-Werts, die Middleboxes verwirren könnte.

Antwort2

Falls das noch jemandem auffällt: Ich hatte ein ähnliches Problem mit einem TP-Link Archer VR2600-Router/Modem (mit Firmware 1.4.0 0.8.0 v0050.0 Build 160518 Rel.50944n).

Die Ausführung mit -o IPQoS=0, wie von @kasperd vorgeschlagen, funktionierte, was auf eine Art QoS-Problem mit meinem Router hindeutet. Ich habe das Nächstliegende aktiviert, was ich in den Routereinstellungen finden konnte (Fortschrittlich→BandbreitenkontrolleIch stelle die maximale Bandbreite knapp unter die auf meiner Leitung verfügbare Bandbreite ein) in der Annahme, dass der Router in diesem Fall möglicherweise beginnt, auf die relevanten Flags zu achten.

Dies scheint zu funktionieren und meine Verbindungen kommen jetzt durch. Durch Umschalten dieser Option kann ich zuverlässig steuern, ob ich durchkomme.

Antwort3

Haben Sie eine Benutzer-SSH-Konfiguration (~/.ssh/config)?

Wenn nicht, erstellen Sie eins und versuchen Sie, die folgenden Zeilen hinzuzufügen:

ServerAliveInterval 120 #ping the server every 120s
TCPKeepAlive no #do not set SO_KEEPALIVE on socket

Antwort4

Leider habe ich hier nicht genug Ansehen, um Sam Masons Antwort oben zu bewerten oder zu kommentieren, aber ich würde ihm gerne öffentlich +1 geben. Ich habe auch einen VR2600 und habe die gleiche Erfahrung gemacht:

  1. Die Verbindung (SSH, SFTP usw.) wird hergestellt, bleibt dann aber hängen
  2. tshark zeigt TCP Spurious Retransmits
  3. Die Einstellung -o IPQoS=0 (allein) auf der Clientseite hat nichts bewirkt
  4. AktivierenDie Einstellung Erweitert->Bandbreitenkontrolle am Router (zuvor deaktiviert) mit den höchstmöglichen Grenzwerten (= praktisch unbegrenzt) scheint den Router so zu reparieren, dass er auf das IPQoS-Flag achtet
  5. Tshark zeigt keine TCP Spurious Retransmits mehr an und die Verbindung hängt nicht mehr (SSH-, SFTP- usw.-Clients funktionieren jetzt mit einem Server hinter dem VR2600-Router).

Dies scheint auf einen erheblichen Fehler im VR2600-Router hinzudeuten. Leider verwende ich (zum Zeitpunkt des Schreibens) die neueste Firmware (1.4.0 0.8.0 v0050.0 Build 160518 Rel.50944n, dieselbe wie Sam), und dieser Router scheint nicht mit DD-WRT kompatibel zu sein bzw. nicht damit getestet worden zu sein.

JEDOCH möchte ich zu dem oben Besprochenen noch Folgendes sagen:

  1. Nachdem ich die Schritte 1 bis 5 ausgeführt habe, kann ich jetzt erfolgreich eine Verbindung herstellen, auch ohne "-o IPQoS=0" anzugeben.

Mit anderen Worten:

Das bloße Aktivieren der Option „Erweitert->Bandbreitenkontrolle“ in den Router-Optionen (selbst mit einer maximal hohen Obergrenze) scheint auszureichen, damit sich dieser Router-NAT wie erwartet verhält. Wenn die Bandbreitenkontrolle deaktiviert ist, tritt das im OP (und ausführlich von @malasa) beschriebene Problem auf.

Unklar, ob die Lösung darin besteht, diese Option einfach zu aktivieren, oder ob Sie sich auch mindestens einmal mit der Option -o verbunden haben müssen. Auf jeden Fall kann ich bestätigen, dass ich nach dem Aktivieren dieser Optiondeaktivierendiese Option Erweitert->Bandbreitenkontrolle, dann sind meine ssh/sftp/usw. wie zuvor kaputt. Wenn ichaktivierendiese Option „Erweitert->Bandbreitenkontrolle“ scheint alles wieder wie erwartet zu funktionieren. Und (nachdem diese Option aktiviert wurde) scheint auch bei Router-Neustarts alles einwandfrei zu funktionieren.

Aus meiner Sicht ist es also ein ziemlich guter Workaround/Fix, der keine Änderungen oder Wartung auf der Clientseite erfordert (um die Bedenken von @leonardoborges zu beantworten).

verwandte Informationen