ssh Verhalten

[The Hit-Man]

Ich habe 2 VPN Server mit denen ich mich immer verbinde. Mal den, mal den ... Dann habe ich einen virtuellen Rechner im Netz stehen, mit ich mich per ssh und auch per sshfs verbinde. Nutze ich den ersten VPN Server, kann ich mich ohne weiteres per ssh auf meinem virtuellen Server im Netz verbinden. Nutze ich aber den zweiten VPN Server, muß ich mich mit der ssh Option

Code: Alles auswählen

KexAlgorithms=ecdh-sha2-nistp521

verbinden. An sonsten komme ich nicht drauf. Ich bin da drauf gekommen, als ich den ssh client mit den debug Optionen ( -vvv ), gestartet habe. Meine Frage ist jetzt, an was das liegt. An meinem virtuellen Server oder an meinem zweiten VPN Provider. Die VPN Protokolle sind wireguard und natürlich nutze ich nur den einen ODER den anderen. Des weiteren nutze ich X2go für meine Desktop Sessions auf dem virtuellen Server. Bei dem ersten VPN Provider komme ich drauf, bei dem zweiten VPN Provider wiederum nicht. Ich fand auch niergends eine Option um dem X2go Client, diese Option mit zu geben oder wird diese Option aus der .ssh/config gelesen? Denn wie es ausschaut, schaut der X2go Client da nicht nach.

[heisenberg]

Das liegt vermutlich daran, dass die sich SSH-Server und -Client nicht auf einen Kex-Exchange-Algorithmus einigen können, bzw. dass der Client vielleicht deutlich neuer ist als der Server und der Client gewisse alte Algorithmen - weil diese alt und mittlerweile als nicht mehr (ganz so) sicher gelten - abgeschaltet hat, die Du per SSH-Option wieder aktivieren musst.

Das hat jetzt nix mit dem VPN zu tun, sondern nur mit den beiden SSH-Komponenten (Client+Server).

Und ja: SSH-Optionen werden grundsätzlich auch aus $HOME/.ssh/config gelesen.

[The Hit-Man]

Das hat jetzt nix mit dem VPN zu tun, sondern nur mit den beiden SSH-Komponenten (Client+Server).

Der virtuelle Server ist ein Ubuntu 22.04.3 LTS ( halte den immer auf den neusten Stand). Der Client ist ein Debian 12. Ich verstehe immer noch nicht, wieso es bei dem ersten VPN ohne diese Option geht und beim zweiten VPN, muß die Option dabei sein. Ich meine der SSH Server Version ändert sich ja nicht. Nur die VPN Tunnel ändern sich.

[heisenberg]

Nochmal: Das ist ein Abstimmungsproblem zwischen SSH-Server und SSH-Client. Das einzige, was da in Bezug auf VPN einen Unterschied macht ist die IP-Adresse, mit der man ankommt. Sobald eine Socketverbindung zwischen Client und Server aufgebaut ist, hat das VPN da nix mehr mit zu tun.

Das Problem wird vermutlich dadurch gelöst, dass Du - wie Du es bereits jetzt tust - dem Client manuell den Key-Exchange-Algorithmus konfigurierst, oder das auf der anderen Seite am Server änderst. Mir ist das Verhalten auch seit Debian 12 aufgefallen. Dann habe ich halt entsprechende Veränderung an meiner $HOME/.ssh/config - Datei vorgenommen und gut.

Von X2Go habe ich keine Ahnung.

[The Hit-Man]

@heisenberg:
Also ich fand im Netz etwas, das ich für das 2te VPN mal den MTU Wert ändern sollte und schon hatte ich keine Probleme mehr. Ich sollte den auf 1280 stellen. Bin jetzt nicht der Netzwerk-Freak ... Weiß jemand was das genau bedeutet?

EDIT: Dann konnte ich auch die besagte Option wieder raus nehmen ... Jetzt frage ich mich allerdings ... WARUM?

[heisenberg]

Ich bin da auch nicht zu 100% sattelfest, aber ich würde folgendes sagen:

