Problème SSH étrange, ssh fonctionne avec -t mais se fige sans

Lorsque je sshme connecte à l'un de mes serveurs, il semble se connecter, mais se bloque avant de me donner l'invite ( message debug2: shell request accepted on channel 0 is the last log entry).

Bien que la chose étrange ssh -t "/bin/bash"fonctionne quand sshne fonctionne pas.

Ce que j'ai découvert jusqu'à présent

• Je peux me connecter correctement à partir de serveurs dans le même emplacement géographique normalement
• Si je ssh -t '/bin/bash'- je peux me connecter parfaitement depuis n'importe quel endroit.
• Si je l' utilise rsync pour le serveur, il semble fonctionner, et puis se bloque
• Si j'utilise rsync depuis le serveur, cela fonctionne sans problème

Ce que j'ai essayé

• supprimer ou modifier toutes les options de connexion .profile,.bashrc /etc/profile
• Changement de ssh_config et / ou sshd_config en un à partir d'un serveur identique qui fonctionne bien
• J'ai vérifié le routage
• J'ai fait examiner un expert en réseau tcpdumpen vain (bien qu'il semble y avoir beaucoup de retransmissions)

Je ne peux vraiment penser à rien d'autre

Mis à part un pilote / firmware de carte réseau douteux.

Cela peut provenir d'un problème dans le profil.
Lorsque vous vous connectez avec ssh -t /bin/bash votre shell, il ne se `` connecte pas '', il ne source /etc/profileni le ni le ~/.profileet ~/.bashrc...

Donc après la connexion, mettez le shell en mode débogage puis sourcez chaque fichier pour trouver ce qui bloque à l'intérieur:

set -x 
. /etc/profile 
...and so on

ÉDITER

Notez que j'avais tort, le fichier .bashrc proviendra de n'importe quel shell interactif (donc seuls les fichiers profile, profile.d importent ici).

Essayez de faire la liste des différentes phases du processus de connexion. Quelque chose comme ça

1) connexion ssh (config, ...)
2) connexion (PAM, tty, wtmp, ...)
3) démarrage du shell (profil, accès au répertoire personnel, ...)

Pour vérifier le (1), vous pouvez démarrer le démon sshd en mode débogage. Pour cela, vous devez démarrer un autre sshd, en écoutant un port dédié (pas sur le port 22 donc pas besoin d'arrêter le démon sshd normal).

# /usr/sbin/sshd -p 2222 -ddd 

Ce sshd n'acceptera qu'une seule connexion et ne passera pas en arrière-plan. Ouvrez un autre terminal et connectez-vous à cette session ssh.

# ssh -vvv -p 2222 user@host

Vous pouvez comparer les messages que vous obtenez avec celui d'un autre serveur de la même marque. Vous saurez alors si le problème est du côté SSH ou non.

(-ddd et -vvv sont le niveau de débogage maximum, vous pouvez le régler)

J'ai eu ce lien , beaucoup plus détaillé.

La réponse à mon problème se révèle être un problème de réseau. J'ai finalement découvert qu'en supprimant un peu le MTU de toutes les cartes réseau, le problème avait disparu.

Quelque chose est probablement mal configuré pour ce réseau, mais je peux maintenant le prouver et le remettre à l'équipe du réseau (qui n'arrêtait pas de me dire que c'était un problème de serveur).

Sachez cependant que c'est un dernier recours. La particularité que j'avais était que le serveur ssh fonctionnait à partir du même sous-réseau mais pas à l'extérieur, et ssh -t '/ bin / bash' fonctionnait de n'importe où.

J'ai également eu des rsyncs qui commenceraient bien, mais à un moment donné, il suffit de bloquer ou de supprimer la connexion.

Donc, si vous regardez cette réponse, essayez d'abord les autres ci-dessus, et UNIQUEMENT si vous rencontrez des bizarreries comme la mienne, cela est-il susceptible d'aider.

Merci donc pour toute l'aide. J'ai tout essayé, et cela m'a appris beaucoup de choses, et laissez-moi confirmer que cela n'a rien à voir avec le serveur (qui est tout ce que j'espérais).

Merci à tous ceux qui ont aidé

Quand vous faites ssh some_user@some_host /bin/bash, ce que vous faites lance un_utilisateur shell de (tel que défini dans /etc/passwdle some_host ), puis d' exécuter la commande donnée, /bin/bash, à partir de l' intérieur de cette coquille.

Maintenant, le shell de some_user (supposons qu'il l'est aussi bash) n'est pas lancé de manière interactive (il exécute la commande donnée à la place). Donc, il n'alloue pas de pty (un pseudo-terminal ) et cela signifie qu'il n'y a pas de pty à utiliser pour la commande émise, il démarre donc de manière non interactive.

Dans l'exemple, la /bin/bashcommande demandée est lancée mais elle semble se bloquer.

Vous pouvez résoudre ce problème en demandant sshde toute façon de créer un pty afin qu'il y en ait un disponible pour le shell et ses processus enfants. C'est ce qui -tfait.

    $ ssh -t some_user@some_host bash

Vous pouvez également résoudre ce problème en forçant la commande à créer un pty. Pour bash, vous faites cela en passant un -iargument. La ligne de commande suivante devrait également fonctionner:

$ ssh some_user@some_host bash -i

Notez cependant que dans ce dernier cas, le shell ne peut pas accéder /dev/ttyet cela se traduit par un avertissement:

bash: no job control in this shell

Les raisons de cela sont expliquées ici . Cela peut ou non être un problème selon ce que vous prévoyez de faire dans le shell, mais l'utilisation ssh -test probablement la meilleure option.

(notez que vous pouvez simplement passer bashla commande car elle devrait de toute façon se trouver sur le chemin du shell par défaut de l'utilisateur)

J'ai le même problème lorsque j'ai récemment utilisé une plate-forme de virtualisation imbriquée.

Il fonctionne après avoir réduit le MTU de 1500 à 1400 sur le serveur source ou de destination.

/sbin/ip link set dev eth0 mtu 1400