2010-01-20 23:33:01 +0000 2010-01-20 23:33:01 +0000
236
236

Manier om ssh connectie timeout & bevriezen van GNOME Terminal te vermijden

Wanneer ik via ssh verbinding maak met bepaalde servers, treedt er een time-out op en “bevriest” de terminal (accepteert geen invoer, verbreekt de verbinding niet, kan niet Ctrl-C om het ssh-proces te stoppen of wat dan ook).

Dit zit in Ubuntu’s gnome-terminal hoewel het de terminal invoer/uitvoer lijkt te pauzeren, en geen invloed heeft op de werking van de GNOME Terminal software zelf. Dus minder een bug in gnome-terminal dan een vervelende inconsistentie met ssh.

Dus, is er een manier om te voorkomen/terug te krijgen van de terminal bij ssh-verbindingen die zijn uitgevallen?

Antwoorden (7)

259
259
259
2010-01-20 23:53:48 +0000

sshd (de server) sluit de verbinding als het een tijdje niets hoort van de client. Je kunt je client vertellen om af en toe een sign-of-life signaal naar de server te sturen.

De configuratie hiervoor staat in het bestand ~/.ssh/config. Om het signaal elke vier minuten naar de remotehost te sturen, zet je het volgende in je ~/.ssh/config.

Host remotehost
  HostName remotehost.com
  ServerAliveInterval 240

Dit is wat ik in mijn ~/.ssh/config heb staan.

Om het voor alle hosts aan te zetten gebruik je:

Host *
  ServerAliveInterval 240

Zorg er ook voor dat je chmod 600 ~/.ssh/config uitvoert, want het config bestand mag niet world-readable zijn.

250
250
250
2010-01-20 23:44:01 +0000

Druk achtereenvolgens op Enter, ~, . om de verbinding met een bevroren sessie te verbreken.

De paragraaf “ESCAPE CHARACTERS” in de ssh man page legt de onderliggende details uit.

39
39
39
2012-07-03 01:28:14 +0000

Ook al is dit geen direct antwoord op je vraag, het is zeer gerelateerd aan het probleem dat je hebt. In plaats van te proberen de verbinding in leven te houden (alle verbindingen sterven uiteindelijk) kun je terminal multiplexors gebruiken, zoals screen en tmux die de sessie in de achtergrond in leven houden zelfs als je terminal wordt verbroken.

In principe als je inlogt op de SSH server voer je direct screen uit die een nieuwe sessie aanmaakt en koppelt:

$ screen

Dan ga je verder en doe je je werk met de shell zoals je normaal zou doen. Als de verbinding wordt verbroken, als je weer online kunt komen en opnieuw verbinding kunt maken met de server over SSH, krijg je een lijst van de huidige sessies met:

$ screen -ls

Om opnieuw verbinding te maken met een sessie:

$ screen -r <session>

waarbij <session> de PID of een sessienaam is. Je wordt opnieuw verbonden met je sessie en je kunt verder gaan waar je gebleven was!

Je kunt zelfs de sessie loskoppelen en opnieuw verbinding maken om weer verder te gaan waar je gebleven was. Om de sessie te ontkoppelen gebruik je C-a gevolgd door C-d (dat is Control + A en dan Control + D).

Er is ook een eenvoudige online handleiding .

Het gebruik van screen en tmux op servers op afstand wordt beschouwd als een best practice en wordt zeer aangeraden. Sommige mensen gaan zelfs zo ver dat ze screen als hun standaard login shell hebben, dus als ze verbinding maken starten ze meteen een nieuwe screen sessie.

12
12
12
2014-02-06 14:13:27 +0000

Probeer -o ServerAliveInterval=30 toe te voegen aan uw verbindingsreeks (30 betekent 30 seconden en kan natuurlijk worden aangepast)

6
6
6
2016-02-12 22:45:27 +0000

Je kunt ook een idle timeout interval instellen vanaf SSH server kant:

Bestand: /etc/ssh/ssh_config

Inhoud:

ClientAliveInterval XX
ClientAliveCountMax YY

Dit werkt op precies dezelfde manier als de client instelling, maar de null-pakketten worden vanaf de server verstuurd, in plaats van vanaf de client.

Geëxtraheerd uit: http://www.sysadmit.com/2016/02/linux-y-vmware-ssh-evitar-desconexion.html

2
2
2
2015-12-17 02:19:43 +0000

Voor mensen die willen voorkomen dat de client de timing out in de eerste plaats.

Je zou kunnen proberen om ConnectTimeout 0 in te stellen in het configuratie bestand. De waarde 0 betekent dat de verbinding voor onbepaalde tijd in leven wordt gehouden, tenzij ze gesloten wordt.

je configuratie (of ssh_config) bestand zou er zo uit kunnen zien:

Host *
   ConnectTimeout 0
0
0
0
2020-01-24 11:55:41 +0000

In mijn geval was het probleem de grote MTU. Je kunt MTU op de router veranderen als je NAT gebruikt, maar ik verander MTU op de server:

sudo /sbin/ifconfig eth0 mtu 1036
sudo /etc/init.d/networking restart

Op Windows kun je deze sleutel ook verhogen:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpMaxDataRetransmissions"=dword:00000010