Vielleicht müssen diese Einstellunge gemacht werden aber es steht nicht in der Doku von dem Provider ... Achja, der Provider ist surfshark ...
Zum Beispiel habe ich noch einen Tunnel von protonvpn und dort mußte ich keine weiteren Einstellungen mit der MTU machen. Da funtzte alles geich von vorn herein.
ssh Verhalten
- The Hit-Man
- Beiträge: 2236
- Registriert: 21.11.2004 17:01:56
- Wohnort: Menden ( Sauerland )
-
Kontaktdaten:
Re: ssh Verhalten
Wer HTML postet oder gepostetes HTML quotet oder sich gepostetes oder
gequotetes HTML beschafft, um es in Verkehr zu bringen, wird geplonkt.
damals windows, früher ubuntu, danach debian, heute arch-linux
gequotetes HTML beschafft, um es in Verkehr zu bringen, wird geplonkt.
damals windows, früher ubuntu, danach debian, heute arch-linux
Re: ssh Verhalten
Das ist ein interessanter Zusammenhang, zwischen der MTU im WG-Tunnel (deines Providers?) und dem KexAlgorithms für den ssh-Client (wenn dieser in diesem WG-Tunnel unterwegs ist). D. h. obwohl ecdh-sha2-nistp521 im default set des ssh-Clienten ist, wird dieser nicht benutzt, weil logischerweise, hier der Zusammenhang zwischen der MTU und dem KexAlgorithms nicht erkannt werden kann.The Hit-Man hat geschrieben:28.08.2023 20:56:18Genau 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.
Würde der sshd-Server nur den ecdh-sha2-nistp521 zulassen, würde der ssh-Client nur diesen benutzen.
Debian 12.8 mit LXDE, OpenBSD 7.6 mit i3wm, FreeBSD 14.1 mit Xfce
- The Hit-Man
- Beiträge: 2236
- Registriert: 21.11.2004 17:01:56
- Wohnort: Menden ( Sauerland )
-
Kontaktdaten:
Re: ssh Verhalten
Ich schrieb ja, das ich schon mal so eine Art Phenomen hatte ... Ich bin mir nicht ganz sicher ob ich einen Tunnel genutzt hatte oder nicht ... ABER hin und wieder muß ich mich vom Rechner aus, bei Kollegen auf die Fritte vebinden. Also das eigene VPN ( geht ja ohne Probleme, Rechner mit Fritte per VPN zu verbinden ). Jetzt wieder das große ABER. Ich kam per ssh nicht auf die Rechner drauf um diese zu updaten, per ssh. Genau das gleiche wie ich hier zu Anfang schrieb, mit meinem virtuellem Server ... Und was fand ich im Netz? die MTU an passen und BÄHM, kam ich per ssh ohne Probleme auf die Rechner im eigenen VPN ... und das VPN zwischen mir und der Fritte von den Kollegen war natürlich KEIN wireguard Tunnel ... Also scheint das Protokoll auch nicht das Problem zu sein ...Das ist ein interessanter Zusammenhang, zwischen der MTU im WG-Tunnel (deines Providers?) und dem KexAlgorithms für den ssh-Client (wenn dieser in diesem WG-Tunnel unterwegs ist). D. h. obwohl ecdh-sha2-nistp521 im default set des ssh-Clienten ist, wird dieser nicht benutzt, weil logischerweise, hier der Zusammenhang zwischen der MTU und dem KexAlgorithms nicht erkannt werden kann.
Würde der sshd-Server nur den ecdh-sha2-nistp521 zulassen, würde der ssh-Client nur diesen benutzen.
Aber man ist ja auch erstmal zu frieden
Wer HTML postet oder gepostetes HTML quotet oder sich gepostetes oder
gequotetes HTML beschafft, um es in Verkehr zu bringen, wird geplonkt.
damals windows, früher ubuntu, danach debian, heute arch-linux
gequotetes HTML beschafft, um es in Verkehr zu bringen, wird geplonkt.
damals windows, früher ubuntu, danach debian, heute arch-linux
Re: ssh Verhalten
Ja, das die MTU bei http(s), ftp und gleichwertig, entscheidend sein kann habe ich schon gesehen, aber beim ssh hätte ich nicht gedachtThe Hit-Man hat geschrieben:28.08.2023 22:05:21Und was fand ich im Netz? die MTU an passen und BÄHM, kam ich per ssh ohne Probleme auf die Rechner im eigenen VPN ...
Debian 12.8 mit LXDE, OpenBSD 7.6 mit i3wm, FreeBSD 14.1 mit Xfce