Délai d'expiration Linux SSH [fermé]

J'ai du mal avec un couple de systèmes qui expirent après X minutes d'inactivité et je ne sais pas comment y remédier.

J'ai une boîte CentOS à mon bureau. Se connecter à SSH ne peut pas le toucher pendant 2 heures et son toujours vivant lorsque je lance quelque chose.

Cependant, connectez-vous à cette même boîte à la maison, et elle expirera parfois après quelques secondes, parfois après quelques minutes.

Je pense que c'est ma connexion Internet, mais si j'utilise activement la box, elle restera connectée.

Cependant, si j'arrête de taper sur Google, quelque chose affichera un message déconnecté et je dois me reconnecter.

Tout ce que je peux vérifier pour voir ce qui se passe?

La première chose que vous devez examiner est la définition de ServerAliveInterval. Cela doit être défini sur votre poste de travail.

Sur les clients Linux ou OSX, vous pouvez créer un fichier de configuration pour votre utilisateur sous ~ / .ssh / config sur votre poste de travail. Ajoutez la directive suivante. Dans mon cas, je veux que cela affecte tous les hôtes, alors je l'ai mis sous Host *.

Host *
    ServerAliveInterval 60

Cela enverra une instruction noop toutes les 60 secondes pour maintenir la connexion ouverte. Vous voudrez peut-être modifier la valeur pour répondre à vos besoins.

Côté serveur, assurez-vous que TCPKeepAlive est défini sur oui.

grep TCPKeepAlive /etc/ssh/sshd_config
TCPKeepAlive yes

Si vous êtes sous Windows, vous devrez faire référence à la documentation de votre client.

Linux n'expire pas les connexions SSH inactives. Vous pouvez laisser une connexion SSH ouverte indéfiniment, et tant qu'aucun des points de terminaison n'a été redémarré ou n'a obtenu une nouvelle adresse IP, la connexion fonctionnera toujours lorsque vous y accéderez après une longue période d'inactivité.

Cependant, s'il existe des boîtiers intermédiaires avec état (NAT, pare-feu, etc.), ceux-ci sont susceptibles d'expiration des connexions inactives. Le résultat de cela est que même si la connexion est vivante aux deux extrémités, les deux points de terminaison ne peuvent plus communiquer car le boîtier de médiation refuse de transmettre des paquets jusqu'à ce que le client SSH ouvre une nouvelle connexion.

Si vous connaissez le délai d' attente du middlebox, vous pouvez contourner le problème en configurant ClientAliveIntervaldans /etc/ssh/sshd_configsur le serveur ou ServerAliveIntervaldans ~/.ssh/configle client. Pour une détection optimale des connexions rompues, il est conseillé d'activer les deux paramètres. Cela détectera également les connexions rompues lorsque l'un des terminaux a été redémarré ou a obtenu une nouvelle adresse IP.

Étant donné que vous indiquez que le délai d'attente semble parfois être aussi bas que quelques secondes, cela peut ne pas être suffisant pour résoudre votre problème. Un délai d'attente apparent très faible peut être provoqué par un CGN surchargé ou mal configuré. Vous devez inspecter le trafic à différents points du chemin de communication afin de déterminer si un CGN est responsable des échecs.

S'il s'avère que les échecs sont causés par votre FAI faisant quelque chose de stupide, comme l'équilibrage de charge des connexions sur plusieurs CGN qui ne partagent pas l'état de connexion, vous ne pouvez pas résoudre le problème vous-même en modifiant simplement votre configuration SSH.

S'il vous arrive d'être coincé avec un FAI avec un CGN peu fiable qu'ils refusent de réparer, les seules options restantes que je connais sont soit de mettre à niveau le client et le serveur vers les versions du noyau avec prise en charge MPTCP ou d'utiliser une solution de tunnel conçue pour tolérer spontanément changements dans les mappages de ports sur le NAT.