właściwy sposób na sudo przez ssh

Mam skrypt, który uruchamia inny skrypt przez SSH na zdalnym serwerze przy użyciu sudo. Jednak kiedy wpisuję hasło, pojawia się ono na terminalu. (W przeciwnym razie działa dobrze)

ssh user@server "sudo script"

Jaki jest właściwy sposób, aby to zrobić, abym mógł wpisać hasło sudo przez SSH bez pojawiania się hasła podczas wpisywania?

Innym sposobem jest użycie -tprzełącznika, aby ssh:

ssh -t user@server "sudo script"

Zobacz man ssh:

 -t      Force pseudo-tty allocation.  This can be used to execute arbi-
         trary screen-based programs on a remote machine, which can be
         very useful, e.g., when implementing menu services.  Multiple -t
         options force tty allocation, even if ssh has no local tty.

Udało mi się w pełni zautomatyzować to za pomocą następującego polecenia:

echo pass | ssh -tt user@server "sudo script"

Zalety:

• bez pytania o hasło
• nie pokaże hasła w historii bash komputera zdalnego

Odnośnie bezpieczeństwa: jak powiedział Kurt , uruchomienie tego polecenia pokaże twoje hasło w lokalnej historii basha i lepiej jest zapisać hasło w innym pliku lub zapisać polecenie all w pliku .sh i wykonać je. UWAGA: Plik musi mieć odpowiednie uprawnienia, aby tylko uprawnieni użytkownicy mieli do niego dostęp.

Zakładając, że nie chcesz monitować o hasło :

ssh $HOST 'echo $PASSWORD | sudo -S $COMMMAND'

Przykład

ssh me@localhost 'echo secret | sudo -S echo hi' # outputs 'hi'

Sudo przez SSH przekazując hasło, tty nie jest wymagane:

Możesz użyć sudo zamiast ssh bez zmuszania ssh do posiadania pseudo-tty (bez użycia przełącznika ssh "-t"), mówiąc sudo, aby nie wymagał interaktywnego hasła i po prostu przechwytywał hasło ze standardowego wejścia. Robisz to za pomocą przełącznika "-S" w sudo. To sprawia, że ​​sudo nasłuchuje hasła na stdin i przestaje nasłuchiwać, gdy zobaczy nową linię.

Przykład 1 - Proste zdalne polecenie

W tym przykładzie wysyłamy proste whoamipolecenie:

$ ssh user@server cat \| sudo --prompt="" -S -- whoami << EOF
> <remote_sudo_password>
root

Mówimy sudo, aby nie wydawało zachęty i pobierało dane wejściowe ze standardowego wejścia. To sprawia, że ​​hasło sudo przechodzi całkowicie cicho, więc jedyną odpowiedzią, którą otrzymujesz, jest wyjście whoami.

Ta technika ma tę zaletę, że umożliwia uruchamianie programów przez sudo przez ssh, które same wymagają wejścia stdin. Dzieje się tak, ponieważ sudo zużywa hasło w pierwszym wierszu stdin, a następnie pozwala dowolnemu programowi na kontynuowanie pobierania stdin.

Przykład 2 - zdalne polecenie, które wymaga własnego standardowego wejścia

W poniższym przykładzie zdalne polecenie „cat” jest wykonywane przez sudo, a my udostępniamy dodatkowe wiersze przez stdin, aby zdalny kot mógł wyświetlić.

$ ssh user@server cat \| sudo --prompt="" -S -- "cat" << EOF
> <remote_sudo_password>
> Extra line1
> Extra line2
> EOF
Extra line1
Extra line2

Dane wyjściowe pokazują, że <remote_sudo_password>linia jest używana przez sudo i że zdalnie wykonany cat wyświetla dodatkowe linie.

Przykładem sytuacji, w której byłoby to korzystne, jest użycie ssh do przekazania hasła do uprzywilejowanego polecenia bez korzystania z wiersza poleceń. Powiedzmy, jeśli chcesz zamontować zdalny zaszyfrowany kontener przez ssh.

Przykład 3 - Montowanie zdalnego kontenera VeraCrypt

W tym przykładowym skrypcie zdalnie montujemy kontener VeraCrypt przez sudo bez dodatkowego tekstu zachęty:

#!/bin/sh
ssh user@server cat \| sudo --prompt="" -S -- "veracrypt --non-interactive --stdin --keyfiles=/path/to/test.key /path/to/test.img /mnt/mountpoint" << EOF
SudoPassword
VeraCryptContainerPassword
EOF

Należy zauważyć, że we wszystkich przykłady wiersza polecenia powyżej (wszystko z wyjątkiem scenariusza) Do << EOFkonstruktu w wierszu poleceń spowoduje, że wszystko wpisane, w tym hasło, które mają być rejestrowane w lokalnych .bash_history urządzenia. Dlatego zdecydowanie zaleca się, aby w prawdziwym świecie używać go w całości za pomocą skryptu, jak powyższy przykład veracrypt, lub, jeśli w wierszu poleceń, umieścić hasło w pliku i przekierować ten plik przez ssh.

Przykład 1a - Przykład 1 bez lokalnego hasła wiersza poleceń

Tak więc pierwszy przykład wyglądałby następująco:

$ cat text_file_with_sudo_password | ssh user@server cat \| sudo --prompt="" -S -- whoami
root

Przykład 2a - Przykład 2 bez lokalnego hasła wiersza poleceń

a drugi przykład to:

$ cat text_file_with_sudo_password - << EOF | ssh va1der.net cat \| sudo --prompt="" -S -- cat
> Extra line1
> Extra line2
> EOF
Extra line1
Extra line2

Umieszczenie hasła w osobnym pliku nie jest konieczne, jeśli umieszczasz całość w skrypcie, ponieważ zawartość skryptów nie trafia do historii. Jednak nadal może być przydatne, jeśli chcesz zezwolić użytkownikom, którzy nie powinni widzieć hasła, na wykonanie skryptu.

Najlepszym sposobem jest ssh -t user@server "sudo <scriptname>"na przykład ssh -t user@server "sudo reboot". Najpierw zapyta o hasło użytkownika, a następnie roota (ponieważ uruchamiamy skrypt lub polecenie z uprawnieniami roota.

Mam nadzieję, że pomogło i rozwiało twoje wątpliwości.

NOPASSw konfiguracji na komputerze docelowym jest rozwiązaniem. Kontynuuj czytanie na http://maestric.com/doc/unix/ubuntu_sudo_without_password

echo $VAR_REMOTEROOTPASS | ssh -tt -i $PATH_TO_KEY/id_mykey $VAR_REMOTEUSER@$varRemoteHost 
echo \"$varCommand\" | sudo bash

Napotkałem problem,

user1@server1$ ssh -q user1@server2 sudo -u user2 rm -f /some/file/location.txt

Output:
sudo: no tty present and no askpass program specified

Potem spróbowałem

#1
vim /etc/sudoers
Defaults:user1    !requiretty

nie zadziałało

#2
user1   ALL=(user2)         NOPASSWD: ALL

to działało poprawnie!

W zależności od Twojego zastosowania odniosłem sukces w następujących przypadkach:

ssh root@server "script"

Spowoduje to wyświetlenie monitu o hasło roota, a następnie poprawne wykonanie polecenia.