Die MTU ist die maximale Größe, die ein Netzwerkdatenpaket haben darf. Da VPN eine Methode ist, bei der vorhandene Pakete in Verschlüsselung eingepackt werden, werden diese Pakete größer - durch den Overhead der Verschlüsselung eben. D. h. die Pakete können die vorhandene MTU überschreiten und werden dann wieder geteilt (Fragmentierung), um noch über das Netzwerk übertragen werden zu können. Das wiederum führt möglicherweise zu Problemen. Setzt man nun vorher die MTU runter, kann auch durch die Verschlüsselung nicht das Maximum (Ethernet: 1500 Bytes) überschritten werden und es findet keine Fragmentierung statt: Problem erfolgreich umgangen.

Das bedeutet insgesamt: Man kann mit der MTU etwas rumspielen. Wenn's das nicht ist, werden die Datenpakete halt etwas kleiner und die Verbindung etwas ineffizienter. Aber ausprobieren kann man das.

Ich denke nicht, dass das hier das Problem ist. Ich weiß allerdings auch nicht, wie sich solche Probleme äußern.

[mat6937]

Nutze ich aber den zweiten VPN Server, muß ich mich mit der ssh Option

Code: Alles auswählen

KexAlgorithms=ecdh-sha2-nistp521

verbinden. An sonsten komme ich nicht drauf. Ich bin da drauf gekommen, als ich den ssh client mit den debug Optionen ( -vvv ), ...

Das ist ja eine Option vom ssh-Client. Benutzt Du verschiedene ssh-Clients oder einen einzigen ssh-Client mit verschiedener Konfiguration für zwei sshd-Server? Dann könnte es evtl. sein, dass die vorhandene default-Option "ecdh-sha2-nistp521" aus dem default-set "rauskonfiguriert" worden ist und Du sie mit der Kommandozeilen-Option "KexAlgorithms=ecdh-sha2-nistp521" (für den ssh-Client) wieder aktivierst.

[The Hit-Man]

Ich denke nicht, dass das hier das Problem ist. Ich weiß allerdings auch nicht, wie sich solche Probleme äußern.

So ein ähnliches Problem hatte ich schon mal ... X2go läuft ja über den ssh port. So weit so gut ... Manchmal brauchte ich eine Verbindung von meinem Rechner aus auf eine andere Fritzbox. Das ist ja auch kein großes Problem. Dann aber als ich auf die Rechner per ssh zugreigen wollte ( wegen updates ), kam ich da nicht drauf. Ich mußte erst den MTU umsetzen und dann gabs keine Probleme mehr. Das muß wohl schon da dran liegen. Auf meinem virtuellen Server konnte ich mich zwar per ssh einloggen aber dann auch nur mit der beschriebenen Option. Mir fiel auf das ich im normalen Terminal ( ssh verbunden ) den midnight-commander nicht aufrufen konnte. also das terminal blieb einfach nach 'mc' stehen. Auch größere X Programme wollte ich zum testen mal über ssh starten ( sonst habe ich ja eigentlich einen X2go Desktop ). Auch die funktionierten nicht, nur so kleine X Programme wie 'xclock' etc.
Jetzt wo ich halt diesen MTU Wert geändert habe, für den 2ten VPN, der Probleme macht, scheint es jetzt zu laufen ...

[heisenberg]

