Nejde navázat odchozí SSH spojení - nikam

[Jakub Štech]

Potřeboval bych nasměrovat ke způsobům, jak tohle vůbec začít debugovat.

Po startu systému je všechno normální, SSH funguje jak má, spravuju systémy několika firmám. Po nějakých akcích se ale něco stane a od té doby nemůžu z toho počítače navázat SSH spojení kamkoliv. Mezi ty akce patří:

- nahození a shození Wireguard tunelu (obvyklě několikrát po sobě)
- přenesení několika desítek GB přes rsync+ssh

SSH klient skončí timeoutem vždy tady:

Kód: [Vybrat]

ssh -vvv example.cz
OpenSSH_9.5p1, OpenSSL 3.1.4 24 Oct 2023
debug1: Reading configuration data (...)
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug2: resolving "example.cz" port 22
debug3: resolve_host: lookup example.cz:22
debug3: ssh_connect_direct: entering
debug1: Connecting to example.cz [47.555.1.1] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48

Podle `strace` to skutečně stojí na connect() volání.

Co zatím vím:

Není to per-user. Problém můžu vyvolat jedním uživatelem, ale ochromí to ssh celé mašině (i rootovi).

Není to na úrovni TCP. Spojení s SSH serverem se naváže bez problémů a okamžitě:

Kód: [Vybrat]

$ nc -v example.cz 22
Connection to example.cz (47.555.1.1) 22 port [tcp/ssh] succeeded!
SSH-2.0-OpenSSH_9.4

Není to nic v síti nebo u ISP. Když přestane SSH fungovat, můžu laptop sbalit a odvézt jinam, a ani tam mi to fungovat nebude.

Nebude to regrese v OpenSSH. Stejně to dělá ve verzích 9.3, 9.4, 9.5.

Asi to nesouvisí s Wireguardem. Zkompiloval jsem si kernel bez něj, a děje se to taky.

Firewall mám, ale nepoužívám:

Kód: [Vybrat]

# iptables-save
# Generated by iptables-save v1.8.10 on Sat Dec  9 16:23:42 2023
*filter
:INPUT ACCEPT [339349:459048520]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [55068:6356188]
COMMIT
# Completed on Sat Dec  9 16:23:42 2023

[Reklama]

[_Jenda]

Zkusil bych se dívat ve Wiresharku, jak se přesně liší první paket od SSH a netcatu. Teda pokud SSH nějaký paket vyprodukuje (předpokládám, že vyrobí SYN a pak čeká na ACK nebo tak něco).

Zkusil bych napsat jednoduchou TCP proxy (za mě skript v Pythonu, který otevře dva sockety, a všechna data bude přeposílat tam a zpět) a připojit se SSHčkem k tomu. Nebo není třeba psát, půjde to nějak udělat spojením netcatů nebo socatem.

[Pivson]

A co apparmor a podobny blbosti ?

Jestli nejaky VPN a spol, podivej se kudy pakety tecou, default routu a pod.

Pokud mas moznost - zkus jinyho SSH klienta (putty, lsh, ...)

P.

[Filip Jirsák]

Podíval bych se na konfiguraci sítě a routování (příkaz ip) a na firewall (iptables nebo nft), zda tam není nějaká neočekávaná routa, pravidlo či rozhraní (např. nějaký tunel) nebo pravidlo firewallu, které by blokovalo provoz nebo ho směřovalo někam jinam.
Dále bych se tcpdumpem nebo Wiresharkem podíval na odchozí komunikaci, jak píše Jenda – zda se vůbec odešle paket navazující spojení, jak vypadá, kam se odešle.

[Jakub Štech]

Díky za odpovědi, máme pokrok!

Na localhost ssh se připojím. Když si socatem udělám proxy, připojím se přes ni i kamkoliv ven.

Alternativním klientem (putty) se připojím.

Pozorováním odchozích paketů jsem vypozoroval, že:
- nefunkční (z openssh klienta) paket má zapnutý DiffServ flag AF21, funkční (putty, nebo openssh přes proxy) nemá
- paket neopustí stroj (trace na routeru ani v cíli nic nezachytí)

Souvisí to tedy s IP QoS. Zkusil jsem:

Kód: [Vybrat]

$ ssh -o IPQoS=none example.cz

a připojilo mě to. Workaround ❤️

Mám tedy někde, v něčem, rozbitou konfiguraci QoS a po nějaké tomu se nelíbící míře aktivity (přesun hodně dat nebo ifup/ifdown tunelu) mě to beze slova odřízne.

[Reklama]