Странная проблема SSH, ssh работает с -t, но зависает без него

Когда я sshзахожу на один из моих серверов, он, кажется, входит в систему, но затем зависает, прежде чем дать мне приглашение ( message debug2: shell request accepted on channel 0 is the last log entry).

Хотя странная вещь ssh -t "/bin/bash"работает, когда sshнет.

Что я узнал до сих пор

• Я могу нормально войти в систему с серверов в том же географическом месте, как обычно
• Если я ssh -t '/bin/bash'- я могу войти в систему из ЛЮБОГО места.
• Если я использую rsync к серверу, это, кажется, работает, а затем блокирует
• Если я использую rsync с сервера, он работает без проблем

Что я пробовал

• удаление или изменение всех параметров входа в систему .profile,.bashrc /etc/profile
• Изменение ssh_config и / или sshd_config одного с идентичного сервера, который работает нормально
• Я проверил маршрутизацию
• Я проверил эксперта по сети tcpdumpбезрезультатно (хотя, похоже, повторных передач много)

Я действительно не могу думать ни о чем другом

Помимо хитрой сетевой карты драйвера / прошивки.

Это может быть связано с проблемой в профиле.
При подключении с ssh -t /bin/bash вашей оболочкой не будет «вход», он не будет источник /etc/profileни ~/.profileи ~/.bashrc...

Таким образом, после подключения переведите оболочку в режим отладки, затем найдите каждый файл, чтобы найти то, что блокируется внутри:

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

РЕДАКТИРОВАТЬ

Обратите внимание, что я ошибся, файл .bashrc будет получен любой интерактивной оболочкой (поэтому здесь важны только файлы profile, profile.d).

Попробуйте составить список различных этапов процесса подключения. Что-то вроде этого

1) ssh-соединение (config, ...)
2) вход в систему (PAM, tty, wtmp, ...)
3) запуск оболочки (профиль, доступ к домашнему каталогу, ...)

Чтобы проверить (1), вы можете запустить демон sshd в режиме отладки. Для этого вам нужно запустить другой sshd, прослушивая выделенный порт (не на порту 22, поэтому нет необходимости останавливать обычный демон sshd).

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

Этот sshd будет принимать только одно соединение и не будет переходить в фоновый режим. Откройте другой терминал и подключитесь к этому сеансу ssh.

# ssh -vvv -p 2222 user@host

Вы можете сравнить полученные сообщения с сообщениями другого сервера того же бренда. Тогда вы будете знать, если проблема на стороне SSH или нет.

(-ddd и -vvv - максимальный уровень отладки, вы можете настроить его)

Я получил эту ссылку , гораздо более подробно.

Ответ на мою проблему Оказывается, это была проблема с сетью. В конце концов я обнаружил, что, немного сбрасывая MTU всех сетевых карт, проблема исчезла.

Скорее всего, что-то неправильно настроено для этой сети, но теперь я могу доказать это и передать это сетевой команде (которая постоянно говорила мне, что это проблема с сервером).

Однако следует помнить, что это последнее средство. У меня была особенность в том, что ssh-сервер работал из той же подсети, но не за ее пределами, а ssh -t '/ bin / bash' работал из любой точки.

У меня также были rsyncs, которые нормально запускались, но в какой-то момент просто зависали или сбрасывали соединение.

Так что, если вы смотрите на этот ответ, попробуйте сначала другие, приведенные выше, и ТОЛЬКО если у вас есть странности, подобные моей, это может помочь.

Так что спасибо за помощь. Я попробовал все, и это научило меня загружаться, и позвольте мне подтвердить, что это не имеет ничего общего с сервером (это все, на что я надеялся).

Так что спасибо всем, кто помог

Когда вы делаете ssh some_user@some_host /bin/bash, что вы делаете, запуск some_user «s оболочки (как определено в /etc/passwdна some_host ) , а затем выполняет заданную команду, /bin/bashиз внутри этой оболочки.

Теперь оболочка some_user (предположим, что это тоже bash) не запускается интерактивно (вместо этого она выполняет данную команду). Таким образом, он не выделяет pty ( псевдотерминал ), а это означает, что для введенной команды нет pty, поэтому он запускается неинтерактивно.

В этом примере запрошенная /bin/bashкоманда запущена, но кажется, что она зависает.

Это можно исправить, попросив sshв любом случае создать pty, чтобы он был доступен для оболочки и ее дочерних процессов. Это то, что -tделает.

    $ ssh -t some_user@some_host bash

Вы также можете исправить это, заставив команду создать pty. Ибо bashвы делаете это, передавая -iаргумент. Следующая командная строка также должна работать:

$ ssh some_user@some_host bash -i

Обратите внимание, однако, что в этом последнем случае оболочка не может получить доступ, /dev/ttyи это приводит к предупреждению:

bash: no job control in this shell

Причины этого объясняются здесь . Это может или не может быть проблемой в зависимости от того, что вы планируете делать в оболочке, но использование ssh -t, вероятно, является лучшим вариантом.

(обратите внимание, что вы можете просто передать bashкак команду, потому что она должна быть в любом случае на пути к оболочке пользователя по умолчанию)

У меня та же проблема, когда я недавно использовал вложенную платформу виртуализации.

Он работает после уменьшения MTU с 1500 до 1400 на исходном или целевом сервере.

/sbin/ip link set dev eth0 mtu 1400