ssh Verhalten

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Benutzeravatar
The Hit-Man
Beiträge: 2171
Registriert: 21.11.2004 17:01:56
Wohnort: Menden ( Sauerland )
Kontaktdaten:

Re: ssh Verhalten

Beitrag von The Hit-Man » 28.08.2023 21:01:18

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.
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 ;)

mat6937
Beiträge: 2953
Registriert: 09.12.2014 10:44:00

Re: ssh Verhalten

Beitrag von mat6937 » 28.08.2023 21:51:34

The Hit-Man hat geschrieben: ↑ zum Beitrag ↑
28.08.2023 20:56:18
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.
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.

Benutzeravatar
The Hit-Man
Beiträge: 2171
Registriert: 21.11.2004 17:01:56
Wohnort: Menden ( Sauerland )
Kontaktdaten:

Re: ssh Verhalten

Beitrag von The Hit-Man » 28.08.2023 22:05:21

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.
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 ...
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 ;)

mat6937
Beiträge: 2953
Registriert: 09.12.2014 10:44:00

Re: ssh Verhalten

Beitrag von mat6937 » 28.08.2023 22:12:19

The Hit-Man hat geschrieben: ↑ zum Beitrag ↑
28.08.2023 22:05:21
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 ...
Ja, das die MTU bei http(s), ftp und gleichwertig, entscheidend sein kann habe ich schon gesehen, aber beim ssh hätte ich nicht gedacht

Antworten