☰

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

tag-icon • tag-icon shell ssh login
Странная проблема с 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но это не дало результата (хотя, похоже, есть много повторных передач).

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

За исключением подозрительного драйвера/прошивки сетевой карты.

решение1

Это может быть связано с проблемой в профиле.
Когда вы подключаетесь к 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 — максимальный уровень отладки, вы можете его настроить)

я понялсвязь, гораздо более подробно.

решение2

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

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

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

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

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

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

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

решение3

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

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

/sbin/ip link set dev eth0 mtu 1400

решение4

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

Сейчас,какой-то_пользовательОболочка (предположим, что это также bash) не запускается интерактивно (вместо этого она выполняет заданную команду). Поэтому она не выделяет pty (aпсевдотерминал) и это означает, что для использования выданной команды нет 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команду, поскольку она в любом случае должна находиться в пути к оболочке пользователя по умолчанию)

Связанный контент