bonne façon de sudo sur ssh

J'ai un script qui exécute un autre script via SSH sur un serveur distant en utilisant sudo. Cependant, lorsque je tape le mot de passe, il apparaît sur le terminal. (Sinon ça marche bien)

ssh user@server "sudo script"

Quelle est la bonne façon de faire cela afin que je puisse taper le mot de passe pour sudo sur SSH sans que le mot de passe n'apparaisse lorsque je tape?

Une autre façon consiste à utiliser le -tcommutateur pour ssh:

ssh -t user@server "sudo script"

Voir 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.

J'ai pu l'automatiser entièrement avec la commande suivante:

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

Avantages:

• pas d'invite de mot de passe
• n'affichera pas le mot de passe dans l'historique de la machine distante

En ce qui concerne la sécurité: comme Kurt l'a dit, exécuter cette commande affichera votre mot de passe sur votre historique bash local, et il est préférable de sauvegarder le mot de passe dans un fichier différent ou de sauvegarder la commande all dans un fichier .sh et de l'exécuter. REMARQUE: le fichier doit disposer des autorisations appropriées pour que seuls les utilisateurs autorisés puissent y accéder.

En supposant que vous ne vouliez pas d'invite de mot de passe :

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

Exemple

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

Sudo sur SSH en passant un mot de passe, aucun tty requis:

Vous pouvez utiliser sudo sur ssh sans forcer ssh à avoir un pseudo-tty (sans l'utilisation du commutateur ssh "-t") en disant à sudo de ne pas exiger de mot de passe interactif et de simplement récupérer le mot de passe de stdin. Pour ce faire, utilisez le commutateur "-S" sur sudo. Cela permet à sudo d'écouter le mot de passe sur stdin et d'arrêter d'écouter lorsqu'il voit une nouvelle ligne.

Exemple 1 - Commande à distance simple

Dans cet exemple, nous envoyons une whoamicommande simple :

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

Nous disons à sudo de ne pas émettre d'invite et de prendre ses entrées de stdin. Cela rend le mot de passe sudo passant complètement silencieux de sorte que la seule réponse que vous obtenez est la sortie whoami.

Cette technique a l'avantage de vous permettre d'exécuter des programmes via sudo sur ssh qui eux-mêmes nécessitent une entrée stdin. C'est parce que sudo consomme le mot de passe sur la première ligne de stdin, puis laisse le programme qu'il exécute continuer à saisir stdin.

Exemple 2 - Commande à distance qui nécessite son propre stdin

Dans l'exemple suivant, la commande distante "cat" est exécutée via sudo, et nous fournissons des lignes supplémentaires via stdin pour que le chat distant les affiche.

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

La sortie montre que le <remote_sudo_password> ligne est consommée par sudo et que le chat exécuté à distance affiche alors les lignes supplémentaires.

Un exemple où cela serait utile est si vous souhaitez utiliser ssh pour passer un mot de passe à une commande privilégiée sans utiliser la ligne de commande. Dites, si vous souhaitez monter un conteneur chiffré distant sur ssh.

Exemple 3 - Montage d'un conteneur VeraCrypt distant

Dans cet exemple de script, nous montons à distance un conteneur VeraCrypt via sudo sans aucun texte d'invite supplémentaire:

#!/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

Il convient de noter que dans tous les exemples de ligne de commande ci-dessus (tout sauf le script), la << EOFconstruction sur la ligne de commande entraînera l'enregistrement de tout ce qui est tapé, y compris le mot de passe, dans .bash_history de la machine locale . Il est donc fortement recommandé que pour une utilisation dans le monde réel, utilisez le faire entièrement via un script, comme l'exemple veracrypt ci-dessus, ou, si vous êtes sur la ligne de commande, mettez le mot de passe dans un fichier et redirigez ce fichier via ssh.

Exemple 1a - Exemple 1 sans mot de passe de ligne de commande local

Le premier exemple deviendrait ainsi:

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

Exemple 2a - Exemple 2 sans mot de passe de ligne de commande local

et le deuxième exemple deviendrait:

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

Il n'est pas nécessaire de mettre le mot de passe dans un fichier séparé si vous placez le tout dans un script, car le contenu des scripts ne finit pas dans votre historique. Cela peut néanmoins être utile au cas où vous souhaiteriez autoriser les utilisateurs qui ne devraient pas voir le mot de passe à exécuter le script.

Le meilleur moyen est ssh -t user@server "sudo <scriptname>", par exemple ssh -t user@server "sudo reboot". Il demandera d'abord le mot de passe de l'utilisateur, puis de root (puisque nous exécutons le script ou la commande avec le privilège root.

J'espère que cela a aidé et dissipé votre doute.

NOPASSdans la configuration sur votre machine cible est la solution. Continuez à lire sur 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

J'ai fait face à un problème,

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

Puis j'ai essayé avec

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

n'a pas fonctionné

#2
user1   ALL=(user2)         NOPASSWD: ALL

qui a fonctionné correctement!

En fonction de votre utilisation, j'ai eu du succès avec ce qui suit:

ssh root@server "script"

Cela demandera le mot de passe root, puis exécutera la commande correctement.