Выполнение команд SSH зависает, хотя интерактивные функции оболочки отлично

Когда я пытаюсь выполнить команду на удаленном сервере с помощью ssh, команда ssh зависает после отладочного сообщения exec request accepted и в конечном итоге отключается.

Неудачная команда: ssh -v -v <username>@<server> uptime (также попробовал echo hello и т.д.)

debug1: Authentication succeeded (publickey).
Authenticated to <server> (<ip>:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 4 setting TCP_NODELAY
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: uptime
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0

И там он висит бесконечно.

Однако, когда я ssh без команды на моем удаленном сервере, я получаю интерактивную оболочку, и все это хорошо.

Успешная команда: ssh -v -v <username>@<server>

Вывод:

debug1: Authentication succeeded (publickey).
Authenticated to <server> (<ip>:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 4 setting TCP_NODELAY
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome!
<prompt>%
...

Есть ли у кого-нибудь идея, почему интерактивный сеанс будет успешным, но выполнение команды не?

Меня преследовали уже несколько месяцев, потому что я больше не могу использовать unison для синхронизации моих файлов (он работал). Любая помощь очень ценится.

Ответы

Ответ 1

Проблема заключалась в том, что мой логин script, хотя и не требовал терминала (я подозревал это и тестировался с параметрами -t и -t). Проблема заключалась в том, что my .bashrc выполнял exec (в данном случае - zsh), потому что наша система не разрешает chsh до zsh).

Линия нарушения:

test -f /usr/bin/zsh && exec /usr/bin/zsh

Решено сначала проверить интерактивную оболочку и выйти, если это так:

[ -z "$PS1" ] && return
test -f /usr/bin/zsh && exec /usr/bin/zsh

Итак, по сути, потому что оболочка выполнялась в zsh, ssh ждала, когда это закончится, чего не было.

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

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

BTW - два других ответа были на правильном пути, поэтому я совершенно не знал, должен ли я отвечать или просто комментировать их ответы. Если ответ на мой собственный вопрос является морально неправильным в stackoverflow, дайте мне знать, и я сделаю покаяние. Спасибо другим ответчикам.

Ответ 2

Ваша проблема, скорее всего, заключается в сценариях запуска оболочки или оболочки. Не зная, что там, трудно угадать фактическую проблему.

Ответ 3

Проверьте команды в файлах запуска оболочки (я бы предположил, что ~/.cshrc из вашего приглашения; в неинтерактивном сеансе ~/.login не имеет значения), для которого по какой-то причине требуется терминал.

Ответ 4

Недавно я столкнулся с проблемой с теми же симптомами, но решил, что проблема не была проблемой в моих сценариях входа. Скорее, мой локальный .ssh/config файл был настроен с RequestTTY force для хоста, к которому я пытался копировать.

Ответ 5

У меня была эта проблема на сервере fedora 22 после разрешения других новых проблем.

ssh -t ziimp/bin/true было нормально, но не ssh ziimp/bin/true, и все мои git + ssh и scp были заблокированы.

Решение, которое я нашел, находится в файле authorized_keys. Мне пришлось удалить префикс command = "/usr/bin/ bash" из моих доверенных ключей...