J'ai lu les différents articles pour ce problème et je peux vérifier que l'utilisation d'un -t lors de l'exécution d'une commande ssh à distance force l'allocation de tty et permet l'achèvement de la commande. Cependant, le problème que j'ai est que douze heures avant ce point, j'ai eu un accès gratuit à ce serveur. Maintenant, sans changements connus, je ne peux plus me connecter.Git: L'extrémité distante a raccroché de manière inattendue
Je peux me connecter à ce serveur toute la journée sans problème. Toutefois, lorsque j'essaie d'exécuter une commande à distance, disons que le nom de serveur ssh 'ls/var/tmp', la connexion se déconnecte sans une erreur enregistrée sur le serveur.
Alors, qu'est-ce qui a changé?
Voici ma config git:
wwwin-svn-sjc:142> git config --list
receive.denynonfastforwards=false
user.name=joericks
[email protected]
http.postbuffer=52428800000
Je cogné http.postbuffer à un niveau obscène pour éliminer cela comme un problème potentiel. Je peux passer à un autre compte et cloner ces dépôts à partir de ce serveur en utilisant exactement les mêmes URLs sans problème. Les autres administrateurs et utilisateurs ne sont pas affectés non plus. Lorsque vous êtes sur le serveur et que vous utilisez le compte de problème, je peux ajouter, valider et envoyer des messages aux serveurs distants toute la journée sans problème. En dehors de Git, je peux forcer l'exécution de commandes ssh distantes en utilisant ssh -t mais c'est vraiment un travail et mes utilisateurs n'accepteront pas de travail si je ne peux pas leur dire pourquoi/comment cela se passe ou qu'est-ce qui l'a causé? J'ai soufflé mes paramètres de configuration .ssh et les clés ssh. Tenter de cloner sans les clés fait apparaître l'invite de mot de passe requise et le même échec.
J'ai vérifié que les autorisations étaient sain d'esprit pour les fichiers .ssh et répertoires parents:
> ls -alrt
total 712
-rw-r--r-- 1 58 Sep 15 17:02 config
-rw-r--r-- 1 681826 Mar 7 12:24 known_hosts
-rw------- 1 1675 Mar 7 15:22 id_rsa
-rw-r--r-- 1 405 Mar 7 15:22 id_rsa.pub
drwx------ 2 4096 Mar 7 15:23 .
-rw-r--r-- 1 405 Mar 7 15:23 authorized_keys
drwxr-xr-x 78 24576 Mar 7 15:25 ..
J'ai volontairement gardé ma config ssh aussi simple que possible:
>cat config
ForwardX11 yes
ForwardAgent yes
StrictHostKeyChecking no
En utilisant -vvv ssh I reviens avec cette sortie. (Tronquée par souci de concision)
A a interrompu la connexion au serveur problématique:
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
Un bon appel à un serveur fonctionnel:
debug3: packet_send2: adding 48 (len 67 padlen 13 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending command: ls
debug2: channel 0: request exec confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
11:43
À ce stade, je suis vraiment à une perte et, malheureusement, J'ai au moins un autre utilisateur qui rencontre ce même problème. Quelqu'un a-t-il déjà trouvé ce qui cause exactement ce problème (l'allocation de tty échoue à moins d'être forcé) et à court d'un redémarrage du système, a trouvé une solution pour corriger le problème?
Jon
http://www.btaz.com/misc/fatal-the-remote-end-hung-up- de manière inattendue/peut aider – Bijendra