Дивний 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

EDIT

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

Спробуйте скласти список різних фаз процесу з'єднання. Щось на зразок цього

1) ssh-з'єднання (config, ...)
2) вхід (PAM, tty, wtmp, ...)
3) запуск оболонки (профіль, доступ до дому dir, ...)

Щоб перевірити (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