ssh sessie stuk, doorwerken met screen

[Jazzy]

Ik ben wat werk aan het doen op een remote server en af en toe slaat de ssh sessie vast waardoor ik mijn werk kwijt ben. Nu ben ik screen gaan gebruiken maar weet nog niet precies of ik het nu goed doe. Het lijkt er op dat ik alleen kan reconnecten naar een screen sessie als ik die eerst expliciet detached heb. Dat is voor mij geen echte oplossing omdat ik steeds CTRL+a, d moet doen voordat ik denk dat ik de sessie mogelijk kwijt zou kunnen raken.

Wat dus werkt is dit:
- ssh naar remote host
- screen -S mijnsessie
- $werk
- Detach: CTRL+a, d
- ssh time out
- nieuwe ssh naar remote host
- screen -r mijnsessie

Wat dus niet werkt:
- ssh naar remote host
- screen -S mijnsessie
- $werk
- nog meer $werk
- ssh time out
- nieuwe ssh naar remote host
- screen -ls: geen detached screens beschikbaar

Doe ik iets verkeerd of is er een betere manier om door te kunnen werken nadat je ssh sessie verbroken is?

Denk niet dat het heel relevant is, maar ik gebruik PuTTY en Solar-PuTTY om vanaf Windows 10 naar een Ubuntu 20.04.1 LTS server te verbinden die in Azure draait.

[CyBeR]

