pourquoi mes sessions ssh gèlent-elles après un certain temps? [fermé]

10

Toutes mes excuses si ce n'est pas le bon endroit pour poser cette question.

J'ai régulièrement besoin de ssh sur différents serveurs. Maintenant, depuis ma machine domestique (linux mint), lorsque je me connecte via ssh, après un certain temps d'inactivité, mon shell ssh se fige, et il n'y a aucun moyen de le récupérer. La seule chose que je puisse faire est "~.", Qui me redonne au moins ma coquille d'initiation.

Lorsque je me connecte depuis d'autres emplacements sur les mêmes serveurs, il n'y a aucun problème. Cela pourrait-il être un problème avec mon FAI? Comment puis-je approfondir celui-ci?

C'est vraiment ennuyeux, car je dois rétablir les connexions ssh après le gel, revenir à l'endroit où j'étais et reprendre le travail. Merci

ssh

— Fabio
source

Avez-vous une adresse IP statique? Sinon, il se peut que votre FAI vous ait donné une adresse IP différente en cours de session - vérifiez vos journaux et voyez.

— user9517

Je n'ai pas d'adresse IP statique. Va vérifier

— Fabio

20

Votre NAT abandonne votre socket TCP après une période d'inactivité.

Votre client ssh peut éventuellement envoyer des noops périodiques au serveur, éliminant ainsi ce problème. Pour ce faire, ajoutez ceci à votre ~/.ssh/config:

Host *
  ServerAliveInterval 60

Vous pouvez également reconfigurer votre NAT pour ne pas expirer les éléments de sa table d'état aussi rapidement qu'il le fait actuellement.

En plus de ce qui précède, vous devez utiliser un multiplexeur de terminal pour vos sessions - quelque chose comme GNU Screen ou tmux. Avec l'un ou l'autre, vous pouvez récupérer votre session en cas de déconnexion.

— EEAA
source

Soit le NAT, soit tout pare-feu douloureusement erroné dans le chemin qui aime supprimer les sessions TCP inactives. Il n'y a aucune raison de supprimer les sessions TCP inactives, à part le manque de mémoire pour conserver les états, mais cela devrait se produire très rarement si vous dimensionnez et configurez correctement vos équipements. C'est une bonne fonctionnalité pour savoir si votre fournisseur / administrateur est compétent (ou non).

— zerodeux

0

Dans mon cas, le problème était en grande taille MTU. Vous pouvez changer MTU sur le routeur si vous utilisez NAT, mais je change MTU sur le serveur:

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

Sous Windows, vous pouvez également augmenter cette clé:

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

— Vasin Yuriy
source