没有键盘交互的 gpg 加密文件

The hack approach:

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

The underlying problem is that the key you have for USER isn't signed. If you trust it, you can sign it with

gpg --edit-key USER sign

It will probably ask a couple questions, depending on your configuration. Do this once, then you should be good to go in your crontab. I'd still recommend using the solution I proposed, putting the passphrase in a separate file and making it only readable by the one user that command runs as. If you do that, you can kill the yes |, and just have the encrypt line.

As David intimated, the problem here is that gpg doesn't trust the public key you're using to encrypt. You could sign the key as he explained.

An alternative--especially if the key might be changing occasionally--would be to tack on --trust-model always to your gpg command.

Here's the relevant bit from the man page:

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

Here is my solution, based on gpg2 (but I bet you can apply similar technique to gpg)

$ gpg2 --edit-key {recipient email address}
> trust
> 5 (select 5 if you ultimately trust the key)
> save

This will tell gpg2 to trust the key fully, so that you can encrypt without prompt

Or sign the key (after you veryfied the fingerprint, of course):

gpg --sign-key <recipient email address>

After that you fully trust the key.

  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

I was running into this too. I couldn't get sign-key to do anything interesting. Here's what I did:

create a gpg key:

gpg --gen-key

get long key ID (result is in 5th column):

gpg --list-keys --with-colon name@domain.tld

Add trusted key line to ~/gnupg/gpg.conf

trusted-key 16DIGITALPHANUMERICKEYID

gpg line in backup script:

gpg -e -r name@domain.tld backup_file.tgz

Debugging cron: I'm also capturing cron dubugging output by sending stdout and stderr to a log file in the cron command line. It's helpful to know

Use this command, it will help you

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

I assume that like me, a lot of people come here for the 'without keyboard interaction' part of the question. With gpg2 and gpg-agent it got quite complicated to sign/encrypt/decrypt stuff without any keyboard interaction. Here is how you would create a signature when your plaintext private key passphrase is saved in a text file:

cat something_so_sign.xzy | gpg \
--passphrase-file "plaintext_passphrase.txt" \
--batch \
--pinentry-mode loopback \
-bsa

Change -b -s -a depending on your needs. The other switches are mandatory. You may also just use --passphrase 'SECRET'. As already pointed out, be careful with that. Plaintext textfiles are not that much better of course.

When you create a certificate first time with your email-id select fully trusted certificate then whenever you encrypt any file will not ask question like.... for more information open image in above link.

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)

A different approach:

This solution will work without user input.

To deny access to sensitive data (rather than encrypt it using third-party's keys), I upload *ONLY my PUBLIC key to the server I want to protect data on and use that key to encrypt with. This negates the need for an interactive prompt to supply a password facilitating automation and best of all, the PRIVATE key is apart from the public server.

gpg --batch --yes --trust-model always -r $YOURPUBKEYEMAILADDRESS -e ./file.txt

However, if NOT encrypting with your own public key, the use of the switch --trust-model always is a bit ropey. Anyway, a different way of solving the problem of denying access to data. HTH- Terrence Houlahan