Ssh-скрипт "Wrapper" зависает при выполнении удаленной команды

Question

Я использую OSX Mountain Lion, а удаленный сервер - CentOS 6. У меня есть несколько сценариев на локальном компьютере, которые я хочу запустить на удаленном сервере, и с этой целью я подумал написать один сценарий, который подключается через ssh, который принимает второй сценарий для выполнения в качестве параметра. Таким образом, я могу писать сценарии bash естественным образом, не беспокоясь о ssh и обо всех проблемах, связанных с этим, и эти же сценарии также можно будет переназначить на моем локальном компьютере. Например,

exec_remote.sh

!#/bin/bash
ssh -t -t jeff@remoteserver 'bash -s' < $1

make_dir.sh (обратите внимание на sudo)

!#/bin/bash
sudo mkdir -p /some/path/to/a/new/location

И идея в том, чтобы бежать как

./exec_remote.sh make_dir.sh

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

Более того, поскольку я не вызывал logout , у меня по-прежнему открыт терминал ssh, и все последующие команды (т.е. ls) полностью заморожены. Я позволил ls бежать в течение 70 минут, прежде чем сломать его. Примечание: я на самом деле не забочусь о выполнении команд после; Я просто включаю это как признак того, что не так.

Как мне это исправить? Или еще лучше, есть ли лучший способ решить эту проблему?

РЕДАКТИРОВАТЬ

Если я обновлю свой сценарий make_dir.sh чтобы создать каталог, для которого не требуется sudo , сценарий выполняется совершенно нормально, как и ожидалось. Известна ли проблема с удаленным запуском команд sudo? Возможно только с CentOS?

Answer 1

Ваш способ выполнения ssh имеет фундаментальный недостаток: у вас есть только один стандартный ввод. Поскольку вы читаете скрипт с помощью < , stdin "заполнен" содержимым скрипта. И объединены с вашим вводом (в данном случае, вашим паролем). Который не может работать.

Таким образом, единственный способ, которым я вижу, чтобы это работало: вы должны скопировать скрипт на удаленный сервер и затем запустить команду ssh, которая просто выполняет этот скрипт. Итак, что-то в этом роде:

#!/bin/bash
USERHOST=jeff@remoteserver

ssh -o ControlMaster=yes -o ControlPersist=3600 -o ControlPath=/tmp/ssh-master-$USER-%r@%h:%p -Nf $USERHOST
trap "ssh -o ControlPath=/tmp/ssh-master-$USER-%r@%h:%p $USERHOST -O exit" exit

TEXEC=$(ssh $USERHOST mktemp)
scp $1 ${USERHOST}:${TEXEC}
ssh -t -t $USERHOST $TEXEC

Этот сценарий открывает совместно используемое соединение с удаленным сервером (поэтому вам нужно всего лишь ввести свой пароль SSH), затем копирует сценарий оболочки и, наконец, выполняет его с помощью обычной команды ssh , которая позволяет ему выделить TTY и, таким образом, позволяет Ваш пароль будет введен для sudo (относительно) безопасным способом. В конце сценария-оболочки разделяемое соединение закрывается через ловушку exit .

Answer 2

Попробуйте запустить скрипт в фоновом режиме, перенаправив std out и std err в файл журнала. Для того, чтобы ваша оболочка вернулась (т.е. не "была заблокирована на долгое время во время выполнения скрипта"), вам нужно использовать nohup, а также перенаправить все каналы: StdOut, StdIn, StdErr. Например:

ssh jeff@remoteserver 'nohup make_dir.sh >> /tmp/log_file 2>&1 </dev/null &'

Приведенная выше команда подключит вас к удаленному серверу и запустит make_dir.sh в фоновом режиме, перенаправив StdOut и StdErr в /tmp /log_file. StdIn перенаправляется из /dev /null. В противном случае ssh будет зависать, пока скрипт не завершится.

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

Answer 3

Просто делать

ssh -t -t jeff@remoteserver $1

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

bash -s с открытым сеансом bash.

Вы, вероятно, хотите $ * вместо $ 1, чтобы вы могли передавать аргументы вызываемому скрипту

Answer 4

Я думаю, я понимаю, что вы хотите. Выполнить локальный файл на удаленной машине.

cat ваш локальный файл через канал в удаленный Bash

например, чтобы проверить

$ echo "ls -l" | ssh jeff@remoteserver "bash " 

в сценарии

cat $1 | ssh jeff@remoteserver "bash "