Kannst Du mal ein paar pings durchführen (erst mit dem altem MTU-Wert (Dein vorher eingestellter Wert) und dann mit dem neuem MTU-Wert (1280) ?

Also so etwas ...

Code: Alles auswählen

ping -s 1350 -c10 server1
ping -s 1350 -c10 server2
ping -s 1450 -c10 server1
ping -s 1450 -c10 server2
ping -s 1550 -c10 server1
ping -s 1550 -c10 server2

... und dann berichten, ob Du irgendwo Paketverluste hattest?

[The Hit-Man]

... und dann berichten, ob Du irgendwo Paketverluste hattest?

Was meinste mit Server1 und Server2? Meine VPN Server?

[heisenberg]

... und dann berichten, ob Du irgendwo Paketverluste hattest?

Was meinste mit Server1 und Server2? Meine VPN Server?

Probiere es mal mit allen.

Und nimm den Befehl hier:

Code: Alles auswählen

ping -M do -s 1150 -c10 server1
ping -M do -s 1350 -c10 server1
ping -M do -s 1450 -c10 server1
ping -M do -s 1550 -c10 server1

Bei der kleineren MTU dürfte nur der 1. Befehl durchgehen. Ansonsten weiss ich nicht, wie Deine andere MTU war.

Zu den Optionen:

-M do

bedeutet, dass das Paket nicht fragmentiert werden darf (Fehlermeldung, falls es doch fragmentiert werden soll)

-s <Wert>

Größe des Ping-Paketes in Bytes.

-c <Wert>

Anzahl von Pings, die gesendet werden.

Ich weiss jetzt auch nicht unbedingt, ob das irgend einen Erkenntnisgewinn liefert. Aber wer weiß.

[heisenberg]

Ich habe selbst mal ein bisschen rumgepingt.

Interessanterweise bekomme ich bei größeren Pings viele Verluste zu manchen Zielen. Bei meinem eigenen Server (VM) geht das. Kann sein, dass das Netzwerktechnisch dort eingeschränkt / runtergeregelt ist.

Maximalgröße ist bei mir 1472:

Code: Alles auswählen

$ ping -M do -s 1472 hurz.cc
PING hurz.cc (1.2.3.4) 1472(1500) bytes of data.
1480 bytes from monitoring.hurz.cc (1.2.3.4): icmp_seq=1 ttl=57 time=18.3 ms
1480 bytes from monitoring.hurz.cc (1.2.3.4): icmp_seq=2 ttl=57 time=16.2 ms
1480 bytes from monitoring.hurz.cc (1.2.3.4): icmp_seq=3 ttl=57 time=19.0 ms

Code: Alles auswählen

$ ping -M do -s 1473 hurz.cc
PING hurz.cc (1.2.3.4) 1473(1501) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

[The Hit-Man]

Die Sache sieht dann so aus ... Den ersten VPN-Server brauche ich nicht testen, da ich da ja auch nix verändert hatte. Der lief ja eh ohne Probleme. Beim 2ten VPN Server sind beide ping Ergebnisse gleich. Der MTU Default Wert ist ja 1420 ... Den habe ich auf 1280 gesetzt. Wie gesagt, beim ping Ergebnis spielt es keine Rolle:

Code: Alles auswählen

u0@HTM-Flur-Ruedi:~$ ping -s 1350 -c10 www.google.de
PING www.google.de (142.251.37.3) 1350(1378) bytes of data.
^C
--- www.google.de ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9227ms

u0@HTM-Flur-Ruedi:~$ ping -s 1450 -c10 www.google.de
PING www.google.de (142.251.37.3) 1450(1478) bytes of data.
From FlurOpenWrt.lan (192.168.10.1) icmp_seq=1 Frag needed and DF set (mtu = 1420)
^C
--- www.google.de ping statistics ---
8 packets transmitted, 0 received, +1 errors, 100% packet loss, time 7148ms

u0@HTM-Flur-Ruedi:~$ ping -s 1550 -c10 www.google.de
PING www.google.de (142.251.37.3) 1550(1578) bytes of data.
^C
--- www.google.de ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7149ms

Ich mußte sie abbrechen weil sie sonst nicht weiter liefen. Es sei no bemerkt, der 1ste VPN Server ist von protonvpn, der 2te ( wo es die Probleme gab ), von surfshark.

[heisenberg]

Es fehlt das -M do

Das ist essenziell! (Auch wenn es bei einem Deiner Befehle wohl implizit gesetzt zu sein scheint.)

Und pinge bitte von Deinem Client Deine Server an. Wie schon geschrieben. Bei anderen Servern ist das evtl. beschränkt.

[The Hit-Man]

Ach, ich hatte wohl einen kleinen Denkfehler ... Müßte den ping von meinem Router aus starten ... Denn auf dem ist ja der Tunnel installiert. Alle Rechner hinter der Fritte gehen ja gleich über den Tunnel, per NAT.

[heisenberg]

Ach, ich hatte wohl einen kleinen Denkfehler ... Müßte den ping von meinem Router aus starten ... Denn auf dem ist ja der Tunnel installiert. Alle Rechner hinter der Fritte gehen ja gleich über den Tunnel, per NAT.

Das ist ja Sinn der Sache, dass die Pakete über den Tunnel gehen.

[The Hit-Man]

So, jetzt aber ... Nochmal ... Erst pinge ich meinen VServer an mit dem VPN was ja, die Fehler hatte, mit dem defaul Wert MTU=1420:

Code: Alles auswählen

u0@HTM-Flur-Ruedi:~$ ping -M do -s 1150 -c10 167.86.110.245
PING 167.86.110.245 (167.86.110.245) 1150(1178) bytes of data.
1158 bytes from 167.86.110.245: icmp_seq=1 ttl=51 time=46.5 ms
1158 bytes from 167.86.110.245: icmp_seq=2 ttl=51 time=64.1 ms
1158 bytes from 167.86.110.245: icmp_seq=3 ttl=51 time=52.7 ms
1158 bytes from 167.86.110.245: icmp_seq=4 ttl=51 time=46.2 ms
1158 bytes from 167.86.110.245: icmp_seq=5 ttl=51 time=46.2 ms
1158 bytes from 167.86.110.245: icmp_seq=6 ttl=51 time=59.2 ms
1158 bytes from 167.86.110.245: icmp_seq=7 ttl=51 time=46.5 ms
1158 bytes from 167.86.110.245: icmp_seq=8 ttl=51 time=65.0 ms
1158 bytes from 167.86.110.245: icmp_seq=9 ttl=51 time=46.7 ms
1158 bytes from 167.86.110.245: icmp_seq=10 ttl=51 time=69.0 ms

--- 167.86.110.245 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 46.178/54.214/69.025/8.746 ms
u0@HTM-Flur-Ruedi:~$ ping -M do -s 1350 -c10 167.86.110.245
PING 167.86.110.245 (167.86.110.245) 1350(1378) bytes of data.
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280

--- 167.86.110.245 ping statistics ---
10 packets transmitted, 0 received, +10 errors, 100% packet loss, time 9215ms

u0@HTM-Flur-Ruedi:~$ ping -M do -s 1450 -c10 167.86.110.245
PING 167.86.110.245 (167.86.110.245) 1450(1478) bytes of data.
From 192.168.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1420)
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 167.86.110.245 ping statistics ---
10 packets transmitted, 0 received, +10 errors, 100% packet loss, time 9218ms

