Comment empêcher “Échec de l'écriture: tuyau cassé” sur la connexion SSH?


283

Que puis-je faire pour configurer SSH sur le client et les serveurs pour éviter les Write Failed: broken pipeerreurs? Cela se produit souvent si vous mettez en veille votre ordinateur client et que vous le reprenez plus tard.


8
Rien vraiment. La session a été interrompue et la sécurité de la session a été compromise. Si vous ne mettez pas la composition en veille, vous pouvez définir un délai de maintien en vie pour que le client transmette au serveur un rythme cardiaque en vie, mais si le système se met en veille, vous ne pouvez rien faire.
darkdragn

3
Dans ce cas, je cherche quelque chose qui me permettrait de relancer une connexion SSH cassée (probablement sur le code de sortie) et de restaurer en utilisant screen?
sorin

4
Vous vous trompez: j'ai DEUX ordinateurs clients connectés au serveur SAME. L'un d'eux est ubuntu 12.10, Quantal, dont le client SSH fonctionne bien et conserve la connexion pendant des heures. L'autre est Ubuntu 14.10, Utopic, juste à côté de l'autre et dans une nouvelle installation; après quelques minutes, il se bloque avec ce message. Les autres fonctions réseau de la machine ne sont pas interrompues. Donc non, ce n'est ni un problème de réseau, ni un problème de serveur, mais un problème logiciel spécifique du client SSH, qui PEUT être résolu, contrairement à ce que "darkdragan" ose dire, "rien ne peut être fait".
David L

2
Et en effet, comme je le disais: les gens parlent trop quand ils disent "rien ne peut être fait", tout comme @darkdragn a osé. J'ai lu la réponse d'Aram Kocharyan et je l'ai appliquée: il y a 20 minutes ... je me suis rendu compte que dans mon ancien Quantal Ubuntu 12.10, j'avais appliqué cette instruction dans ce fichier [je viens de vérifier], il y a deux ans, et c'était la raison de la stabilité là-bas. Je l'ai fait ici, et depuis 20 minutes, la connexion est stable depuis. Alors s'il vous plaît, les gens: abstenez-vous lorsque vous osez penser que "rien ne peut être fait", et abstenez-vous encore davantage lorsque vous essayez de laisser ce message à d'autres personnes.
David L

11
@ DavidL, vous devriez mieux lire les questions avant de parler. Votre problème n'est pas le même que celui du PO, qui mentionne clairement de mettre l'ordinateur en veille. D’ailleurs, une seule des réponses ("mosh") a été postée deux ans après la question. Cependant, les autres réponses constituent la deuxième meilleure solution, à savoir proposer des solutions aux cas qui peuvent être résolus plus facilement, comme le vôtre. Détendez-vous, ne soyez pas trop stressé, le fait de faire des reproches ne sert à rien ici ...
msb

Réponses:


266

J'ai essayé ceci /etc/ssh/ssh_configpour Linux et Mac:

Host *
ServerAliveInterval 120

C'est la fréquence à laquelle, en secondes, il doit envoyer un message keepalive au serveur. Si cela ne fonctionne pas, entraînez un singe à appuyer sur Entrée toutes les deux minutes pendant que vous travaillez.

Vous pouvez définir soit ServerAliveIntervaldans /etc/ssh/ssh_configl'ordinateur client, soit ClientAliveIntervaldans /etc/ssh/sshd_configl'ordinateur serveur. Essayez de réduire l’intervalle si vous obtenez toujours l’erreur.

La configuration pour un seul utilisateur peut être définie dans un fichier à la ~/.ssh/configfois côté serveur et côté client. Assurez-vous que le fichier dispose des autorisations appropriées chmod 644 ~/.ssh/config.


4
Je ne suis pas sur un Mac, mais Ubuntu 12.04 et le fichier pour ce système d'exploitation semble également être ~ / .ssh / config.
H2ONaCl

5
OS X 10.8.4 génère une erreurBad configuration option: ClientAliveInterval
ohho

3
Je reçois la même Bad configuration optionerreur sur OSX 10.8.4.
Nick Heiner

10
Généralement, vous mettez ces deux commandes dans différentes parties du système. ServerAliveInterval uniquement du côté client OSX ... et uniquement ClientAliveInterval du fichier de configuration sshd ...
ftrotter

2
Mon singe m'a dit: haut [ENTER] « Pourquoi ne pas vous tapez « »
augusto

85

Les sessions SSH peuvent être interrompues pour des raisons nombreuses et probablement inévitables.

