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

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

невыполненной команды: ssh -v -v <username>@<server> uptime (также пробовал echo hello etc.)

debug1: Authentication succeeded (publickey).
Authenticated to <server> (<ip>:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
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 no-more-sessions@openssh.com
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 для синхронизации моих файлов (раньше это работало). Любая помощь очень ценится.

21
linux remote-execution ssh

5 ответов

проблема действительно была моим сценарием входа в систему, хотя и не связана с требованием терминала (я подозревал это и тестировал с -t и -T options). Проблема была в том, что мой .bashrc управлял exec (в данном случае zsh - потому что наша система не позволяет chsh to 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 был вызван вообще - я думал, что это только для интерактивных оболочек, но точное назначение и порядок различных сценариев init-это то, что я не думаю, что когда-нибудь узнаю.

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

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

24

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

4

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

2

недавно я столкнулся с проблемой с теми же симптомами, но определил, что проблема была не проблема в моих сценариях входа в систему. Вернее, мой местный конфигурация RequestTTY force для хоста, на который я пытался скопировать.

2

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

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

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

1