Pourquoi mon délai d'attente ssh varie-t-il selon l'emplacement du réseau?

15

Lorsque je suis connecté à l'un de nos serveurs de bureau (qui exécutent Fedora 10) depuis chez moi, ma session expire après une période d'activité assez courte (environ 5 minutes). J'ai essayé d'utiliser TcpKeepAlivedu côté client, sans résultat.

Ce que je ne comprends pas, c'est que si je suis au bureau sur le réseau local de l'entreprise, je peux laisser une session inactive toute la journée sans que cela ne se termine, donc le comportement semble dépendre de mon emplacement.

Des idées pourquoi cela se produit et comment éviter les délais d'attente lorsque je ne suis pas sur le réseau local? J'utilise le client Terminal sur Mac OSX si cela aide.

MISE À JOUR - La suggestion de Dave Drager d'utiliser l' ServerAliveIntervalensemble avec une valeur non nulle a TcpKeepAlive=nofonctionné pour moi. Concernant certaines des autres réponses, les ClientAlive... paramètres ne sont pas acceptés par le client Mac OSX SSH.

linux ssh mac-osx fedora timeout gareth_bowles
la source

Réponses:

6

Il existe un bon résumé de ce problème ici .

Ils recommandent:

ssh -o TCPKeepAlive=yes

ou:

ssh -o TCPKeepAlive=no -o ServerAliveInterval=15

Cependant, j'ai un problème sur mon site de travail où je suis déconnecté des sessions, où à la maison, ça va. Je crois que mon pare-feu (SonicWall) peut être en train de flipper avec TCPKeepAlive, peut-être à cause de NAT.

Mon client SSH, SecureCRT, a heureusement une option pour un protocole "NO-OP", qui je crois envoie essentiellement une commande qui ne fait rien au serveur. En l'activant manuellement, je peux rester connecté. Je ne sais pas ce que le client terminal MacOSX a qui est similaire à cela. Il y a un résumé sur la façon d'implémenter "NO-OP" en ligne de commande.

Enfin, vous souhaiterez peut-être utiliser Wireshark ou un autre renifleur pour surveiller votre connexion TCP réelle et découvrir ce qui se passe avec. Ce serait la dernière façon de voir pourquoi il se déconnecte encore de temps en temps.

Dave Drager
la source
Merci, Dave - l'option ServerAliveInterval a très bien fonctionné.
gareth_bowles
@Dave J'avais entendu dire que certains administrateurs de serveur désapprouvaient cette pratique car cela pouvait être (a) un risque pour la sécurité, ou (b) une charge de serveur injustifiée. L'une ou l'autre de ces préoccupations est-elle valable, IYHO?
Jonathan Day
Il s'agit d'un paramètre sur le point de terminaison client, donc bien que si vous êtes dans un environnement hostile, cela puisse augmenter la capacité de quelqu'un à vous usurper, il est très peu probable qu'il ait un impact sur la sécurité de la connexion. Je ne peux pas non plus vraiment voir cela causer une charge supplémentaire.
Dave Drager
@Dave: j'ai entré cette commande mais j'obtiens ce qui suit, utilisation: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:] port] [-e escape_char] [-F configfile] [- I pkcs11] [-i fichier_identité] [-L [adresse_bind:] port: hôte: port hôte] [-l nom_connexion] [-m spéc_mac] [-O ctl_cmd] [option -o] [-p port] [-R [ bind_address:] port: host: hostport] [-S ctl_path] [-W host: port] [-w local_tun [: remote_tun]] [user @] hostname [commande]
user1050619
Ce correctif a également fonctionné pour PuTTY. La seule option que je devais définir était dans Connection -> Seconds between Keepalive: 15. La session SSH est bien vivante depuis plus de 8 heures (Comcast), alors qu'elle se déconnectait généralement en <30 minutes.
Dan Dascalescu
2

C'est probablement parce que lorsque vous vous connectez depuis votre domicile, vous passez par un pare-feu qui ferme la session TCP après un petit laps de temps. Mais TcpKeepAlive devrait éviter cela. Avez-vous activé TcpKeepAlive côté client ou côté serveur?

rayon
la source
J'ai fait TcpKeepAlive du côté client (dans mon ~ / .ssh / config) - je pensais que cela résoudrait les problèmes de pare-feu local, mais il arrive toujours à expiration.
gareth_bowles
Par défaut, il est "activé" côté serveur, mais vérifiez le sshd_config pour voir s'il n'a pas été désactivé.
rayon
Certains pare-feu déconnectent une connexion TCP après un certain temps, même s'ils ne sont pas inactifs.
TomOnTime
Certains pare-feu déconnectent une connexion TCP après un certain temps, même s'ils ne sont pas inactifs. La façon de détecter cela est de voir si vous êtes déconnecté de manière cohérente.
TomOnTime
Voici les paramètres que j'ai utilisés pour corriger: TCPKeepAlive no, ClientAliveInterval 300, ClientAliveCountMax 3
Matt Simmons
2

Je reçois cela tout le temps sur ma connexion Comcast. Le problème est que l'intervalle de maintien en vie de votre client SSH est trop long pour le délai configuré dans votre chemin réseau. Si vous êtes sous Linux, vous pouvez modifier les valeurs ServerAliveIntervalet ServerAliveCounterpour qu'elles soient inférieures à leurs valeurs par défaut. Cette valeur est définie en secondes. Le fichier de configuration à l'échelle du système se trouve (généralement) dans /etc/ssh/ssh_config. La définition de ces deux ET TcpKeepAlivedevrait aider à maintenir votre connexion.

sysadmin1138
la source
1

Comme le dit radius, certains pare-feu à état complet «oublient» une connexion après un certain temps (généralement configurable) et ne permettent plus de communication pour la connexion; ils s'attendent à ce que la connexion démarre avec un TCP SYN (je fais référence à votre communication SSH ici).

Il y a une autre possibilité. Le chemin d'accès réseau entre votre domicile et votre bureau peut présenter des pertes (du type paquet). Lorsque vous essayez de taper sur le client SSH, si votre lien est bloqué depuis un certain temps, le client peut abandonner et échouer.

La configuration Keepalive sur le client gérera le premier cas ici mais ne peut pas aider dans le second cas. Le pare-feu se trouve généralement sur le périmètre de votre bureau et peut donc être configurable. Cela aiderait également sur le premier point.

Pour vérifier si vous rencontrez des pertes de liaison intermittentes, vous pouvez garder un «ping» actif en arrière-plan depuis votre ordinateur client.

nik
la source
0

Vous pouvez également ajouter les paramètres suggérés par d'autres en tant que paramètres par défaut dans votre ~/.ssh/configfichier, afin que vous n'ayez pas à les transmettre à sshchaque fois que vous établissez une connexion:

nano ~/.ssh/config et ajouter:

TCPKeepAlive=no
ServerAliveInterval=15
Dan Dascalescu
la source