Выполнение команды 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 -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>%
...

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

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


person Robert Muil    schedule 08.05.2011    source источник
comment
Я не знаю ответа на ваш вопрос, но у меня есть идея. Возможно, в вашем SSH-клиенте или на SSH-сервере есть неправильная конфигурация. Попробуйте подключить другого клиента к тому же серверу, а затем попробуйте тот же клиент к другому серверу, и посмотрим, какой из них сработает.   -  person pts    schedule 08.05.2011
comment
О некоторых подобных проблемах ранее сообщалось в stackoverflow: google.com/search? q=ssh+команда+выполнение+зависание   -  person James C    schedule 08.05.2011
comment
Это не проблема конфигурации SSH — он не работает с разных клиентов. Конфигурация сервера заблокирована для меня, но проверена другими пользователями. Другие проблемы, размещенные здесь, не совсем такие же, я просмотрел их.   -  person Robert Muil    schedule 09.05.2011


Ответы (7)


Проблема действительно заключалась в моем сценарии входа в систему, хотя и не в требовании терминала (я подозревал это и тестировал с параметрами -t и -T). Проблема заключалась в том, что мой .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 в их сценариях запуска.

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

person Robert Muil    schedule 09.05.2011
comment
.bashrc = вызывается всякий раз, когда оболочка вызывается и присоединяется к терминалу. .bash_profile вызывается только при входе в систему. Различие нечеткое, но его легко проверить с помощью команды echo 'echo I is logged in' › ~/.bash_profile и выполнения команды с использованием ssh. Таким образом, вы можете увидеть, делает ли прямое выполнение команды через ssh оболочку оболочкой входа в систему. - person Mel; 11.05.2011
comment
Я столкнулся с той же проблемой, используя oh-my-zsh, мне пришлось вставить [ -z "$PS1" ] && return прямо перед source $ZSH/oh-my-zsh.sh, чтобы избежать зависания SSH при использовании другого хоста в качестве прокси. - person Kenneth Hoste; 08.06.2016

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

person Mel    schedule 08.05.2011

Мы исправили это, добавив -n (для перенаправления std из /dev/null) и -t (принудительное выделение псевдотерминала).

Пример:

ssh -t -n user@host command
person A.Badger    schedule 20.11.2018

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

person geekosaur    schedule 08.05.2011

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

person Mark Dominus    schedule 14.11.2014

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

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

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

person Tanguy    schedule 17.07.2015

В конце концов я нашел переменную "$-", которая работает для меня:

if [[ $- =~ i ]] ; then
    [ -x /bin/tcsh ] && exec /bin/tcsh
    # Bash startup stuff goes here...
fi

Получил это от: https://www.gnu.org/software/bash/manual/html_node/Is-this-Shell-Interactive_003f.html

person The Veritable Bugeater    schedule 20.11.2019