u0@HTM-Flur-Ruedi:~$ ping -M do -s 1550 -c10 167.86.110.245
PING 167.86.110.245 (167.86.110.245) 1550(1578) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 167.86.110.245 ping statistics ---
10 packets transmitted, 0 received, +10 errors, 100% packet loss, time 9218ms

Und jetzt einmal mit meinem geänderten Wert, der zu gehen scheint MTU=1280:

Code: Alles auswählen

u0@HTM-Flur-Ruedi:~$ ping -M do -s 1150 -c10 167.86.110.245
PING 167.86.110.245 (167.86.110.245) 1150(1178) bytes of data.
1158 bytes from 167.86.110.245: icmp_seq=1 ttl=51 time=49.9 ms
1158 bytes from 167.86.110.245: icmp_seq=2 ttl=51 time=45.6 ms
1158 bytes from 167.86.110.245: icmp_seq=3 ttl=51 time=45.2 ms
1158 bytes from 167.86.110.245: icmp_seq=4 ttl=51 time=220 ms
1158 bytes from 167.86.110.245: icmp_seq=5 ttl=51 time=46.6 ms
1158 bytes from 167.86.110.245: icmp_seq=6 ttl=51 time=96.8 ms
1158 bytes from 167.86.110.245: icmp_seq=7 ttl=51 time=46.0 ms
1158 bytes from 167.86.110.245: icmp_seq=8 ttl=51 time=198 ms
1158 bytes from 167.86.110.245: icmp_seq=9 ttl=51 time=344 ms
1158 bytes from 167.86.110.245: icmp_seq=10 ttl=51 time=91.1 ms