wellicht is je screen sessie nog attached omdat je volgens de server nog ingelogd bent; gebruik in dat geval screen -x (multi-attach) of screen -dr (de oude sessie d'r af knikkeren) om te attachen

[ Voor 19% gewijzigd door CyBeR op 09-12-2020 14:01 ]

[Vloris]

Ik heb zelf ongeveer in m'n vingers ingebakken zitten om altijd "screen -dR" te typen.
De 'd' voor "detach eerst eventueel nog bestaande (evt. dode) verbindingen"
De 'R' is hetzelfde als 'r' (reattach aan een bestaande screen-sessie), maar als er geen bestaande sessie is start die gewoon een nieuwe waarbij 'r' een foutmelding zou geven.

screen -dR werkt dus altijd: zowel voor het starten van een nieuwe screen, als voor het re-attachen aan een bestaande.

[eheijnen]

Dat Screen gebruikt wordt staat al in de TS en het heeft niet zoveel zin om alleen een soort van "rtfm" te gaan roepen.

[ Voor 77% gewijzigd door Cyphax op 09-12-2020 17:57 ]

[init6]

Als dit is omdat je met een AWS omgeving werkt en je er vrij snel uit gegooid wordt, dan kan je ook je ssh config aanpassen zodat je sessie er niet snel uitgegooid zal worden:
Configureer in je ssh config ServerAliveInterval 50 en het is gefixed. Maar het is sowieso goed om een screen sessie te starten.

Ik start meestal screen op met -R:
screen -R bla

-R Reattach if possible, otherwise start a new session.

[ Voor 11% gewijzigd door init6 op 09-12-2020 17:38 ]

[Jazzy]

Kijk, dat is de praktijkervaring die ik mistte. Bedankt voor de reacties.

Ik denk dat ik het detachen verkeerd begrepen had maar kwartje is nu gevallen. Ik ga ook gewoon standaard -dR gebruiken.

init6 schreef op woensdag 9 december 2020 @ 17:36:
Als dit is omdat je met een AWS omgeving werkt en je er vrij snel uit gegooid wordt, dan kan je ook je ssh config aanpassen zodat je sessie er niet snel uitgegooid zal worden:
Configureer in je ssh config ServerAliveInterval 50 en het is gefixed.

Het is Azure, niet AWS, maar je hebt wel een punt inderdaad. Ik weet niet meer precies wanneer maar ergens de afgelopen jaren is dit echt een issue geworden. Werken met screen lijkt me sowieso een verbetering, maar het is inderdaad hoog tijd om ook de root cause te fixen.

[Hero of Time]

Kijk trouwens ook even naar mosh. Zal je ook wel blij van worden.

[aawe mwan]

Hiervoor gebruik ik altijd tmux.
Het is eigenlijk net screen, maar dan anders.

Je start met tmux a om de sessie terug te halen die je kwijt geraakt bent toen de verbinding wegviel.

^B " om het window horizontaal te splitsen,
^B % om het window vertikaal te splitsen.
^B d om een detach te doen (je kunt later nog terug)
of met ^D gewoon uitloggen uit je tmux sessie.

Je kunt ook op meerdere plaatsen tegelijk verbinden met je tmux sessie. Eigenlijk net screen dus.

[ Voor 5% gewijzigd door aawe mwan op 10-12-2020 08:37 ]

[DaFeliX]

Hero of Time schreef op woensdag 9 december 2020 @ 19:36:
Kijk trouwens ook even naar mosh. Zal je ook wel blij van worden.

Mosh is een leuke oplossing! Alleen geeft de TS geeft aan dat ie WinOS gebruikt, en volgens mij werkt Mosh niet op WinOS?

[Jazzy]

DaFeliX schreef op donderdag 10 december 2020 @ 07:28:
[...]


Mosh is een leuke oplossing! Alleen geeft de TS geeft aan dat ie WinOS gebruikt, en volgens mij werkt Mosh niet op WinOS?

Welkom in 2020, native Linux apps op Windows 10 met Windows Subsystem for Linux (WSL).

[MartinMeijerink]

Als je ook het beheer over de server hebt, dan kun je het ook aan de serverkant oplossen door in /etc/ssh/sshd_config de keywords ClientAliveInterval en ClientAliveCountMax te gebruiken.
Ik vind het bijzonder irritant om een verbinding kwijt te raken, vooral om de history die daarbij niet bijgewerkt wordt, daarom zet ik bij elke server die ik beheer en/of installeer deze regels in /etc/ssh/sshd_config:

code:

ClientAliveInterval 120
ClientAliveCountMax 720

(en dan wel ff de sshconfig reloaden)
Op deze manier blijft de verbinding minimaal 24 uur actief, tenzij er echt een storing op de lijn is.

[Hero of Time]

DaFeliX schreef op donderdag 10 december 2020 @ 07:28:
[...]

Mosh is een leuke oplossing! Alleen geeft de TS geeft aan dat ie WinOS gebruikt, en volgens mij werkt Mosh niet op WinOS?

Als de de moeite had genomen om de link te volgen, had je met een klik erna gezien dat er gewoon een Windows versie is. Het is zelfs voor cygwin beschikbaar.

En zoals @Jazzy ook aangeeft, welkom in 2020, met WSL boeit het niet dat je Windows draait voor dit soort handige (Linux) tools. Heck, zelfs scp is native in Windows zonder WSL te moeten inschakelen!

[Jazzy]

MartinMeijerink schreef op donderdag 10 december 2020 @ 19:25:
Als je ook het beheer over de server hebt, dan kun je het ook aan de serverkant oplossen door in /etc/ssh/sshd_config de keywords ClientAliveInterval en ClientAliveCountMax te gebruiken.
Ik vind het bijzonder irritant om een verbinding kwijt te raken, vooral om de history die daarbij niet bijgewerkt wordt, daarom zet ik bij elke server die ik beheer en/of installeer deze regels in /etc/ssh/sshd_config:

code:

ClientAliveInterval 120
ClientAliveCountMax 720

(en dan wel ff de sshconfig reloaden)
Op deze manier blijft de verbinding minimaal 24 uur actief, tenzij er echt een storing op de lijn is.

Dank je. Ik had dit toevallig kort daarvoor gedaan en maar toch raak ik de verbinding kwijt. Nu net nog even een testje gedaan en heb het niet precies gemeten maar ik was de sessie al binnen tien minuten kwijt. Voor zover ik me dit herinner is het probleem ontstaan na een major Ubuntu update (14 naar 16?) maar ik heb er indertijd niet veel aandacht aan besteedt.

Blijft ook best wel lastige materie moet ik zeggen. Bijna alles wat ik Google met zowel 'ssh' als 'time out' bevat gaat over mensen die helemaal geen verbinding op kunnen zetten, echt meer dan 90% van de resultaten gaan niet over wat ik probeer op te lossen. Om het nog iets ingewikkelder te maken draait deze server dus in Azure, recent van Classic naar ARM gemigreerd. Dat betekent dus niet een enkele firewall tussen de client en de server maar een heel stuk Azure infra waaronder een Azure virtual network en load balancer.

Ik ga eerst maar eens een nieuw server uitrollen in hetzelfde virtual networkom even high-level te kijken of ik daarmee hetzelfde probleem heb. Vandaar uit maar verder troubleshooten.

[MartinMeijerink]

Jazzy schreef op vrijdag 11 december 2020 @ 13:41:
[...]
Dank je. Ik had dit toevallig kort daarvoor gedaan en maar toch raak ik de verbinding kwijt. Nu net nog even een testje gedaan en heb het niet precies gemeten maar ik was de sessie al binnen tien minuten kwijt. Voor zover ik me dit herinner is het probleem ontstaan na een major Ubuntu update (14 naar 16?) maar ik heb er indertijd niet veel aandacht aan besteedt.

Bijzonder... ik beheer tientallen linuxservers, van SuSE 8.0, SLES10.2, 10.3, 10.4, Ubuntu 10.04 t/m 20.04, Debian 8/9/10, Devuan tot ESXi-servers (ook ssh), die staan in verschillende datacenters, maar ook achter consumentenmodempjes, en deze oplossing werkt bij alle servers altijd (vaak stel ik het vantevoren al in, tot ik een keer bij een vers geïnstalleerde server de verbinding een keer kwijtraak, en dan denk ik "o ja, nog ff ClientAliveInterval en ClientAliveCountMax instellen", en dan is het ook daadwerkelijk opgelost).

Kan het zijn dat TCPKeepAlive invloed heeft, en toevallig gedisabled is (staat geloof ik standaard al aan, en ik weet ook eigenlijk niet of deze instelling veel uitmaakt)

Of het ligt mss aan je client, die dit mss niet ondersteunt? Mijn sshclients zijn gewoon de ingebouwde OpenSSH clients van Debian (thuis) en Devuan (werklaptop), wat ik zelf dus gebruik.

[Hero of Time]

Het zou mij ook niet verbazen als het in de infra van Azure ligt, ipv server en client. Zou namelijk zomaar kunnen dat de netwerkstack inactieve verbindingen, dus waar weinig data overheen gaat (en dat is nou eenmaal zo als je even niets doen met ssh, zelfs als er keepalive is), eruit trapt om te zorgen dat het totaal aantal verbindingen dat het bij moet houden niet te groot wordt waardoor anderen problemen kunnen ontstaan.

[DaFeliX]

Hero of Time schreef op donderdag 10 december 2020 @ 20:28:
[...]

Als de de moeite had genomen om de link te volgen, had je met een klik erna gezien dat er gewoon een Windows versie is. Het is zelfs voor cygwin beschikbaar.

En zoals @Jazzy ook aangeeft, welkom in 2020, met WSL boeit het niet dat je Windows draait voor dit soort handige (Linux) tools. Heck, zelfs scp is native in Windows zonder WSL te moeten inschakelen!

Ik had uiteraard die moeite genomen, en na klikken daar stond toch duidelijk "Mosh is free software, available for GNU/Linux, BSD, macOS, Solaris, Android, Chrome, and iOS.". Geen Windows. Sterker nog, toen ik een CTRL+F deed in de pagina kwam ik dit tegen:

Windows
Install Mosh for Chrome.

There is no "native" mosh executable for Windows available at this time.

Het had dus iig duidelijker in de infopagina van Mosh kunnen staan dat er andere manieren zijn om 't tin Windows te draaien.

Dat je het in WSL zou kunnen draaien had ik mij niet bedacht, want draai al jaren geen WinOS meer; dus die link had ik niet gemaakt

[ Voor 17% gewijzigd door DaFeliX op 12-12-2020 09:27 . Reden: dubbele quote weg ]

[Jazzy]

Nou, dit is nog niet opgelost. Wel weet ik inmiddels zeker dat het een configuratieprobleem is op deze server. Heb namelijk een tweede Ubuntu-VM uitgerold in hetzelfde netwerk en daar heb ik het probleem niet mee. En dat komt ook wel overeen met mijn herinnering dat het probleem ontstond na een major update van het OS.

Het goede nieuws is dat ik nu in ieder geval een server heb om mee te vergelijken en ik kan al zeggen dat het probleem ook niet in sshd_config zit. Enige verschil is dat ik op de probleemserver deze hebt toegevoegd, op de werkende server zijn de regels uitgecomment:

code:

ClientAliveInterval 3600
ClientAliveCountMax 3

En verder heb ik het issue met verschillende clients op verschillende computers dus het ligt ook niet aan de source-kant.

Tegen beter weten in heb ik in sshd_config toch maar eens TCPKeepAlive aangezet al zou dat alleen nodig moeten zijn om een probleem op te lossen met firewalls die idle sessies weggooien en we hadden al vastgesteld dat dit bij mij niet de oorzaak kan zijn. Zo maar eens testen of dit wat uitmaakt.

[Hero of Time]

Ik heb zakelijk meerdere Linux servers onder m'n hoede. Aantal op kantoor, geen problemen mee. Aantal met Ubuntu, eigenlijk ook geen probleem mee. Maar er is een groepje servers dat op een eigen platform staat en daar is het regelmatig bal. Het OS maakt ook niet uit, een CentOS 6 en een paar Debian machines variërend van 7 t/m 10. Allemaal hebben wel een keer dat de verbinding hangt en resulteert in een broken pipe.

Je zou dan al denken aan configuratie oid, maar dat is het dus niet. De exacte reden waarom weet ik niet (en ga ik eigenlijk ook geen moeite voor doen), maar het is iets te toevallig dat het alleen gebeurt als ik via de site-to-site verbinding naar het platform verbinding maak. Pak ik het externe IP adres, dat alleen vanaf ons kantoor bruikbaar is, is er niets aan de hand.

Ik zie al eerder, het is goed mogelijk dat het helemaal niet aan de server of client ligt, maar het netwerk zelf. En daar heb je geen invloed op.
Overigens, als je keepalive aanzet op de server, let even op dat je het ook op je client opgeeft.

[Jazzy]

Hero of Time schreef op vrijdag 18 december 2020 @ 17:39:
Ik zie al eerder, het is goed mogelijk dat het helemaal niet aan de server of client ligt, maar het netwerk zelf. En daar heb je geen invloed op.

Ik heb dus een tweede server in hetzelfde netwerk gezet om dat uit te sluiten.

[Hero of Time]

Jazzy schreef op vrijdag 18 december 2020 @ 17:48:
[...]

Ik heb dus een tweede server in hetzelfde netwerk gezet om dat uit te sluiten.

Jij ziet ze als naast elkaar. Maar staan ze ook echt fysiek op dezelfde host te draaien of zit er toch niet stiekem wat extra/andere netwerkapparatuur en verbindingen tussen en lijkt het alleen maar naast elkaar te staan?

[Jazzy]

Hero of Time schreef op vrijdag 18 december 2020 @ 17:50:
[...]

Jij ziet ze als naast elkaar. Maar staan ze ook echt fysiek op dezelfde host te draaien of zit er toch niet stiekem wat extra/andere netwerkapparatuur en verbindingen tussen en lijkt het alleen maar naast elkaar te staan?

Natuurlijk niet, maar ze zijn wel onder dezelfde configuratie gebracht en ik heb de probleemserver allang een keer naar een andere host laten migreren. Hoe Microsoft hun omgeving heeft ingericht lijkt het me uitgesloten dat van die miljoenen Linux-servers net alleen die van mij nu een paar jaar achter een verkeerd geconfigureerde firewall zou zitten.

[Jazzy]

Jazzy schreef op vrijdag 11 december 2020 @ 13:41:
[...]
Dat betekent dus niet een enkele firewall tussen de client en de server maar een heel stuk Azure infra waaronder een Azure virtual network en load balancer.

En dat laatste was dus het probleem. Vandaag toevallig om een heel andere reden even naar de netwerkconfiguratie gekeken en kwam in de eigenschappen van de NAT rules deze time-out setting tegen:



Dit bleek dus de oorzaak te zijn en verklaart ook waarom het nalopen van al die andere settings in het OS geen oplossing bood. Bij de testserver die ik uitgerold had heb ik er niet aan gedacht dat ik een load balancer gebruikte, vandaar dat ik op een schone server het probleem niet kon reproduceren.