Как использовать SSH для запуска локального сценария оболочки на удаленном компьютере?

Если компьютер A является компьютером с Windows, вы можете использовать Plink (часть PuTTY) с параметром -m, и он выполнит локальный сценарий на удаленном сервере.

plink root@MachineB -m local_script.sh

Если Машина A является системой на основе Unix, вы можете использовать:

ssh root@MachineB 'bash -s' < local_script.sh

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

Это старый вопрос, и ответ Джейсона работает нормально, но я хотел бы добавить следующее:

ssh user@host <<'ENDSSH'
#commands to run on remote host
ENDSSH

Это также можно использовать с su и командами, требующими ввода данных пользователем. (обратите внимание на ' сбежавший heredoc)

Изменить: поскольку этот ответ продолжает получать биты трафика, я бы добавил еще больше информации об этом замечательном использовании heredoc:

Вы можете вкладывать команды с этим синтаксисом, и это единственный способ, которым вложение работает (разумным способом)

ssh user@host <<'ENDSSH'
#commands to run on remote host
ssh user@host2 <<'END2'
# Another bunch of commands on another host
wall <<'ENDWALL'
Error: Out of cheese
ENDWALL
ftp ftp.secureftp-test.com <<'ENDFTP'
test
test
ls
ENDFTP
END2
ENDSSH

Вы действительно можете общаться с некоторыми службами, такими как telnet, ftp и т. Д. Но помните, что heredoc просто отправляет stdin как текст, он не ждет ответа между строками

Изменить: я только что узнал, что вы можете сделать отступ внутри с помощью вкладок, если вы используете <<-END!

ssh user@host <<-'ENDSSH'
    #commands to run on remote host
    ssh user@host2 <<-'END2'
        # Another bunch of commands on another host
        wall <<-'ENDWALL'
            Error: Out of cheese
        ENDWALL
        ftp ftp.secureftp-test.com <<-'ENDFTP'
            test
            test
            ls
        ENDFTP
    END2
ENDSSH

(Я думаю, это должно сработать)

См. Также http://tldp.org/LDP/abs/html/here-docs.html

Кроме того, не забудьте экранировать переменные, если вы хотите забрать их с целевого хоста.

Это поймало меня в прошлом.

Например:

user@host> ssh user2@host2 "echo \$HOME"

распечатывает / home / user2

в то время как

user@host> ssh user2@host2 "echo $HOME"

распечатывает / home / user

Другой пример:

user@host> ssh user2@host2 "echo hello world | awk '{print \$1}'"

правильно распечатывает "привет".

Это расширение ответа YarekT для объединения встроенных удаленных команд с передачей переменных ENV с локального компьютера на удаленный хост, чтобы вы могли параметризовать свои скрипты на удаленной стороне:

ssh user@host ARG1=$ARG1 ARG2=$ARG2 'bash -s' <<'ENDSSH'
  # commands to run on remote host
  echo $ARG1 $ARG2
ENDSSH

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

Почему это работает. ssh поддерживает следующий синтаксис:

ssh пользователь @ хост удаленная_команда

В bash мы можем указать переменные среды для определения перед запуском команды в одной строке, например:

ENV_VAR_1 = 'значение1' ENV_VAR_2 = 'значение2' bash -c 'echo $ ENV_VAR_1 $ ENV_VAR_2'

Это упрощает определение переменных перед запуском команды. В этом случае echo - это наша команда, которую мы выполняем. Все, что находится до echo, определяет переменные среды.

Итак, мы объединяем эти две функции и ответ YarekT, чтобы получить:

ssh user @ host ARG1 = $ ARG1 ARG2 = $ ARG2 'bash -s' ‹закрыть 'ENDSSH' ...

В этом случае мы устанавливаем для ARG1 и ARG2 локальные значения. Отправка всего после user @ host в качестве remote_command. Когда удаленная машина выполняет команду, ARG1 и ARG2 устанавливают локальные значения благодаря локальной оценке командной строки, которая определяет переменные среды на удаленном сервере, а затем выполняет команду bash -s, используя эти переменные. Вуаля.

<hostA_shell_prompt>$ ssh user@hostB "ls -la"

Вам будет предложено ввести пароль, если только вы не скопировали открытый ключ пользователя hostA в файл authorized_keys в домашнем каталоге пользователя .ssh. Это позволит использовать аутентификацию без пароля (если она принята в качестве метода аутентификации в конфигурации ssh-сервера)

Я начал использовать Fabric для более сложных операций. Fabric требует Python и несколько других зависимостей, но только на клиентской машине. Сервер должен быть только ssh-сервером. Я считаю, что этот инструмент намного более мощный, чем сценарии оболочки, переданные SSH, и стоит того, чтобы его настроить (особенно если вам нравится программировать на Python). Fabric обрабатывает выполнение сценариев на нескольких хостах (или хостах определенных ролей), помогает облегчить идемпотентные операции (например, добавление строки в сценарий конфигурации, но не в том случае, если она уже есть), и позволяет создавать более сложную логику (например, Python язык может предоставить).

Попробуйте запустить ssh user@remote sh ./script.unx.

Предполагая, что вы имеете в виду, что хотите сделать это автоматически с «локальной» машины, без ручного входа на «удаленную» машину, вам следует изучить расширение TCL, известное как Expect, оно предназначено именно для такого рода ситуаций. Я также предоставил ссылку на скрипт для входа / взаимодействия через SSH.

https://www.nist.gov/services-resources/software/expect

http://bash.cyberciti.biz/security/expect-ssh-login-script/

Я использую его для запуска сценария оболочки на удаленном компьютере (проверено на / bin / bash):

ssh deploy@host . /home/deploy/path/to/script.sh

ssh user@hostname ".~/.bashrc;/cd path-to-file/;.filename.sh"

настоятельно рекомендуется использовать исходный файл среды (.bashrc / .bashprofile / .profile). перед запуском чего-либо на удаленном хосте, потому что переменные среды целевого и исходного хостов могут быть отложены.

если вы хотите выполнить команду, подобную этой команде temp=`ls -a` echo $temp в `` вызовет ошибки.

команда ниже решит эту проблему ssh user@host ''' temp=`ls -a` echo $temp '''

Ответ здесь (https://stackoverflow.com/a/2732991/4752883) отлично работает, если вы пытаетесь запустить сценарий на удаленной машине с Linux, используя plink или ssh. Это будет работать, если в сценарии есть несколько строк на linux.

** Однако, если вы пытаетесь запустить пакетный сценарий, расположенный на локальном linux/windows компьютере, а ваш удаленный компьютер - Windows, и он состоит из нескольких строк с использованием **

plink root@MachineB -m local_script.bat

не будет работать.

Будет выполнена только первая строка скрипта. Вероятно, это ограничение plink.

Решение 1:

Чтобы запустить многострочный пакетный скрипт (особенно если он относительно простой, состоящий из нескольких строк):

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

cd C:\Users\ipython_user\Desktop 
python filename.py

вы можете объединить строки вместе с помощью разделителя «&&» в вашем local_script.bat файле следующим образом: https://stackoverflow.com/a/8055390/4752883:

cd C:\Users\ipython_user\Desktop && python filename.py

После этого изменения вы можете запустить сценарий, как указано здесь @ JasonR.Coombs: https://stackoverflow.com/a/2732991/4752883 с:

`plink root@MachineB -m local_script.bat`

Решение 2:

Если ваш пакетный сценарий относительно сложен, может быть лучше использовать пакетный сценарий, который инкапсулирует команду plink, а также следующее, как указано здесь @Martin https://stackoverflow.com/a/32196999/4752883:

rem Open tunnel in the background
start plink.exe -ssh [username]@[hostname] -L 3307:127.0.0.1:3306 -i "[SSH
key]" -N

rem Wait a second to let Plink establish the tunnel 
timeout /t 1

rem Run the task using the tunnel
"C:\Program Files\R\R-3.2.1\bin\x64\R.exe" CMD BATCH qidash.R

rem Kill the tunnel
taskkill /im plink.exe

Этот сценарий bash выполняет ssh на целевом удаленном компьютере и запускает некоторую команду на удаленном компьютере, не забудьте установить ожидание перед его запуском (на Mac brew install expect)

#!/usr/bin/expect
set username "enterusenamehere"
set password "enterpasswordhere"
set hosts "enteripaddressofhosthere"
spawn ssh  $username@$hosts
expect "$username@$hosts's password:"
send -- "$password\n"
expect "$"
send -- "somecommand on target remote machine here\n"
sleep 5
expect "$"
send -- "exit\n"

Вы можете использовать runoverssh:

sudo apt install runoverssh

runoverssh -s localscript.sh user host1 host2 host3...

-s удаленно запускает локальный сценарий

Полезные флаги:
-g использовать глобальный пароль для всех хостов (запрос единого пароля)
-n использовать SSH вместо sshpass, полезно для аутентификации с открытым ключом

Если сценарий короткий и предназначен для встраивания в ваш сценарий, и вы работаете под bash оболочкой, а также bash оболочка доступна на удаленной стороне, вы можете использовать declare для передачи локального контекста на удаленный. Определите переменные и функции, содержащие состояние, которое будет передано на удаленный компьютер. Определите функцию, которая будет выполняться на удаленной стороне. Затем внутри документа, читаемого bash -s, вы можете использовать declare -p для передачи значений переменных и использовать declare -f для передачи определений функций на удаленный компьютер.

Поскольку declare заботится о цитировании и будет анализироваться удаленным bash, переменные правильно заключены в кавычки и функции передаются должным образом. Вы можете просто написать сценарий локально, обычно я выполняю одну длинную функцию с работой, которую мне нужно выполнить на удаленной стороне. Контекст должен быть выбран вручную, но следующий метод достаточно хорош для любых коротких сценариев и безопасен - должен правильно обрабатывать все угловые случаи.

somevar="spaces or other special characters"
somevar2="!@#$%^"
another_func() {
    mkdir -p "$1"
}
work() {
    another_func "$somevar"
    touch "$somevar"/"$somevar2"
}
ssh user@server 'bash -s' <<EOT
$(declare -p somevar somevar2)    # transfer variables values
$(declare -f work another_func)   # transfer function definitions
work                              # call the function
EOT

Если это один сценарий, все в порядке с указанным выше решением.

Я бы настроил Ansible для выполнения этой работы. Он работает таким же образом (Ansible использует ssh для выполнения сценариев на удаленной машине как для Unix, так и для Windows).

Он будет более структурированным и удобным в обслуживании.

Неясно, использует ли локальный сценарий локально установленные переменные, функции или псевдонимы.

Если это так, это должно сработать:

myscript.sh:

#!/bin/bash

myalias $myvar
myfunction $myvar

Он использует $myvar, myfunction и myalias. Предположим, они установлены локально, а не на удаленной машине.

Создайте функцию bash, содержащую скрипт:

eval "myfun() { `cat myscript.sh`; }"

Задайте переменную, функцию и псевдоним:

myvar=works
alias myalias='echo This alias'
myfunction() { echo This function "$@"; }

И экспортируйте myfun, myfunction, myvar и myalias в server, используя env_parallel из GNU Parallel:

env_parallel -S server -N0  --nonall myfun ::: dummy

Сначала скопируйте скрипт на машину B с помощью scp

[пользователь @ machineA] $ scp / path / to / script user @ machineB: / home / user / path

Затем просто запустите скрипт

[пользователь @ machineA] $ ssh user @ machineB "/ home / user / path / script"

Это будет работать, если вы дали скрипту разрешение на выполнение.