gpg chiffrer le fichier sans interaction clavier
J'exécute la commande suivante dans une crontab pour chiffrer un fichier et je ne souhaite pas d'interaction clavier
echo "PASSPHRASE" | gpg --passphrase-fd 0 -r USER --encrypt FILENAME.TXT
mais j'ai cette réponse:
gpg: C042XXXX: There is no assurance this key belongs to the named user
pub 40XXX/C042XXXX 2012-01-11 Name LastName. (comment) <[email protected]>
Primary key fingerprint: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
Subkey fingerprint: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N)
Comme David l'a laissé entendre, le problème est que gpg ne fait pas confiance à la clé publique que vous utilisez pour chiffrer. Vous pouvez signer la clé comme il l'a expliqué.
Une alternative - en particulier si la clé peut changer de temps en temps - serait d'ajouter --trust-model always à votre commande gpg.
Voici le bit pertinent de la page de manuel:
--trust-model pgp|classic|direct|always|auto Set what trust model GnuPG should follow. The models are: pgp This is the Web of Trust combined with trust signatures as used in PGP 5.x and later. This is the default trust model when creating a new trust database. classic This is the standard Web of Trust as used in PGP 2.x and earlier. direct Key validity is set directly by the user and not calculated via the Web of Trust. always Skip key validation and assume that used keys are always fully trusted. You generally won't use this unless you are using some external validation scheme. This option also suppresses the "[uncertain]" tag printed with signature checks when there is no evidence that the user ID is bound to the key. auto Select the trust model depending on whatever the internal trust database says. This is the default model if such a database already exists.
Voici ma solution, basée sur gpg2 (mais je parie que vous pouvez appliquer une technique similaire à gpg)
$ gpg2 --edit-key {recipient email address}
> trust
> 5 (select 5 if you ultimately trust the key)
> save
Cela dira à gpg2 de faire pleinement confiance à la clé pour pouvoir chiffrer sans invite
L'approche de hack:
echo -n PASSPHRASE > phrase
chmod 400 phrase #Make sure ONLY the user running the cron job can read the phrase
yes | gpg --passphrase-fd 3 --recipient USER --encrypt FILENAME.txt 3<phrase
Le problème sous-jacent est que la clé que vous avez pour USER n'est pas signée. Si vous y faites confiance, vous pouvez le signer avec
gpg --edit-key USER sign
Cela posera probablement quelques questions, selon votre configuration. Faites cela une fois, alors vous devriez être capable d'aller dans votre crontab. Je recommanderais toujours d'utiliser la solution que j'ai proposée, en plaçant la phrase secrète dans un fichier séparé et en la rendant uniquement lisible par l'utilisateur sous lequel la commande est exécutée. Si vous faites cela, vous pouvez tuer le yes | et simplement avoir la ligne de chiffrement.
Utilisez cette commande, elle vous aidera
echo "PASSPHRASE" | gpg --passphrase-fd 0 --always-trust -r USER --encrypt FILENAME.TX
Je suppose que, comme moi, beaucoup de gens viennent ici pour la partie «sans interaction au clavier» de la question. Avec gpg2 et gpg-agent, il est devenu assez compliqué de signer/chiffrer/déchiffrer des éléments sans aucune interaction clavier. Voici comment créer une signature lorsque votre phrase secrète de clé privée en texte brut est enregistrée dans un fichier texte:
cat something_so_sign.xzy | gpg \
--passphrase-file "plaintext_passphrase.txt" \
--batch \
--pinentry-mode loopback \
-bsa
Changez -b -s -a en fonction de vos besoins. Les autres commutateurs sont obligatoires. Vous pouvez aussi simplement utiliser --passphrase 'SECRET'. Comme déjà indiqué, faites attention à cela. Les fichiers texte en clair ne sont pas beaucoup mieux, bien sûr.
Une approche différente: Pourrefuser l'accèsaux données sensibles (plutôt que de les chiffrer à l'aide des clés d'un tiers), je télécharge SEULEMENT * mon ** PUBLIC clé sur le serveur, je veux protéger les données et utiliser cette clé pour chiffrer. Cela supprime la nécessité d'un invite interactif pour fournir un mot de passe facilitant l'automatisation et, mieux encore, la cléPRIVATEest distincte du serveur public.
gpg --batch --yes --trust-model always -r $YOURPUBKEYEMAILADDRESS -e ./file.txt
Cependant, siPASchiffrant avec votre propre clé publique, l’utilisation du commutateur --trust-model always est un peu compliquée. Quoi qu’il en soit, une autre façon de résoudre le problème du refus d’accès aux données. HTH- Terrence Houlahan
Je courais dans cela aussi. Je ne pouvais pas obtenir de clé pour faire quelque chose d'intéressant. Voici ce que j'ai fait:
créer une clé gpg:
gpg --gen-key
obtenir une clé longue (le résultat est dans la 5ème colonne):
gpg --list-keys --with-colon [email protected]
Ajouter une ligne de clé de confiance à ~/gnupg/gpg.conf
trusted-key 16DIGITALPHANUMERICKEYID
ligne gpg dans le script de sauvegarde:
gpg -e -r [email protected] backup_file.tgz
Débogage de cron: Je capture également la sortie de duplication de cron en envoyant stdout et stderr à un fichier journal dans la ligne de commande cron. Il est utile de savoir
Lorsque vous créez un certificat pour la première fois avec votre adresse e-mail, sélectionnez un certificat de confiance, puis chaque fois que vous chiffrez un fichier, aucune question ne se pose, par exemple .... pour plus d'informations, ouvrez l'image dans le lien précédent.
Il n'est PAS certain que la clé appartient à la personne nommée dans l'utilisateur ID. Si vous vraiment savez ce que vous faites, vous pouvez répondre au suivant question avec oui.
Utilisez cette clé quand même? (y/N)
Ou signez la clé (après avoir vérifié l’empreinte digitale, bien sûr):
gpg --sign-key <recipient email address>
Après cela, vous faites entièrement confiance à la clé.
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately