Volby pro SSH, aby vydržel dlouhodobě NAT

[mikesznovu]

Mám dotaz, jaké zvolit volby pro sshd + ssh, aby  vydržel téměř nonstop pro Remote forwarding portu. Na server například je komunikace každou hodinu, která se forwarduje do klienta (tedy ten co spouští ssh)
V situaci, kdy klient je za NATem s poločasem rozpadu 2 minuty.

Používám nyni -o ServerAliveInterval 50 a běží to   třeb půl dne ale  v noci někdy(nevím jak často) vymizí, proces ssh se ztratí a na serveru už ss-4lntp taky neukazuje řádek který jsem nastavilMám pocit, že s touto volbou to vydrží.  Jednu hypotézu mám, že výsledky by mohlo zkreslovat různé nepovedené komunikace, které neprovedou výsledek, nezalogují se, jako  třeba jen otevřené spojení, různé port scannery, které refreshnou komunikaci a zabrání expiraci.

Předtím jem to provozoval bez ServerAliveInterval amám pocit, že rozpadky byly čaastější, ale neumím to upřesnit.

1. Jsou volby Server vs Client - AliveInterval/Count rovnocenné? (až na to že se nastavují u klienta resp. u serveru a odhlédnu od toho, který konec čeká na expiraci timeru)
Je tato volba důležitá?

2. Bonusová otázka, jak Remote/local forwarding funguje,   čeká server až se dokoncčí handshake a pak teprv začne komunikace na klientovi a nebo tunel posílá TCP pakety jak přijdou /že přes tunel putuje TCP syn, ack+syn, ck přes celý tunel)


3: TCPKeepAlive jsem pochopil že není to co chci. Má být vypnuté nebo na něm nezáleží? (Volba je pro obě strany)

[Reklama]

[Petr Krčmář]

K trvalému udržování SSH tunelu slouží nástroj autossh.

[Jan Fikar]

1. Jsou volby Server vs Client - AliveInterval/Count rovnocenné? (až na to že se nastavují u klienta resp. u serveru a odhlédnu od toho, který konec čeká na expiraci timeru)

Tak ServerAliveInterval a ServerAliveCountMax se nastaví v klientovi. Po čase AliveInterval pošle klient prázdnou alive zprávu a tím se snaží udržet spojení aktivní. Když AliveCountMax krát nedostane na tuto zprávu odpověď, tak řekne, že nemá spojení a končí.

Pokud si teda myslím, že se mi spojení rozpadá třeba na 300 sekund, tak si nastavím ServerAliveInterval 30 a ServerAliveCountMax 200, takže to přežije výpadek kratší než 600 sekund a ještě se spojí. Nevýhoda je, že když se to opravdu rozpadne, nebo server spadne, tak to bude ještě 600 sekund trčet.

Výchozí je ServerAliveCountMax 3, ale lepší je dát víc a naopak menší ServerAliveInterval. Nejlíp je to dát do ~/.ssh/config

3: TCPKeepAlive jsem pochopil že není to co chci.

No taky pomáhá udržet spojení aktivní, ale není to šifrovaný, takže je to riziko. Lepší je nastavit na serveru ClientAliveInterval a ClientAliveCountMax. Což dělá to stejné, ale z pohledu serveru. Teda server pošle klientovi alive zprávu. Když jich nedostane CountMax zpět, tak řekne, že klient se odpojil a zruší spojení.

[Hornik]

Muzete podrobneji popsat ten use case?

Uvazovali jste o vyuziti TailScale, ZeroTier nebo IPv6?

[bobprasak]

3: TCPKeepAlive jsem pochopil že není to co chci.

No taky pomáhá udržet spojení aktivní, ale není to šifrovaný, takže je to riziko. Lepší je nastavit na serveru ClientAliveInterval a ClientAliveCountMax. Což dělá to stejné, ale z pohledu serveru. Teda server pošle klientovi alive zprávu. Když jich nedostane CountMax zpět, tak řekne, že klient se odpojil a zruší spojení.

Tcp keepalive je defacto prazdnej ack packet, tam nema bejt co sifrovany. Navic je resen os vrstvou a nikoliv aplikaci, ssh jen pozada aby socket byl otevren s so_keepalive option. OS pak zajisti periodicke posilani ack paketu, jak casto a v jakejch intevalech zalezi na sysctl options (sem ted linej je hledat).

[Reklama]

[Jan Fikar]

Tcp keepalive je defacto prazdnej ack packet, tam nema bejt co sifrovany. Navic je resen os vrstvou a nikoliv aplikaci, ssh jen pozada aby socket byl otevren s so_keepalive option. OS pak zajisti periodicke posilani ack paketu, jak casto a v jakejch intevalech zalezi na sysctl options (sem ted linej je hledat).

Ano, ale ten prázdný ack paket jde někde zachytit, zahodit, nebo modifikovat. Kdežto ty pakety Alive uvnitř ssh jsou zašifrované a je zaručena integrita přes MAC, takže s nimi nejde nic provést. Proto se upřednostňují.

[kouli]

Jestli má to SSH spojení vydržet přes noc, tak je naopak potřeba ty TCP keep-alive nebo SSH alive vypnout, zachovat dostatečné time-outy na TCP a vedle toho eliminovat NATy a stavové firewally po cestě: buď pomocí tunelu (který ten keep-alive bude používat pro udržení NATu) nebo IPv6 (pokud po cestě není stavový firewall). Takto spojení s SSH serverem vydrží nejen přes noc, ale přežije třeba i usnutí notebooku, přenos do jiné lokality a pod. Když ten keep-alive uděláte v SSH a/nebo TCP, tak se to spolehlivě rozpadne třeba i při krátkém výpadku internetu.

[mikesznovu]

Mě právě šlo o dosažení této vlastnosti bez obezliček a wrapperů, jestli to ssh bude samotný.


Na větším množství systému pozoruji široké spektrum chování, třeba když se připojim z macu osu ixu, uspim,proberu druhý den, připojím se na wifi, mohu dopsat "rozepsaný  příkaz", maximálně prvních 5 sekund to "bufferuje",.
Jinde minutové rozpojení ohlásí ukončení ssh.

Ale asi už je to pasé a vyřešené, používám to volbu - ServerKeepAlive a už to pár dní nevypadlo.