Le canal ssh se bloque après l'authentification
Le serveur ranger vient hier de ne plus répondre à la connexion ssh, après des mois de travail comme prévu. L'authentification réussit, mais la journalisation -vvv révèle qu'un délai incroyablement long a été défini sur le canal établi pour la session:
debug1: Authentication succeeded (publickey).
Authenticated to ranger ([192.168.1.115]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env Shell
debug3: Ignored env TERM
debug3: Ignored env DOCKER_Host
debug3: Ignored env NVM_DIR
debug3: Ignored env USER
debug3: Ignored env NAME
debug3: Ignored env LS_COLORS
debug3: Ignored env HOSTTYPE
debug3: Ignored env _Java_OPTIONS
debug3: Ignored env PATH
debug3: Ignored env PWD
debug3: Ignored env XMODIFIERS
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env LESSOPEN
debug3: Ignored env DISPLAY
debug3: Ignored env LESSCLOSE
debug3: Ignored env _
debug2: channel 0: request Shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: channel_handler: chan 0: skip for 713631 more seconds
debug3: channel_handler: first channel unpauses in 713631 seconds
debug3: channel_handler: chan 0: skip for 713631 more seconds
debug3: channel_handler: first channel unpauses in 713631 seconds
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: Shell request accepted on channel 0
debug3: channel_handler: chan 0: skip for 713631 more seconds
debug3: channel_handler: first channel unpauses in 713631 seconds
debug3: channel_handler: chan 0: skip for 713631 more seconds
debug3: channel_handler: first channel unpauses in 713631 seconds
debug3: channel_handler: chan 0: skip for 713631 more seconds
debug3: channel_handler: first channel unpauses in 713631 seconds
La même chose se produit sur d’autres comptes sur cette machine, y compris de tout nouveaux comptes utilisant l’authentification par mot de passe (ce qui supprime donc vraisemblablement les problèmes .bashrc et ainsi de suite). De même, essayer d'appeler une commande complètement différente (ssh -vvv user@ranger 'ls ~') donne le même résultat.
Le client et le serveur sont sur le même réseau Ethernet, connecté au même commutateur.
Client: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 mars 2016
Serveur: Ubuntu 16.04.4, OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 mars 2016
Je suis aussi sur WSL . Tuer toutes les instances en cours de C:\WINDOWS\System32\bash.exe l'a corrigé. Avant cela, ouvrir de nouvelles instances de bash ne fonctionnait pas.
Je suppose que d’autres ont essayé de redémarrer, sans succès. Je ne pense donc pas que cette solution soit applicable dans l’ensemble, mais j'espère que mon point de données aidera quelqu'un à comprendre ce qui se passe.
Plusieurs instances de bash étaient ouvertes et certaines étaient ouvertes depuis des semaines. Par conséquent, une valeur de ralentissement exponentiel partagée n'était peut-être pas réinitialisée. Plus tôt aujourd'hui, l'icône réseau de Windows signalait (faussement) que je n'avais pas d'accès réseau, alors peut-être que cela avait quelque chose à voir avec cela.
Je viens d'arriver au même problème que ci-dessus lors de l'utilisation de WSL (Windows Subsystem for Linux), et les solutions mentionnées précédemment ne fonctionnaient pas pour moi.
J'ai finalement résolu le problème en redémarrant le WSL. Dans PowerShell en mode administratif, entrez simplement: Restart-Service LxssManager
Je me suis inspiré de la solution présentée dans Redémarrer Ubuntu sous Windows sans redémarrer Windows?
Couru dans ce problème identique avec WSL openSSH. Tous les autres programmes ssh n’avaient aucun problème à se connecter au périphérique local. J'ai essayé toutes les suggestions ci-dessus sans succès, même en désinstallant complètement openSSH-client et en le réinstallant.
Ensuite, j'ai essayé la première chose que vous êtes supposé faire lorsqu'un ordinateur est stupide. Fermez-le et rallumez-le. Tout est de retour à la normale.
Pas une réponse, mais une résolution: j'ai retiré et réinstallé ssh, et tout va bien. ¯\_ (ツ) _/¯