Que puis-je faire pour configurer SSH sur le client et les serveurs pour empêcher Write Failed: broken pipe des erreurs? Cela se produit souvent si vous mettez votre ordinateur client en veille et que vous le reprenez plus tard.
J'ai essayé ceci dans /etc/ssh/ssh_config pour Linux et Mac:
Host *ServerAliveInterval 120C'est à quelle fréquence, en quelques secondes, il devrait 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 ServerAliveInterval dans /etc/ssh/ssh_config de la machine cliente ou ClientAliveInterval dans /etc/ssh/sshd_config de la machine 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 ~/.ssh/config côté serveur et côté client. Assurez-vous que le fichier dispose des autorisations correctes chmod 644 ~/.ssh/config.
Les sessions SSH peuvent se rompre pour de nombreuses raisons, peut-être 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 screen dans une session ssh, vous verrez un nouveau terminal ouvert et vous pourrez l'utiliser pour exécuter des tâches. Disons que votre session ssh meurt dans le processus. Exécuter screen -d puis screen -r rouvrira la dernière session et vous pourrez continuer à partir de là. Assurez-vous de lire une partie de la documentation avant de l'utiliser.
Configuration du client
Essayez de créer le fichier:
~/.ssh/configAjouter le contenu:
Host * ServerAliveInterval 30 ServerAliveCountMax 5Maintenant, connectez-vous à 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 (alias sshd), elle ne change rien du côté client ssh, alors ne l'utilisez pas dans le fichier de configuration ci-dessus.
Cela enverra un signal hello-are-you-there au serveur si aucun paquet n'a été reçu au cours des 30 secondes précédentes (comme spécifié ci-dessus). Cependant, si le nombre de signaux hello-are-you-there consécutifs atteint ServerAliveCountMax, ssh se déconnectera du serveur. Cette valeur est définie par défaut sur 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 à la .fichier ssh / config et vous pouvez lire:
Utilisation d'un fichier de configuration SSH
Pour plus d'informations sur les autres options. Vous ne voudrez peut-être pas l'appliquer à chaque serveur auquel vous vous connectez et auquel cet exemple sera appliqué. Ou restreignez-le uniquement à un serveur particulier en remplaçant la ligne Host * avec Host <IP> (remplacer par une adresse IP, voir 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 20ClientAliveCountMax 5Vous pouvez soit le désactiver en définissant ClientAliveInterval de 0 ou tweak ClientAliveInterval et ClientAliveCountMax pour définir 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, il est donc moins probable qu'ils soient usurpables.
Je suis en train de mettre à niveau à distance un serveur Ubuntu de lucid vers precise et j'ai perdu la connexion ssh au milieu de la mise à niveau avec le message "L'écriture a échoué. Tuyau cassé". ClientAliveInterval et ServerAliveInterval n'ont rien fait. La solution consiste à activer les options TCPKeepAlive dans le ssh client:
TCPKeepAlive yesdans
/etc/ssh/ssh_configJ'espère que cela vous aidera
Pour le client, modifiez votre ~/.ssh/config (ou /etc/ssh/ssh_config) classez comme suit:
Host * TCPKeepAlive yes ServerAliveInterval 120TCPKeepAlive - Spécifie si le système doit envoyer des messages TCP keepalive 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 remarqué. Cependant, cela signifie que les connexions mourront si la route est temporairement en panne, et certaines personnes trouvent cela ennuyeux (La valeur par défaut est "oui").
ServerAliveInterval - Définit un intervalle de délai d'attente en secondes après lequel, si aucune donnée n'a été reçue du serveur, ssh(1) enverra un message via le canal crypté pour demander une réponse au serveur. La valeur par défaut est 0, ce qui indique que ces messages ne seront pas envoyés au serveur.
Pour le serveur, modifiez votre /etc/ssh/sshd_config comme:
ClientAliveInterval 600ClientAliveCountMax 0Si vous souhaitez que le client ssh se ferme automatiquement (délai d'expiration) 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 - Ceci indique le délai d'attente en secondes. Après x nombre de secondes, le serveur ssh enverra un message au client demandant une réponse. Deafult vaut 0 (le serveur n'enverra pas de message au client pour vérification.).
Voir aussi: Quelles sont les options ServerAliveInterval et ClientAliveInterval dans sshd_config faire, précisément?
J'adore Mosh. Je me connecte fréquemment à un serveur ssh, ferme mon ordinateur portable et vais dans un café, l'ouvre et continue comme si de rien n'était.
Mosh (coque mobile)
Application de terminal distant qui permet itinérance, soutien connectivité intermittente, et fournit intelligent écho local et l'édition en ligne des frappes de l'utilisateur.
Mosh remplace SSH. Il est plus robuste et réactif, en particulier sur les liaisons Wi-Fi, cellulaires et longue distance.
Mosh est un logiciel libre, disponible pour GNU / Linux, FreeBSD, Solaris, Mac OS X et Android.
Pour moi, je recevais Write failed: Broken pipe même lorsque je tapais activement dans vim ou à l'invite du shell. Je ne pouvais pas naviguer sur Internet localement pendant un certain temps non plus. (Je me connectais à distance à Ubuntu en utilisant Terminal.)
D'autres sur mon réseau diffusent beaucoup de vidéos de Netflix et d'autres endroits. 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 les problèmes de réseau de leurs clients.
Si vous disposez d'une connexion à distance et que vous diffusez des vidéos ou de la musique en continu avec une connexion SSH ou telnet simultanée, il est inévitable qu'à un moment donné, vous receviez un message de tuyau cassé. La mise à niveau de mon forfait haut débit FAI semblait rendre ma connexion interrompue moins fréquente.
J'ai posté ma réponse ici, car ce n'était pas une machine virtuelle Ubuntu.
ssh -o IPQoS=throughput user@hostJ'ai un script sur le serveur distant qui ne semble jamais échouer, quel que soit le client ou le serveur de configuration SSH.
#!/bin/bashwhile true; do date; sleep 10; done;Gardez-le pour certains dummy.sh fichier 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 interrompue pour une autre raison. Lorsque vous revenez à ce terminal, appuyez simplement sur CTRL + C et continuez à travailler.
Vous pouvez ajouter ces arguments à chaque fois que vous appelez ssh: -o ServerAliveInterval=15 -o ServerAliveCountMax=3
Vous n'avez pas besoin d'éditer les fichiers de configuration /etc/ssh/*si vous faites cela.
Vous pouvez créer un alias ou une fonction ou un script bash pour faciliter cela.
Par exemple, ces fonctions bash, vous pouvez les ajouter dans votre .bashrc, do_ssh est utilisé manuellement pour activer keepalives. do_ssh_pty est utilisé dans les scripts pour définir le 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@host peut être utilisé ou do_ssh user@host <args> <command> et keepalives sera actif.
@DavidL vous devriez mieux lire les questions avant de râler. Votre problème n’est pas le même que celui du PO, qui mentionne clairement la mise en veille de l’ordinateur. Lequel d’ailleurs une seule des réponses adresse (“mosh”), et il a été posté 2 ans après la question. Cependant, les autres réponses font la meilleure chose suivante, qui propose des solutions à des cas qui peuvent être résolus plus facilement, comme le vôtre. Détendez-vous, ne soyez pas si stressé, les diatribes ne font aucun bien ici…
Rien vraiment. La session a été interrompue et la sécurité de la session a été compromise. Si vous ne mettez pas la maquette en veille, vous pouvez définir un temps de maintien en vie pour que le client envoie un battement de cœur au serveur, mais si le système se met en veille, il n’y a rien à faire.
Vous vous trompez: j’ai DEUX machines clientes de bureau qui se connectent au MÊME serveur. L’un est ubuntu 12.10, Quantal, dont le client SSH fonctionne bien et maintient la connexion pendant des heures. L’autre est Ubuntu 14.10, Utopique, juste à côté de l’autre et dans une nouvelle installation; après quelques minutes, il se bloque avec ce message. Le reste des 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 spécifique de logiciel CLIENT SSH, qui PEUT ÊTRE résolu, contrairement à ce que “darkdragan” ose dire, que “rien ne peut être fait”.
Dans ce cas, je cherche quelque chose qui me permettrait de relancer une connexion ssh interrompue (basée probablement sur le code de sortie) et de restaurer en utilisant screen?
Et en effet, comme je l’ai dit: 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… J’ai réalisé que dans mon ancien Ubuntu 12.10 Quantal, 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 au cours de ces 20 dernières minutes, la connexion est stable depuis lors. Alors s’il vous plait, les gens: abstenez-vous lorsque vous osez penser que “rien ne peut être fait”, et abstenez-vous encore plus lorsque vous essayez de laisser ce message à d’autres personnes.
@DavidL D’accord pour dire que le non peut être ennuyeux, en particulier d’une position d’ignorance.
Cependant, il semble aussi que vous l’ayez pris un peu personnellement (c’est-à-dire un peu râleur). darkdragn prob signifiait bien
Les sessions SHH font pivoter les clés de cryptage au fil du temps, pour éviter les attaques par force brute à longue échelle de temps. Sleep / resume va casser cette sécurité et la connexion.
Rien n’est aussi agréable que la situation suivante. Une personne qui dit: “Cela ne peut pas être fait / Rien ne peut être fait”, est répondue ou interrompue par quelqu’un qui dit: "regardez… C’est fait, et c’était facile " @darkdragn
Le même problème dans le réseau lorsque deux périphériques avec la même adresse.
Éteignez l’un d’eux et le problème est résolu.