Jak mogę uruchomić dowolnie złożone polecenie za pomocą sudo over ssh?

Mam system, do którego mogę się logować tylko pod moją nazwą użytkownika (myuser), ale muszę uruchamiać polecenia jako inny użytkownik (scriptuser). Do tej pory wymyśliłem następujące polecenia, aby uruchomić potrzebne mi polecenia:

ssh -tq myuser@hostname "sudo -u scriptuser bash -c \"ls -al\""

Jeśli jednak, gdy spróbuję uruchomić bardziej złożone polecenie, takie jak [[ -d "/tmp/Some directory" ]] && rm -rf "/tmp/Some directory"szybko, mam problem z cytowaniem. Nie jestem pewien, w jaki sposób mógłbym przekazać to przykładowe złożone polecenie bash -c, gdy \"już wyznaczam granice przekazywanego polecenia (a więc nie wiem, jak cytować katalog / tmp / Some, który zawiera spacje.

Czy istnieje ogólne rozwiązanie pozwalające mi przekazać dowolne polecenie bez względu na to, jak skomplikowane / szalone jest cytowanie, czy też jest to jakieś ograniczenie, które osiągnąłem? Czy istnieją inne możliwe i być może bardziej czytelne rozwiązania?

Trik, którego czasami używam, to użycie base64 do kodowania poleceń i potokowanie go w celu uderzenia w drugą stronę:

MYCOMMAND=$(base64 -w0 script.sh)
ssh user@remotehost "echo $MYCOMMAND | base64 -d | sudo bash"

Spowoduje to zakodowanie skryptu ze wszystkimi przecinkami, ukośnikami odwrotnymi, cudzysłowami i zmiennymi wewnątrz bezpiecznego ciągu i wysłanie go na inny serwer. ( -w0jest wymagany do wyłączenia zawijania linii, co domyślnie ma miejsce w kolumnie 76). Z drugiej strony, $(base64 -d)dekoduje skrypt i podaje go do bash, aby został wykonany.

Nigdy nie miałem z tym żadnego problemu, bez względu na to, jak skomplikowany był skrypt. Rozwiązuje problem ucieczki, ponieważ nie musisz niczego uciekać. Nie tworzy pliku na zdalnym hoście i możesz z łatwością uruchamiać bardzo skomplikowane skrypty.

Widzisz -ttopcję? Przeczytaj ssh(1)instrukcję.