--- 167.86.110.245 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 45.231/118.344/343.721/97.208 ms
u0@HTM-Flur-Ruedi:~$ ping -M do -s 1350 -c10 167.86.110.245
PING 167.86.110.245 (167.86.110.245) 1350(1378) bytes of data.
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280

--- 167.86.110.245 ping statistics ---
10 packets transmitted, 0 received, +10 errors, 100% packet loss, time 9196ms

u0@HTM-Flur-Ruedi:~$ ping -M do -s 1450 -c10 167.86.110.245
PING 167.86.110.245 (167.86.110.245) 1450(1478) bytes of data.
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280

--- 167.86.110.245 ping statistics ---
10 packets transmitted, 0 received, +10 errors, 100% packet loss, time 9208ms

u0@HTM-Flur-Ruedi:~$ ping -M do -s 1550 -c10 167.86.110.245
PING 167.86.110.245 (167.86.110.245) 1550(1578) bytes of data.
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280

--- 167.86.110.245 ping statistics ---
10 packets transmitted, 0 received, +10 errors, 100% packet loss, time 9203ms

[heisenberg]

So, jetzt aber ... Nochmal ... Erst pinge ich meinen VServer an mit dem VPN was ja, die Fehler hatte, mit dem defaul Wert MTU=1420:

u0@HTM-Flur-Ruedi:~$ ping -M do -s 1350 -c10 .....
PING ....245 (..245) 1350(1378) bytes of data.
ping: local error: message too long, mtu=1280

Du schreibst, dass Du die MTU auf 1420 gesetzt hast. der Ping sagt aber, dass Du aber noch eine MTU von 1280 hast. Hast Du die VPN-Clients/Server neu verbinden lassen?

[mat6937]

Also ich fand im Netz etwas, das ich für das 2te VPN mal den MTU Wert ändern sollte und schon hatte ich keine Probleme mehr. Ich sollte den auf 1280 stellen.

Welche MTU(s) ist/sind bei den Endpoint-Interfaces deines WireGuard-Tunnels konfiguriert bzw. z. Zt. vorhanden?

BTW: Bei meinen WireGuard-Tunnels haben die Endpoints (Linux/FreeBSD/OpenBSD/Windows) eine MTU von 1472 und die WireGuard-Peers (Clients, servers) eine MTU von 1392, und ich hatte noch nie Probleme mit WireGuard wegen der MTU.

[The Hit-Man]

Du schreibst, dass Du die MTU auf 1420 gesetzt hast. der Ping sagt aber, dass Du aber noch eine MTU von 1280 hast. Hast Du die VPN-Clients/Server neu verbinden lassen?

Ja, habe ich ...

BTW: Bei meinen WireGuard-Tunnels haben die Endpoints (Linux/FreeBSD/OpenBSD/Windows) eine MTU von 1472 und die WireGuard-Peers (Clients, servers) eine MTU von 1392, und ich hatte noch nie Probleme mit WireGuard wegen der MTU.

Da kann ich nichts zu sagen. Stand nirgends wo etwas ... Fand den MTU Wert ja auch nur per Zufall beim googlen ...

[The Hit-Man]

Ich glaube wenn ich den Tunnel einfach über meinen Rechner starte mit wg-quick up wireguard.conf brauche ich mich wohl auch nicht um den MTU zu kümmern? Aber vielleicht wenn ich den Tunnel auf dem Router anlege, dann vielleicht schon?

[heisenberg]

.oO(Ich glaube ich höre mal auf, hier ziellos rumzustümpern und nehme mal lieber als stiller Beobachter weiter teil.)

