bonne façon de sudo sur ssh


150

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?


2
quant à moi, la raison de chercher un moyen de sudo via ssh était que cela ne fonctionnait pas en essayant quelque chose comme ssh <user@server> sudo <script>, car j'obtenais l'erreursudo: no tty present and no askpass program specified
knocte

Réponses:


244

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.

2
Bien, je connaissais l'option -t, je ne savais tout simplement pas que cela fonctionnait pour les invites sudo.

3
à quoi sert l'option -t?
Vince


3
Cela ne fonctionne pas ici: ssh -t localhost <<< "sudo touch file;"EDIT Apparemment, il est important que vous fournissiez réellement la commande en tant que paramètre, pas par le biais de standard in (ce qui a du sens avec le recul).
Expiation limitée du

la -tméthode affichera également la sortie colorée des commandes qui le font normalement.
karmakaze

24

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.


8
Il apparaîtra dans l'historique bash du système local, y compris le mot de passe. Mieux vaut stocker le mot de passe dans un fichier et chatter le fichier.
Kurt Fitzner

4
Mec, je savais -t, mais je n'avais pas lu le manuel assez attentivement pour voir que tu pouvais le passer deux fois! C'est ce que je cherchais depuis des mois! Pour plus de sécurité, j'ai simplement défini une variable de mot de passe avant d'exécuter avec read -s -p "Password: " pw, puis je l'ai fait echo "$pw" | ..... J'ai maintenant roulé ceci dans un script pratique pour moi :).
kael le

A fonctionné comme du charme pour moi!
MiKr13

Pourquoi ne configurez-vous pas simplement sudo sans mot de passe pour les utilisateurs et commandes spécifiques que vous devez exécuter? Ce n'est pas un problème SSH ...
nomen

@nomen votre solution est également valide, mais nécessite des étapes supplémentaires. Si j'ai beaucoup d'appareils sans utilisateur sudo sans mot de passe, je peux créer un script d'automatisation à l'aide de cette solution. Parfois, vous travaillez sur un système qui ne vous appartient pas et que vous ne voulez pas ou ne pouvez pas apporter de modifications, parfois il y a d'autres considérations.
ofirule

6

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'

14
C'est / très / dangereux car le mot de passe en clair se retrouve sur la ligne de commande. Les lignes de commande sont publiques et peuvent être vues par tous les autres utilisateurs et processus du système. Par exemple, "ps auxwwwww" par un utilisateur non privilégié affichera tous les processus en cours d'exécution et les lignes de commande qui les ont exécutés.
Kurt Fitzner

3
Sans oublier de mettre votre mot de passe (en texte clair) dans le fichier bash_history.
Layne Bernardo

5

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.


Dans la commande à distance ssh, pourquoi avez-vous besoin d'exécuter catet de diriger les résultats vers sudo? Pouvez-vous simplement utiliser sudocomme commande principale à distance ssh?
joanpau

@joanpau L'initiale catest utilisée pour diriger le mot de passe de l'utilisateur vers sudo de l'autre côté. Si l'utilisateur peut exécuter sudo sans mot de passe, ce n'est pas obligatoire, mais je ne suggère pas cette configuration. La raison pour laquelle il est envoyé est d'empêcher le mot de passe de s'afficher sur la ligne de commande du système distant. Les lignes de commande ne sont pas sécurisées, tout utilisateur peut voir chaque ligne de commande avec ps auxwww.
Kurt Fitzner

Je demande le catdans la commande ssh cat \| sudo --prompt="" -S.... Si les -Sforces sudopour lire le mot de passe de stdin, le chat et le tuyau sont-ils vraiment nécessaires? La commande ssh pourrait-elle être simplement sudo --prompt="" -S...?
joanpau

@jonpau Cette commande cat prend stdin et le fait passer par sudo afin de lui transmettre le mot de passe sudo. Il montre comment vous pouvez diriger le mot de passe sudo via ssh via stdin en toute sécurité.
Kurt Fitzner

1

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.




-1

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!


Cela n'accomplit pas vraiment ce qui est demandé. L'idée est de toujours exiger le mot de passe, mais de lui permettre d'être tapé sur ssh. Ce que vous avez fait, c'est simplement donner à user1 un accès sudo complet à user2 sans mot de passe. C'est bien pour des applications spécifiques, mais ce n'est pas la meilleure idée en tant que solution générale.
Possum

-7

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.


26
Yikes, SSH en tant que root? C'est une mauvaise idée pour toutes sortes de raisons.
darkfeline

12
N'oubliez pas que ssh n'est pas telnet. Il n'est pas plus dangereux de ssh en tant que root que de ssh en tant qu'autre utilisateur et d'exécuter sudo. Votre mot de passe est crypté de la même manière sur la connexion ssh.
Stéphane

22
Stéphane a absolument raison en ce qui concerne la sécurité des mots de passe. Cependant, en utilisant root au lieu de sudo, vous perdez la piste d'audit qui accompagne sudo. En outre, l'accès root peut ne pas être disponible.
djeikyb
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.