Jak używać SSH do uruchamiania skryptu powłoki na zdalnym komputerze?

Muszę uruchomić skrypt powłoki (Windows / Linux) na zdalnym komputerze.

Mam skonfigurowane SSH zarówno na komputerze A, jak i B. Mój skrypt znajduje się na komputerze A, który uruchomi część mojego kodu na komputerze zdalnym, komputerze B.

Komputery lokalne i zdalne mogą być systemem Windows lub Unix.

Czy istnieje sposób, aby to zrobić, używając Plink / SSH?

Jeśli Maszyna A jest oknem Windows, możesz użyć Plink (część PuTTY ) z parametrem -m, a on wykona skrypt lokalny na zdalnym serwerze.

plink root@MachineB -m local_script.sh

Jeśli Maszyna A jest systemem uniksowym, możesz użyć:

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

Nie trzeba kopiować skryptu na zdalny serwer, aby go uruchomić.

To jest stare pytanie i odpowiedź Jasona działa dobrze, ale chciałbym dodać to:

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

Można tego również używać z poleceniami su i poleceniami, które wymagają wkładu użytkownika. (zwróć uwagę na 'uciekającego heredoka)

Edycja: Ponieważ ta odpowiedź ciągle się powiększa, dodałbym jeszcze więcej informacji do tego wspaniałego zastosowania heredoc:

Możesz zagnieżdżać polecenia za pomocą tej składni, i to jedyny sposób, w jaki wydaje się działać zagnieżdżanie (w rozsądny sposób)

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

Możesz faktycznie rozmawiać z niektórymi usługami, takimi jak telnet, ftp itp. Pamiętaj jednak, że heredoc po prostu wysyła stdin jako tekst, nie czeka na odpowiedź między wierszami

Edycja: Właśnie dowiedziałem się, że możesz użyć wcięć wewnątrz kart, jeśli używasz <<-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

(Myślę, że to powinno działać)

Zobacz także http://tldp.org/LDP/abs/html/here-docs.html

Nie zapomnij także o zmianie zmiennych, jeśli chcesz je pobrać z hosta docelowego.

To mnie złapało w przeszłości.

Na przykład:

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

wypisuje / home / user2

podczas

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

drukuje / home / user

Inny przykład:

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

drukuje poprawnie „cześć”.

Jest to rozszerzenie odpowiedzi YarekT, aby połączyć wbudowane polecenia zdalne z przekazywaniem zmiennych ENV z komputera lokalnego do zdalnego hosta, aby można było sparametryzować skrypty po stronie zdalnej:

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

Uznałem to za wyjątkowo pomocne, utrzymując wszystko w jednym skrypcie, dzięki czemu jest bardzo czytelny i łatwy w utrzymaniu.

Dlaczego to działa ssh obsługuje następującą składnię:

ssh użytkownik @ host komenda_zdalna

W bash możemy określić zmienne środowiskowe, które mają zostać zdefiniowane przed uruchomieniem polecenia w jednym wierszu:

ENV_VAR_1 = „wartość1” ENV_VAR_2 = „wartość2” bash -c „echo $ ENV_VAR_1 $ ENV_VAR_2”

Ułatwia to definiowanie zmiennych przed uruchomieniem polecenia. W tym przypadku echo to nasze polecenie, które uruchamiamy. Wszystko przed echem definiuje zmienne środowiskowe.

Łączymy więc te dwie funkcje z odpowiedzią YarekT, aby uzyskać:

ssh user @ host ARG1 = $ ARG1 ARG2 = $ ARG2 'bash -s' << 'ENDSSH' ...

W tym przypadku ustawiamy ARG1 i ARG2 na wartości lokalne. Wysyłanie wszystkiego po user @ host jako komenda_zdalna. Gdy zdalna maszyna wykonuje polecenie ARG1 i ARG2, są ustawiane wartości lokalne, dzięki ocenie lokalnego wiersza poleceń, która definiuje zmienne środowiskowe na zdalnym serwerze, a następnie wykonuje polecenie bash -s przy użyciu tych zmiennych. Voila

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

Spowoduje to wyświetlenie monitu o podanie hasła, chyba że skopiowałeś klucz publiczny użytkownika hosta do pliku autoryzowanych_kluczy w katalogu głównym katalogu użytkownika .ssh. Pozwoli to na uwierzytelnianie bez hasła (jeśli zostanie zaakceptowane jako metoda uwierzytelniania w konfiguracji serwera ssh)

Zacząłem używać Fabric do bardziej wyrafinowanych operacji. Sieć szkieletowa wymaga języka Python i kilku innych zależności, ale tylko na komputerze klienckim. Serwer musi być tylko serwerem ssh. Uważam, że to narzędzie jest o wiele potężniejsze niż skrypty powłoki przekazywane do SSH i warte jest kłopotów z konfiguracją (szczególnie jeśli lubisz programować w Pythonie). Fabric obsługuje działające skrypty na wielu hostach (lub hostach niektórych ról), pomaga w wykonywaniu idempotentnych operacji (takich jak dodawanie wiersza do skryptu konfiguracyjnego, ale nie, jeśli już tam jest), i pozwala na budowę bardziej złożonej logiki (takiej jak Python język może zapewnić).

Spróbuj uruchomić ssh user@remote sh ./script.unx.

cat ./script.sh | ssh <user>@<host>

Zakładając, że masz na myśli, że chcesz to zrobić automatycznie z „lokalnej” maszyny, bez ręcznego logowania się na „zdalnej” maszynie, powinieneś zajrzeć do rozszerzenia TCL znanego jako Oczekiwanie, jest ono zaprojektowane właśnie do tego rodzaju sytuacji. Podałem również link do skryptu do logowania / interakcji przez SSH.

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

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

Używam tego do uruchomienia skryptu powłoki na zdalnym komputerze (testowany na / bin / bash):

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

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

zdecydowanie zaleca się źródło pliku środowiska (.bashrc / .bashprofile / .profile). przed uruchomieniem czegoś na hoście zdalnym, ponieważ zmienne środowiskowe hosta docelowego i źródłowego mogą być niepoprawne.

jeśli chcesz wykonać polecenie takie jak to temp=`ls -a` echo $temp w `` spowoduje błędy.

poniższe polecenie rozwiąże ten problem ssh user@host ''' temp=`ls -a` echo $temp '''

Odpowiedź tutaj ( https://stackoverflow.com/a/2732991/4752883 ) działa świetnie, jeśli próbujesz uruchomić skrypt na zdalnym komputerze z systemem Linux za pomocą plinklub ssh. Będzie działać, jeśli skrypt ma wiele wierszy linux.

** Jednak jeśli próbujesz uruchomić skrypt wsadowy znajdujący się na linux/windowskomputerze lokalnym , a twój komputer zdalny jest w stanie Windows, i składa się z wielu wierszy przy użyciu **

plink root@MachineB -m local_script.bat

nie zadziała.

Zostanie wykonana tylko pierwsza linia skryptu. Jest to prawdopodobnie ograniczenie plink.

Rozwiązanie 1:

Aby uruchomić wielowierszowy skrypt wsadowy (zwłaszcza jeśli jest stosunkowo prosty i składa się z kilku wierszy):

Jeśli oryginalny skrypt partii jest następujący

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

możesz połączyć linie razem za pomocą separatora „&&” w następujący sposób w local_script.batpliku: https://stackoverflow.com/a/8055390/4752883 :

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

Po tej zmianie możesz uruchomić skrypt, jak wskazano tutaj przez @ JasonR.Coombs: https://stackoverflow.com/a/2732991/4752883 z:

`plink root@MachineB -m local_script.bat`

Rozwiązanie 2:

Jeśli skrypt wsadowy jest stosunkowo skomplikowany, może być lepiej użyć skryptu wsadowego, który zawiera polecenie plink, a także następujące czynności, jak wskazano tutaj @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

Ten skrypt bash robi ssh na docelowym komputerze zdalnym i uruchamia komendę na komputerze zdalnym, nie zapomnij zainstalować expect przed uruchomieniem go (na komputerze 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"

Możesz użyć Runoverssh :

sudo apt install runoverssh

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

-s uruchamia skrypt lokalny zdalnie

Przydatne flagi:
-g użyj globalnego hasła dla wszystkich hostów (monit o jedno hasło)
-nużyj SSH zamiast sshpass, przydatny do uwierzytelniania z kluczem publicznym

Najpierw skopiuj skrypt na maszynę B za pomocą scp

[użytkownik @ maszynaA] $ scp / ścieżka / do / skrypt użytkownik @ maszynaB: / home / użytkownik / ścieżka

Następnie uruchom skrypt

[użytkownik @ maszynaA] $ ssh użytkownik @ maszynaB "/ home / user / path / script"

Działa to, jeśli dałeś uprawnienia do wykonywania skryptu.