gpg crypter un fichier sans interaction du clavier

Je suis en cours d'exécution commande suivante dans un crontab pour crypter un fichier, et je ne veux pas d'une interaction entre le 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) <user@email.com>
 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)

Depuis --passphrase-fd lit à la première ligne... ce qui se produit si vous exécutez echo -e "PASSPHRASE" "\nyes" | gpg --passphrase-fd 0 -r USER --encrypt FILENAME.TXT ?
page de manuel de quelqu'un? --batch et --yes.

InformationsquelleAutor coto | 2012-02-27

Comme David l'a laissé entendre, le problème ici est que gpg ne pas faire confiance à la clé publique que vous utilisez pour les chiffrer. Vous pouvez vous inscrire à la clé comme il l'a expliqué.

Une alternative, surtout si la clé pourrait être en train de changer occasionnellement--serait de virer de bord sur --trust-model always de votre commande gpg.

Voici pertinentes bits à partir de la page de man:

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

Ne comprends pas pourquoi le système pense que du code. J'ai cliqué sur citer; pas de code. Lors de l'édition, il se montre tel que cité (sans couleur). Bizarre.
c'est parce que le texte utilise des espaces pour aligner.
cette réponse est la bonne pour moi! merci

InformationsquelleAutor rsaw

40

Voici ma solution, basée sur paquetages gpg2 (mais je parie que vous pouvez appliquer la même technique à gpg)
```
$ gpg2 --edit-key {recipient email address}  
> trust
> 5 (select 5 if you ultimately trust the key) 
> save
```
Cela indiquera paquetages gpg2 à faire confiance à la clé à fond, de sorte que vous pouvez crypter sans invite
- Cette mise à jour de la fiducie-db immédiatement et aucun enregistrement n'est requis.
- Cela définit le propriétaire ne font pas confiance la clé de validité. Confiance ultime est seulement pour vos propres Clés. c'est à dire Tout signé par un de Confiance en fin de compte, l'Identité est traitée comme signé par vous-même. Donc, NE PAS mettre de CONFIANCE À l'ULTIME si ce n'est pas votre clé. Le problème, c'est la clé de validité. Pour résoudre/solution de contournement, vous devez signer la clé. (pensez à un local uniquement, de signature et de vérification des empreintes digitales)
- x539 est droit. après gpg2 --edit-key <key-id> vous n' lsign et save. Je pense que la confiance 5 est une mauvaise utilisation de ce (mal compris), et (pour moi), il a même été inefficace (inutile), parce que ce x539 dit.
InformationsquelleAutor Antony
10

Le hack approche:
```
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 l'UTILISATEUR n'est pas signé. Si vous avez confiance, vous pouvez vous connecter avec
```
gpg --edit-key USER sign
```
Il va probablement poser quelques questions, en fonction de votre configuration. Le faire une fois, alors vous devriez être bon d'aller dans votre crontab. Je voudrais encore vous recommandons d'utiliser la solution que j'ai proposé, en mettant le mot de passe dans un fichier séparé et de faire qu'il ne soit lisible que par l'utilisateur qui commande s'exécute. Si vous faites cela, vous pouvez tuer le yes |, et viens de le chiffrer ligne.
- J'ai essayé le signe de la clé méthode, les deux paquetages gpg2 --edit-key connexion de l'UTILISATEUR, maintenant, il montre qu'il est signé, mais encore de la confiance:inconnu. Et le lot n'est toujours pas en run w/o invites
- Je pense que lsign serait une meilleure idée. N'est-il pas que si vous lsign ie. localement signer une clé, un signe qui reste sur votre ordinateur. Mais si vous suffit de vous inscrire, c'est considéré comme public, et, donc envoyé à un serveur de clés lorsque vous faites un --send-keys ?
InformationsquelleAutor David Souther

Utiliser cette commande, il vous aidera à

echo "PASSPHRASE" | gpg --passphrase-fd 0 --always-trust -r USER --encrypt FILENAME.TX

InformationsquelleAutor Anil

1

Je suppose que comme moi, beaucoup de gens viennent ici pour le "sans interaction du clavier" une partie de la question. Avec les paquetages gpg2 et gpg-agent, c'est devenu assez compliqué de signer/chiffrer/déchiffrer des trucs sans aucune interaction du clavier. Voici comment vous pouvez créer une signature lors de votre texte en clair de la clé privée de passe est enregistré dans un fichier texte:
```
cat something_so_sign.xzy | gpg \
    --passphrase-file "plaintext_passphrase.txt" \
    --batch \
    --pinentry-mode loopback \
    -bsa