Un utilitaire utile qui peut être utilisé pour atténuer les problèmes causés par cela s’appelle screen. Screen est un utilitaire puissant qui vous permet de contrôler plusieurs terminaux qui resteront en vie indépendamment de la session ssh. Par exemple, si vous exécutez screenune session SSH, un nouveau terminal sera ouvert et vous pourrez l'utiliser pour exécuter des travaux. Disons que votre session SSH meurt dans le processus. Courir screen -densuite screen -rrouvrira la dernière session et vous pourrez continuer à partir de là. Assurez-vous de lire une partie de la documentation avant de l’utiliser.


5
C’est probablement la meilleure réponse, je ne sais pas pourquoi il n’est pas majoré. Les autres "correctifs" sont utiles dans le cas particulier où vous voudriez réellement maintenir une connexion SSH, mais dans la plupart des cas d'utilisation, j'imagine que le vrai problème est que les processus prévus continuent de s'exécuter, quels que soient les problèmes de connexion client / serveur. .
Paul McMurdie

16
J'ajouterais aussi Tmux comme alternative à screen. Je le trouve plus polyvalent et stable que l'écran.
Vendredi

2
laissez simplement ceci ici pour référence future - vous pouvez facilement exécuter screen -d -rpour récupérer votre dernière session.
doplumi

2
Ou simplement screen -dr. Ou screen -xselon ce que vous comptez faire. Le fait est qu'il faut savoir ce que font tous ces commutateurs pour pouvoir utiliser ceux qui conviennent et ne pas suivre aveuglément les suggestions des internautes. Il y a un résumé compact disponible ici: ss64.com/bash/screen.html
flith

Ce n'est pas une réponse au problème
user3728501 Le

46

Configuration client

Essayez de créer le fichier:

~/.ssh/config

Ajoutez le contenu:

Host *
  ServerAliveInterval 30
  ServerAliveCountMax 5

Maintenant ssh sur votre serveur et voyez si votre problème est résolu. L'option ClientAliveInterval n'est utile que lors de la configuration du serveur ssh (c'est-à-dire sshd), elle ne change rien du côté du client ssh. Ne l'utilisez donc pas dans le fichier de configuration ci-dessus.

Ceci enverra un signal bonjour au serveur si aucun paquet n'a été reçu au cours des 30 secondes précédentes (comme spécifié ci-dessus). Toutefois, si le nombre de signaux consécutifs Bonjour-êtes-vous-il atteint ServerAliveCountMax, ssh se déconnectera du serveur. La valeur par défaut est 3 (donc 3 * 30 = 90 secondes sans activité du serveur), augmentez-la si cela convient à vos besoins. Il y a beaucoup plus d'options de configuration dans le fichier .ssh / config et vous pouvez lire:

Utilisation d'un fichier de configuration SSH

Pour plus d'informations sur d'autres options. Vous pouvez ne pas vouloir appliquer cela à tous les serveurs auxquels vous vous connectez auxquels cet exemple le fera. Ou limitez-le à un serveur particulier en remplaçant la ligne Host *par Host <IP>(remplacez par une adresse IP, reportez-vous à la page de manuel ssh_config).

Configuration du serveur

De même, vous pouvez dire au serveur d'être doux avec vos clients. Le fichier de configuration est /etc/ssh/sshd_config.

ClientAliveInterval 20
ClientAliveCountMax 5

Vous pouvez le désactiver en définissant ClientAliveIntervalsur 0ou sur ClientAliveIntervalet ClientAliveCountMaxen définissant une inactivité maximale du client ssh sans répondre aux sondes. L'un des avantages de ces paramètres par rapport à TCPKeepAlive est que les signaux sont envoyés via les canaux cryptés, ce qui réduit les risques d'usurpation d'identité.


Ça ne marche pas Je suis à nouveau confronté à la même erreur.
user997704

3
Essayez-le directement à partir de la ligne de commande et descendez plus bas: ssh -o ServerAliveInterval = 5 utilisateur @ hôte
Matt

Essayé que trop .. ne fonctionne pas. Je ne sais vraiment pas ce qui se passe avec mon système
utilisateur997704

2
C'est ClientAliveCountMax, PAS ClientAliveMaxCount
David G

@DavidG Veuillez éditer la réponse avec vos corrections.
CivMeierFan

23

Je suis en train de mettre à jour un serveur Ubuntu de lucide à précis et j'ai perdu la connexion SSH au milieu de la mise à niveau avec le message "Échec de l'écriture. Tube de Brocken". ClientAliveInterval et ServerAliveInterval n'ont rien fait. La solution consiste à activer les options TCPKeepAlive dans le client ssh:

TCPKeepAlive yes

dans

/etc/ssh/ssh_config

20

Pour le client, éditez votre fichier ~/.ssh/config(ou /etc/ssh/ssh_config) comme suit:

Host *
  TCPKeepAlive yes
  ServerAliveInterval 120

TCPKeepAlive - Spécifie si le système doit envoyer des messages de maintien TCP de l'autre côté. S'ils sont envoyés, la mort de la connexion ou le crash de l'une des machines sera correctement constaté. Cependant, cela signifie que les connexions mourront si la route est interrompue temporairement et que certaines personnes la trouvent ennuyeuse (la valeur par défaut est "oui").

ServerAliveInterval - Définit un intervalle de délai d'attente en secondes à l'issue duquel, si aucune donnée n'a été reçue du serveur, ssh (1) envoie un message via le canal chiffré pour demander une réponse au serveur. La valeur par défaut est 0, indiquant que ces messages ne seront pas envoyés au serveur.


Pour le serveur, éditez votre /etc/ssh/sshd_configcomme:

ClientAliveInterval 600
ClientAliveCountMax 0

Si vous voulez que le client ssh quitte (temporisation) automatiquement après 10 minutes (600 secondes).

ClientAliveCountMax - Ceci indique le nombre total de messages checkalive envoyés par le serveur ssh sans obtenir de réponse du client ssh. La valeur par défaut est 3.

ClientAliveInterval - Cela indique le délai d'attente en secondes. Après x secondes, le serveur ssh enverra un message au client lui demandant de répondre. Deafult vaut 0 (le serveur n'enverra pas de message au client à vérifier).


