Comment utiliser l'argument mot de passe-fd de Gnupg?
Je voudrais utiliser la commande decrypt de GnuPG sans aucune intervention de l'utilisateur. Le script du --passphrase-fd l'argument semble exactement ce dont j'ai besoin. Mais je ne sais pas comment cela fonctionne - je n'ai pas trouvé d'exemples.
Quelqu'un pourrait-il me donner un exemple d'une telle commande, dans les environnements Windows et UNIX?
(Pour info, j'utilise GnuPG 2).
Merci déjà :)
Pour utiliser l'option gpg --passphrase-fd dans GnuPG v2, vous devez spécifier le --batch paramètre. Je vais d'abord expliquer comment --passphrase-fd fonctionne, puis accédez aux exemples.
--passphrase-fd indique à GnuPG de quelle descripteur de fichier (-fd) attendre la phrase secrète. Les descripteurs de fichiers standard sont STDIN (0), STDOUT (1) et STDERR (2). Pour le contexte de cette question, vous ne vous préoccuperiez normalement que de STDIN (0).
Vous n'avez pas spécifié d'où vous voulez que la phrase secrète provienne, donc je vais démontrer l'utilisation de STDIN (standard en) de différentes manières.
--passphrase-fd 0 indique à GnuPG de récupérer la phrase secrète de l'entrée dans le shell actuel; ainsi, par exemple, si vous souhaitez que GnuPG récupère les données de phrase secrète dans la ligne d'entrée de console la plus proche, la commande et la sortie seront comme suit:
gpg2 --batch --passphrase-fd 0 --armor --decrypt /path/to/encrypted_file.pgp
<next line of input is passphrase followed by hitting enter>
gpg: encrypted with 1024-bit RSA key, ID EC18C175, created 2013-10-26
"testkey4321 (4321) <[email protected]>"
this is a test... this is only a test...
Dans l'exemple ci-dessus, la phrase secrète a été fournie via le descripteur de fichier 0 (STDIN) - que nous avons fourni en l'entrant sur l'entrée standard actuelle du shell.
Dans l'exemple suivant, nous dirons à GnuPG de récupérer la phrase secrète d'entrée dans le shell actuel qui est en fait la sortie d'une autre commande (echo, dans ce cas, qui "écho" simplement ce que vous lui dites):
echo "mypassphrase" | gpg2 --batch --passphrase-fd 0 --armor --decrypt /path/to/encrypted_file.pgp
gpg: encrypted with 1024-bit RSA key, ID EC18C175, created 2013-10-26
"testkey4321 (4321) <[email protected]>"
this is a test... this is only a test...
Un autre exemple qui sauvegarde le contenu d'un fichier qui contient la phrase secrète vers STDIN -
cat /path/to/file_with_passphrase | gpg2 --batch --passphrase-fd 0 --armor --decrypt /path/to/encrypted_file.pgp
gpg: encrypted with 1024-bit RSA key, ID EC18C175, created 2013-10-26
"testkey4321 (4321) <[email protected]>"
this is a test... this is only a test...
En résumé, --passphrase-fd indique simplement à GnuPG que vous souhaitez lui fournir la phrase secrète requise via un descripteur de fichier standard; la différence entre GnuPG v2 et GnuPG est simplement le --batch paramètre.
Les exemples ci-dessus devraient fonctionner de la même manière dans les environnements Windows et * nix, à la seule différence que dans Windows - selon votre configuration et votre version - vous devrez remplacer cat par type dans l'ordre pour vider le contenu d'un fichier dans STDIN.
la réponse de kylehuff ne fonctionnerait toujours pas pour moi, avec gpupg affichant toujours une invite de mot de passe.
Selon https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase avec gnupg version 2.1.0 et supérieure, vous devez effectuer des étapes supplémentaires pour prendre en charge --passphrase-fd
Tout d'abord, modifiez la configuration de gpg-agent pour autoriser le mode de repérage en boucle: ~/.gnupg/gpg-agent.conf
allow-loopback-pinentryRedémarrez le processus gpg-agent s'il est en cours d'exécution pour laisser la modification prendre effet.
Deuxièmement, soit l'application doit être mise à jour pour inclure un paramètre de ligne de commande pour utiliser le mode de bouclage comme suit:
$ gpg --pinentry-mode loopback ...
Utilisation de GPG4win/gpg 2.2.3: pour utiliser le passphrase-fd 0 et contourner l'invite, je peux confirmer que les éléments suivants fonctionnent:
--pinentry-mode loopback
Comme j'ai dû le découvrir moi-même récemment, j'ai pensé que cela valait la peine de donner son avis.
La réponse de kylehuff est très bonne si vous décryptez des fichiers, cependant, si vous avez besoin d'une redirection d'entrée/sortie, comme la tuyauterie, voici un exemple d'utilisation d'un non0 Descripteur de fichier pour transmettre la phrase secrète.
#!/usr/bin/env bash
# Set some variables for easy modding
Var_fd='9'
Var_pass_location="/path/to/passphrase.file"
Var_gpg_decrypt_opts="--passphrase-fd ${Var_fd} --decrypt"
Var_output_location="out.txt"
Arr_string=( "$@" )
# Open file descriptor and shove the passphrase file into it
exec ${Var_fd}<${Var_pass_location}
# Pipe input array though gpg and append to output file
cat <<<"${Arr_string[*]}" | $(which gpg) ${Var_gpg_decrypt_opts} >> ${Var_output_location}
# Do not forget to close the file descriptor
exec ${Var_fd}>&-
Soyez averti, en dehors des cas d'utilisation spéciaux, que l'enregistrement de votre phrase secrète de clés privées est généralement considéré comme une mauvaise idée ou une mauvaise pratique de sécurité. - N'oubliez pas non plus de fermer le descripteur lorsque vous avez terminé afin que votre phrase secrète ne soit plus accessible via cette méthode.- Souvent, j'ai vu conseillé dans ces cas d'utilisation d'utiliser des clés protégées spécifiquement sans phrase secrète, mais c'est tout à fait votre choix . Si vous aimez le code ci-dessus, vous voudrez peut-être également extraire le script que j'ai débogué pour génération de clés sans assistance ou assisté car il couvre des options de descripteur de fichier gpg encore moins utilisées.
Modifications/mises à jour
J'ai donc débogué les opérations de décryptage en masse et j'ai des preuves pour montrer que les descripteurs de fichiers semblent se fermer automatiquement ou peut-être qu'il est fermé automatiquement par GnuPG. Vérifiez build 152 tout en bas des journaux bruts, juste avant diff vérifie, vous constaterez que le premier bloc de données chiffrées a mangé la phrase secrète en laissant les deux blocs de données suivants sans phrase secrète valide. Les scripts associés dans cette opération sont; d'abord le script de construction script_decrypt.sh définit la phrase secrète de la clé de test sur le descripteur de fichier 9 comme indiqué dans les exemples ci-dessus, alors le Script d'aide est appelé de telle sorte qu'il utilisera ce descripteur de fichier ... c'est un cas d'utilisation génial mais la morale de l'histoire semble que les opérations de décryptage en masse que vous envisagez de mettre en œuvre avec les descripteurs de fichiers GnuPG devront probablement suivre les étapes décrites ci-dessus dans leur ensemble pour que les descripteurs de fichiers soient correctement rouverts. Je vais réécrire le script d'aide au cours des prochaines poussées, alors vérifiez les journaux de build Travis-CI supérieurs à 152 pour savoir si j'ai une solution pour fermer les descripteurs de fichiers ...
... donc cela n'a pris que deux essais pour que les choses fonctionnent, voyez la différence de build 154 le fichier crypté et le journal d'entrée brut correspondent. Comme supposé, les descripteurs de fichiers sont vidés après la première utilisation par GnuPG ou un sous-shell, ainsi la phrase secrète doit être affectée avant chaque commande de décryptage pour que le décryptage en bloc se produise.
J'espère que cela vous a été précieux.