```
Changement -b -s-a en fonction de vos besoins. Les autres commutateurs sont obligatoires. Vous pouvez aussi simplement utiliser --passphrase 'SECRET'. Comme l'a déjà souligné, être prudent avec ça. Les fichiers texte en clair sont pas beaucoup mieux, bien sûr.

InformationsquelleAutor LimeRed
0

Ou signer la clé (après vous veryfied l'empreinte, bien sûr):
```
gpg --sign-key <recipient email address>
```
Après que vous avez pleinement 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
```
- Faire confiance à la propriétaire n'a rien à voir avec ce problème. Seulement définir le propriétaire de confiance si vous lui faire confiance en ce qui concerne la signature/vérification des autres touches et leurs propriétaires
- Ianes pourquoi ne pas modifier votre réponse à la mise à jour des clés de la confiance? Actuellement, peuvent être trompeuses... Aussi --lsign-key peut-être une meilleure idée, non? voir mon autre commentaire à propos de lsign
InformationsquelleAutor lanes
0

J'ai été en cours d'exécution dans cette trop. Je n'arrivais pas à signer-clé pour faire quelque chose d'intéressant. Voici ce que j'ai fait:

créer une clé gpg:
```
gpg --gen-key
```
d'obtenir un ID de clé (le résultat est dans la 5ème colonne):
```
gpg --list-keys --with-colon name@domain.tld
```
Ajouter de confiance touche de ligne dans ~/gnupg/gpg.conf
```
trusted-key 16DIGITALPHANUMERICKEYID
```
gpg ligne dans le script de sauvegarde:
```
gpg -e -r name@domain.tld backup_file.tgz
```
De débogage cron:
Je suis également capturer cron dubugging de sortie par l'envoi de stdout et stderr dans un fichier journal dans le cron de ligne de commande. Il est utile de savoir
- Non, ne le faites pas. L'ajout d'un trusted-key ligne gpg.conf va provoquer gpg à toujours de confiance qui touche comme entièrement comme l'un des périls de l'utilisateur touches, ce qui est une mauvaise chose. En passant --trusted-key comme un argument, et seulement dans ce cas précis est acceptable (comme c'est en passant --trust-model=always de la même manière).
- C'est ma clé. N'est-ce pas le marquant comme de confiance exactement ce que je veux?
- Si c'est en fait, votre clé, alors oui, il faut le marquer comme finalement de confiance (même si personnellement, je préfère le faire avec --edit-key, non pas par l'ajout d'un trusted-key ligne). Le demandeur n'a pas dit que c'était leur clé gpg se plaint.
InformationsquelleAutor jorfus
0

Lorsque vous créez un certificat première fois avec votre e-mail-id select entièrement certificat de confiance alors à chaque fois que vous crypter n'importe quel fichier va poser pas de question, comme.... pour plus d'informations, ouvrez l'image dans le lien ci-dessus.

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 à la prochaine
question par oui.

Utiliser cette clé de toute façon? (o/N)

InformationsquelleAutor sumer raj
0

Une approche différente:
Pour refuser l'accès à des données sensibles (plutôt que de les chiffrer à l'aide de tiers clés), j'ai télécharger SEULEMENT* mon **PUBLIC clé pour le serveur je veux protéger les données et d'utiliser cette clé pour chiffrer avec. Cela supprime le besoin d'une invite de commandes pour la fourniture d'un mot de passe de faciliter l'automatisation et le meilleur de tous, le PRIVÉ clé est en dehors du serveur public.
```
gpg --batch --yes --trust-model always -r $YOURPUBKEYEMAILADDRESS -e ./file.txt
```
Toutefois, si PAS chiffrement à l'aide de votre propre clé publique, l'utilisation de l'interrupteur --trust-model always est un peu ropey. De toute façon, une autre manière de résoudre le problème de la négation de l'accès aux données. HTH - Terrence Houlahan

InformationsquelleAutor F1Linux

Vous devez vous connecter pour publier un commentaire.