[The Hit-Man]

Sei es drum ... So lange es geht, ist es ja OK. Bischen unzufriedend stellend das man nicht genau weiß, was es ist aber egal ...
Danke Euch trotzdem für die Mühe. Ist ja nicht immer alles selbstverständlich ...

[mat6937]

Bischen unzufriedend stellend das man nicht genau weiß, was es ist aber egal ...

Es geht doch um das ssh-Verhalten. Du hast oben geschrieben:

Ich bin da drauf gekommen, als ich den ssh client mit den debug Optionen ( -vvv ), gestartet habe.

Poste mal die genaue Information, um zu sehen wie Du dazu gekommen bist, die Option:

Code: Alles auswählen

KexAlgorithms=ecdh-sha2-nistp521

zu benutzen.
Wie und warum bist Du dann auf die MTU gekommen? Meinst Du das eine bestimmte MTU (im WireGuard-Tunnel) nur diese Option (aus dem default set des ssh-Clienten) erforderlich macht? Oder hat der debug-Modus (-vvv) dir das gezeigt?

[The Hit-Man]

Poste mal die genaue Information, um zu sehen wie Du dazu gekommen bist, die Option:

Das würde jetzt wohl eher den Rahmen sprengen ... Ich wollte mich ganz normal per ssh, wie ich es immer mache auf meinem virtuellen Server an melden, über den besagten Tunnel der ärger machte. Das Terminal machte einfach nix mehr als ich mich ganz normal an meinem Server anmelden wollte. Aus dem Grund hatte ich die debug/verbose Option eingeschaltet ( ssh username@server -vvv ). Dort sah ich das der ssh client an einem Punkt harkte, mit der Bezeichnung:

Code: Alles auswählen

KexAlgorithms

Frag mich nicht nach dem genauen Syntax. Des weiteren funtze mein sshfs zu meinem Server nicht mehr, über dem besagten, fehlerhaften Tunnel. Also, was macht man, bevor man das Forum fragt? Man googlet selbst nach der Lösung. Irgendwo fand ich dann genau diese Oprtion:

Code: Alles auswählen

KexAlgorithms=ecdh-sha2-nistp521

die, ich natürlich in meinem sshfs mount einbaute UND in meiner ssh Terminalverbindung. Und was mußten meine Augen sehen? ES FUNKTIONIERTE !!! So weit so gut ... Ich gehe mal davon aus, Du hast den kompletten Thread gelesen.
Auf dem Server befindet sich ein X2go Server ( das ist eine Art Remote Desktop ). Komisch, dachte ich mir, wieso funktioniert dieser auf einmal nicht mehr, da der Server doch über SHH getunnel wird und SSH funktioniert doch plötzlich wieder mit der besagten Option.

Also was mach man wieder bevor man im Forum fragt. Man googelt natürlich selbst nach der Lösung. Also googlte ich nach meinem VPN Provider und X2go Server denn ich nutze auch noch hin und wieder einen anderen VPN Provider und damit keine Probleme ... Also weiter im Text. Dann konnte es ja nur an meinem Provider liegen und dem X2go Server. Dadurch fand ich irgendwo die MTU Einstellung, die ich dann probierte und SIEHE DA... BÄHM ... auch ohne die Option:

Code: Alles auswählen

KexAlgorithms=ecdh-sha2-nistp521

funktionierte es plötzlich. Problem gelöst ... Nur weiß ich nicht wieso und warum das funktioniert, plötzlich mit der MTU Einstellung ...

@mat6937:
Jetzt kommst du und erklärst mir hoffentlich warum das so ist

Wie und warum bist Du dann auf die MTU gekommen? Meinst Du das eine bestimmte MTU (im WireGuard-Tunnel) nur diese Option

Genau eine bestimmte MTU für genau diesen Tunnel ... Habe von diesem Provider noch andere wireguard Tunnel ... aber das MTU muß wohl so gesetzt werden, sonst funtzt es mit all den anderen Tunneln von dem Provider auch nicht.