Întâmpin o problemă în care ssh la un server la distanță se blochează cu mesajul SSH2_MSG_KEXINIT trimis. Am explorat deja opțiunile MTU fără noroc.
Cazul 1 (eșuează)
Acest lucru se întâmplă când fac ssh de pe computerul meu Linux printr-un router openWRT care rulează clientul openVPN. Am routerul setat să redirecționeze din LAN 44.20.11.0/24 la VPN tun0. Pot ping cu succes serverul ssh la distanță de pe computerul meu, așa că nu cred că redirecționarea este problema.
Această versiune client pentru PC openVPN este 2.5.2 mips-openwrt-linux-gnu. Versiunea openWRT openVPN de pe server este openvpn-2.3.8-16.26.1.x86_64.
Iată rezultatul clientului ssh pentru cazul eșuat:
ssh -vvvv [email protected]
OpenSSH_8.8p1, OpenSSL 1.1.1m 14 decembrie 2021
debug1: Citirea datelor de configurare /home/myuser/.ssh/config
debug1: Citirea datelor de configurare /usr/etc/ssh/ssh_config
debug1: /usr/etc/ssh/ssh_config linia 24: include /etc/ssh/ssh_config.d/*.conf nu se potrivește niciun fișier
debug1: /usr/etc/ssh/ssh_config linia 26: Se aplică opțiuni pentru *
debug2: resolve_canonicalize: numele de gazdă 10.84.96.200 este adresa
debug3: UserKnownHostsFile extins „~/.ssh/known_hosts” -> „/home/myuser/.ssh/known_hosts”
debug3: UserKnownHostsFile extins „~/.ssh/known_hosts2” -> „/home/myuser/.ssh/known_hosts2”
debug3: ssh_connect_direct: intrare
debug1: se conectează la 10.84.96.200 [10.84.96.200] portul 22.
debug3: set_sock_tos: setați soclul 3 IP_TOS 0x10
debug1: Conexiune stabilită.
debug1: fișier de identitate /home/myuser/.ssh/id_rsa tip 0
debug1: fișier de identitate /home/myuser/.ssh/id_rsa-cert tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_dsa tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_dsa-cert tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_ecdsa tip 2
debug1: fișier de identitate /home/myuser/.ssh/id_ecdsa-cert tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_ecdsa_sk tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_ecdsa_sk-cert tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_ed25519 tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_ed25519-cert tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_ed25519_sk tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_ed25519_sk-cert tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_xmss tip -1
debug1: fișier de identitate /home/myuser/.ssh/id_xmss-cert tip -1
debug1: șir de versiune locală SSH-2.0-OpenSSH_8.8
debug1: versiunea de protocol la distanță 2.0, versiunea de software la distanță OpenSSH_7.6
debug1: compat_banner: match: OpenSSH_7.6 pat OpenSSH_7.0*, OpenSSH_7.1*, OpenSSH_7.2*, OpenSSH_7.3*, OpenSSH_7.5*, OpenSSH_7.6*, OpenSSH_7.7* compat 0x0040
debug2: fd 3 setarea O_NONBLOCK
debug1: se autentifică la 10.84.96.200:22 ca „myuser”
debug3: record_hostkey: tipul de cheie găsit ECDSA în fișierul /home/myuser/.ssh/known_hosts:828
debug3: record_hostkey: tipul de cheie găsit RSA în fișierul /home/myuser/.ssh/known_hosts:2050
debug3: record_hostkey: tipul de cheie găsit DSA în fișierul /home/myuser/.ssh/known_hosts:2051
debug3: record_hostkey: a găsit tipul de cheie ED25519 în fișierul /home/myuser/.ssh/known_hosts:2052
debug3: load_hostkeys_file: s-au încărcat 4 chei de la 10.84.96.200
debug1: load_hostkeys: fopen /home/myuser/.ssh/known_hosts2: Nu există un astfel de fișier sau director
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: Nu există un astfel de fișier sau director
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: Nu există un astfel de fișier sau director
debug3: order_hostkeyalgs: au tipul de cheie potrivit cu cele mai bune preferințe [email protected], folosind HostkeyAlgorithms literal
debug3: trimite pachet: tip 20
depanare1: SSH2_MSG_KEXINIT a trimis```
Iată ruta PC-ului pentru acest scenariu (Caz 1, eșec):
implicit prin 44.20.6.1 dev br0
10.0.0.0/8 prin 44.20.11.11 dev enp1s0
44.20.6.0/24 dev br0 proto kernel scope link src 44.20.6.2
44.20.11.0/24 dev enp1s0 proto kernel scope link src 44.20.11.187
Cazul 2 (funcționează)
Când rulez clientul openVPN direct pe computerul Linux, pot trimite cu succes ssh la serverul ssh de la distanță. Acest lucru mă face să cred că problema constă în routerul openWRT/openVPN.
Această versiune client openvpn este 2.5.5 x86_64-suse-linux-gnu
Iată ruta PC-ului Linux atunci când ocoliți routerul openWRT și rulați clientul openVPN direct pe computer:
implicit prin 44.20.6.1 dev br0
44.20.6.0/24 dev br0 proto kernel scope link src 44.20.6.2
44.20.11.0/24 dev enp1s0 proto kernel scope link src 44.20.11.187
Am o singură instanță a clientului openVPN care rulează la un moment dat.
Am citit toate firele care sugerează schimbarea MTU. Am încercat să-l setez 1492, 1000, și 576 pe dispozitivele de rețea ale clientului, fără noroc. MTU-ul serverului openVPN de pe partea de server este setat la 1492.
Atât PC-ul Linux, cât și clienții VPN openWRT/openVPN folosesc aceeași configurație de client (porțiuni relevante incluse):
client
dev tun
menține în viață 10 300
reneg-sec 0
auth-user-pass
script-securitate 3
Trage
cheie-persiste
persist-tun
server de tip ns-cert
comp-lzo
verbul 6
mut 20
auth SHA512
cifrul AES-256-CBC
Observatiile mele:
Deoarece acest lucru funcționează atunci când rulează clientul VPN direct pe PC-ul Linux, nu cred că acesta este un client openVPN sau o configurare greșită a serverului. Bănuiesc că problema se află între ele, în routerul openWRT/openVPN. Când ssh'ing direct de la routerul openWRT, conexiunea se blochează, de asemenea.
mtr 10.84.96.200 nu arată pierderi de pachete.
Bănuiesc că problema ar putea fi unul dintre aceste lucruri:
- Nu am schimbat MTU pe dispozitivele de rețea corecte
- MTU ar trebui să fie o altă valoare decât
1492, 1000 sau 576
- Există o setare de firewall pe routerul openWRT care încalcă acest lucru
- Ceva în openWRT face ca acest lucru să eșueze
Dispozitivul openWRT este un router de călătorie gl.inet Slate. Pot accesa jurnalele atât de la openVPN-ul client, cât și de la server, dar nu pot schimba partea de server openVPN. Pot accesa și schimba serverul ssh de pe partea serverului.
Iată o diagramă pentru a se putea explica mai clar:
