Connexions SSH bloquées avec «Échec d'écriture: canal cassé»

12

Je me connecte à une box CentOS 5.5 via SSH depuis une machine Ubuntu 11.04.

La connexion semble fonctionner comme prévu lorsqu'elle est active (c.-à-d. Sans décalage ni perte), mais si elle reste inactive pendant un certain temps, elle se fige et ne répond plus. Finalement, le message d'erreur "Echec de l'écriture: canal cassé" sera renvoyé et je reviendrai à l'invite de ma machine locale.

Quel genre de choses puis-je faire pour aider à déboguer cela, découvrir ce qui se passe et résoudre ce problème? En tant que développeur, cela rend ma vie pénible de devoir se reconnecter constamment.

— Stephen RC
source

15

Il semble que la configuration SSHD de la boîte CentOS ne soit pas définie pour faire le client KeepAlive.

Déposez ces deux lignes dans votre configuration CentOS sshd (/ etc / ssh / sshd_config), redémarrez-la et profitez-en!

KeepAlive yes
ClientAliveInterval 60

Pendant que vous y êtes, je vous recommande d'utiliser gnu screenpour maintenir votre session en vie du côté de CentOS.

— yuriismaster
source

1

KeepAlive a été renommé TCPKeepAlive et peut être laissé à la valeur par défaut qui est oui. ClientAliveInterval devrait être suffisant. Tu vois man sshd_config.

— 2015 à 9h51

9

La vraie réponse est presque toujours que vous avez un périphérique NAT sur le chemin, généralement un pare-feu, dont les tables d'état ont un délai d'attente assez agressif. Parce que vous laissez votre connexion ssh inactive pendant quelques périodes, le périphérique NAT "oublie" le mappage entre votre adresse interne et le numéro de port source, et votre adresse éphémère externe NATted et numéro de port.

Lorsque vous essayez ultérieurement de faire quelque chose dans cette fenêtre ssh, une nouvelle paire adresse / port éphémère vous est affectée, à laquelle le serveur ssh de destination n'a aucune connaissance et ne répond pas; plus tard, un certain délai local est atteint et la connexion est interrompue par votre ordinateur local.

La solution pratique pour cela est de faire exactement ce que propose Yuriismaster: activer KeepAlives (qui assure un trafic régulier pour "chatouiller" cette entrée de la table d'état), et utiliser screendu côté distant (pour préserver l'état en cas de chute des choses). Je ne poste cette réponse que parce que vous avez demandé ce qui se passe, ainsi que ce qu'il faut faire à ce sujet. Espérons que cela clarifie pourquoi les suggestions de Yuriismaster sont bonnes.

— Chapelier Fou
source

C'est parfaitement logique! Nous avons un NAT avec une configuration DMZ pour cette boîte. Je vais essayer la configuration du délai d'attente et voir si cela fonctionne pour moi. Merci :)

— Stephen RC

J'accepte le vôtre car vous m'avez aidé à comprendre les raisons du problème. Mais le crédit doit aller à @yuriismaster pour le correctif.

— Stephen RC

Valorin: absolument, il le fait, et il était le premier. Franchement, je pense qu'il mérite l'acceptation plus que moi; mais c'est votre question, donc ça devrait aller comme bon vous semble. Merci pour les commentaires, de toute façon.

— MadHatter