Voir aussi: Que font les options ServerAliveIntervalet ClientAliveIntervaldans sshd_config, précisément?


Définir un ServerAliveCountMax supérieur à celui par défaut sur le client devrait également aider à maintenir la connexion active pour les connexions lentes.
Jonnyjandles

17

J'aime absolument Mosh. Je me connecte fréquemment à un serveur, ferme mon ordinateur portable et vais dans un café, l'ouvre et continue comme si rien n'avait changé.

Mosh (shell mobile)

Application de terminal distant qui permet l' itinérance , prend en charge la connectivité intermittente et fournit une modification intelligente de l'écho local et de la ligne des touches de l'utilisateur.

Mosh remplace SSH. Il est plus robuste et réactif, en particulier via les liaisons Wi-Fi, cellulaires et longue distance.

Mosh est un logiciel gratuit, disponible pour GNU / Linux, FreeBSD, Solaris, Mac OS X et Android.


6

Pour moi, je me sentais Write failed: Broken pipemême quand je tapais activement dans vim ou à l’invite du shell. Je ne pouvais pas non plus naviguer sur Internet localement pendant un moment. (Je me connectais à distance à Ubuntu via Terminal.)

D'autres membres de mon réseau diffusent beaucoup de vidéos de Netflix et d'autres lieux. Je ne peux pas le prouver, mais je soupçonne que c'est un problème de FAI ou de routeur. Par exemple, Verizon et Netflix se pointent du doigt pour résoudre les problèmes de réseau de leurs clients.

Si vous disposez d'une connexion à distance et diffusez de la vidéo ou de la musique en streaming avec une connexion SSH ou Telnet simultanée, il est inévitable qu'à un moment donné, vous recevez un message de canal cassé. La mise à niveau du forfait haut débit de mon FAI semblait rendre ma connexion interrompue moins fréquente.



3

J'ai un script sur le serveur distant qui ne semble jamais échouer, quel que soit le client ou le serveur de configuration SSH.

#!/bin/bash
while true; do date; sleep 10; done;

Enregistrez-le dans un fichier dummy.sh et exécutez-le rapidement avant de réduire la fenêtre ou de vous en éloigner. Il continuera à imprimer l’horodatage actuel sur le serveur et maintiendra votre connexion en vie tant que la connexion n’est pas abandonnée pour une autre raison. Lorsque vous revenez à ce terminal, appuyez simplement sur CTRL + C et continuez à travailler.


9
ou tout simplement laisser topcourir
Eben Geer

1

Vous pouvez ajouter ces arguments chaque fois que vous appelez ssh: -o ServerAliveInterval=15 -o ServerAliveCountMax=3

Vous n'avez pas besoin de modifier les fichiers / etc / ssh / * config si vous le faites.

Vous pouvez créer un alias ou une fonction ou un script bash pour faciliter la tâche.

Par exemple, ces fonctions bash, vous pouvez ajouter dans votre .bashrc, do_ssh est utilisé manuellement pour activer keepalives. do_ssh_pty est utilisé dans les scripts pour définir pty et éviter les invites.

do_ssh() {
    ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=3 $*
}

do_ssh_pty() {
    ssh -tt -o "BatchMode=yes" -o "StrictHostKeyChecking=no" -o ServerAliveInterval=15 -o ServerAliveCountMax=3 $*
}

Maintenant do_ssh user@hostpeut être utilisé ou do_ssh user@host <args> <command>et Keepalives sera actif.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.