ssh -tt root@host << EOF
sudo some # sudo shouldn't ask for a password, otherwise, this fails. 
lines
of
code 
but be careful with \$variables
and \$(other) \`stuff\`
exit # <- Important. 
EOF

Często używam vima i :!cat % | ssh -tt somemachinetrików.

Myślę, że najłatwiejszym rozwiązaniem jest modyfikacja komentarza @ thanasisk.

Utwórz skrypt scpna maszynie, a następnie uruchom go.

Miej rmsam skrypt na początku. Powłoka otworzyła plik, więc został załadowany i można go bez problemu usunąć.

Wykonując czynności w tej kolejności ( rmpo pierwsze, inne po drugie), zostanie nawet usunięty, gdy w pewnym momencie zawiedzie.

Możesz użyć specyfikatora %qformatu, printfaby zająć się zmienną dla Ciebie:

cmd="ls -al"
printf -v cmd_str '%q' "$cmd"
ssh user@host "bash -c $cmd_str"

printf -vzapisuje dane wyjściowe do zmiennej (w tym przypadku $cmd_str). Myślę, że to najprostszy sposób na zrobienie tego. Nie ma potrzeby przesyłania żadnych plików ani kodowania ciągu poleceń (tak jak lubię lewę).

Oto bardziej złożony przykład pokazujący, że działa również w przypadku nawiasów kwadratowych i ampersandów:

$ ssh user@host "ls -l test"
-rw-r--r-- 1 tom users 0 Sep  4 21:18 test
$ cmd="[[ -f test ]] && echo 'this really works'"
$ printf -v cmd_str '%q' "$cmd"
$ ssh user@host "bash -c $cmd_str"
this really works

Nie testowałem tego, sudoale powinno to być tak proste, jak:

ssh user@host "sudo -u scriptuser bash -c $cmd_str"

Jeśli chcesz, możesz pominąć krok i uniknąć tworzenia zmiennej pośredniej:

$ ssh user@host "bash -c $(printf '%q' "$cmd")"
this really works

Lub nawet po prostu unikaj tworzenia zmiennej całkowicie:

ssh user@host "bash -c $(printf '%q' "[[ -f test ]] && echo 'this works as well'")"

Oto „poprawny” (syntaktyczny) sposób wykonania czegoś takiego w bash:

ssh user@server "$( cat <<'EOT'
echo "Variables like '${HOSTNAME}' and commands like $( uname -a )"
echo "will be interpolated on the server, thanks to the single quotes"
echo "around 'EOT' above.
EOT
)"

ssh user@server "$( cat <<EOT
echo "If you want '${HOSTNAME}' and $( uname -a ) to be interpolated"
echo "on the client instead, omit the the single quotes around EOT."
EOT
)"

Aby uzyskać dokładne wyjaśnienie, jak to działa, zobacz https://stackoverflow.com/a/21761956/111948

Czy wiesz, że możesz użyć, sudoaby dać ci powłokę, w której możesz uruchamiać polecenia jako wybrany użytkownik?

-i, --login

Uruchom powłokę określoną przez wpis bazy danych haseł użytkownika docelowego jako powłokę logowania. Oznacza to, że pliki zasobów specyficzne dla logowania, takie jak .profile lub .login, zostaną odczytane przez powłokę. Jeśli podano polecenie, jest ono przekazywane do powłoki w celu wykonania za pomocą opcji -c powłoki. Jeśli nie podano polecenia, wykonywana jest powłoka interaktywna. sudo próbuje przejść do katalogu domowego tego użytkownika przed uruchomieniem powłoki. Polecenie jest uruchamiane w środowisku podobnym do środowiska, które użytkownik otrzyma podczas logowania. Sekcja Środowisko poleceń w dokumentacji podręcznika sudoers (5), w jaki sposób opcja -i wpływa na środowisko, w którym polecenie jest uruchamiane, gdy używana jest polityka sudoers.

Możesz zdefiniować skrypt na komputerze lokalnym, a następnie catprzesłać go do zdalnego komputera:

user@host:~/temp> echo "echo 'Test'" > fileForSsh.txt
user@host:~/temp> cat fileForSsh.txt | ssh localhost

Pseudo-terminal will not be allocated because stdin is not a terminal.
stty: standard input: Invalid argument
Test

Proste i łatwe.

ssh użytkownik @ servidor "bash -s" <script.sh

Jeśli używasz wystarczająco nowoczesnej powłoki Bash, możesz umieścić swoje polecenia w funkcji i wydrukować tę funkcję jako ciąg znaków export -p -f function_name. Wynik tego ciągu może następnie zawierać dowolne polecenia, które niekoniecznie muszą być uruchamiane jako root.

Przykład użycia potoków z mojej odpowiedzi na Unix.SE :

#!/bin/bash
remote_main() {
   local dest="$HOME/destination"

   tar xzv -C "$dest"
   chgrp -R www-data "$dest"
   # Ensure that newly written files have the 'www-data' group too
   find "$dest" -type d -exec chmod g+s {} \;
}
tar cz files/ | ssh user@host "$(declare -pf remote_main); remote_main"

Przykład, który pobiera, zapisuje plik dla zalogowanego użytkownika i instaluje program root:

remote_main() {
    wget https://example.com/screenrc -O ~/.screenrc
    sudo apt-get update && sudo apt-get install screen
}
ssh user@host "$(declare -pf remote_main); remote_main"

Jeśli chcesz uruchomić całą komendę sudo, możesz użyć tego:

remote_main() {
    wget https://example.com/screenrc -O ~user/.screenrc
    apt-get update && apt-get install screen
}
ssh user@host "$(declare -pf remote_main);
    sudo sh -c \"\$(declare -pf remote_main); remote_cmd\""
# Alternatively, if you don't need stdin and do not want to log the command:
ssh user@host "$(declare -pf remote_main);
    (declare -pf remote_main; echo remote_cmd) | sudo sh"

Oto moje (nie tak naprawdę przetestowane) gówniane rozwiązanie:

#!/usr/bin/env ruby
# shell-escape: Escape each argument.
ARGV.each do|a|
  print " '#{a.gsub("'","\'\\\\'\'")}' "
end

Nie możesz zrobić:

ssh -tq myuser@hostname "$(shell-escape sudo -u scriptuser bash -c "$(shell-escape ls -al)")"

Następnym krokiem jest utworzenie bettersshskryptu, który już to robi:

betterssh -tq myuser@hostname sudo -u scriptuser bash -c "$(shell-escape ls -al)"

Dla tych z was, którzy muszą przekazać parametry do skryptu, powinno to wyglądać następująco:

ssh user@remotehost "echo `base64 -w0 script.sh` | base64 -d | sudo bash -s <param1> <param2> <paramN>"

Najpierw utwórz skrypt lokalny, a następnie uruchom go zdalnie za pomocą następującego polecenia:

cat <Local Script.sh> | ssh user@server "cat - | sudo -u <user> /bin/bash"