gpg encrypt file without keyboard interaction

Question

I am running next command within a crontab to encrypt a file and I don't want a keyboard interaction

echo "PASSPHRASE" | gpg --passphrase-fd 0 -r USER --encrypt FILENAME.TXT

but I have this answer:

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)

Since --passphrase-fd reads only the first line... what happens if you run `echo -e "PASSPHRASE" "\nyes" | gpg --passphrase-fd 0 -r USER --encrypt FILENAME.TXT` ? — David Costa, Feb 27 '12 at 12:54

score 77 · Accepted Answer · edited Oct 16 '14 at 18:44

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.

Don't understand why the system thinks that's code. I clicked quote; not code. When editing it shows up only as quoted (with no color). Weird. — rsaw, Feb 27 '12 at 14:25

score 46 · Answer 2 · answered Feb 02 '13 at 02:30

46

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

answered Feb 02 '13 at 02:30

Antony

5,068
7
24
31

1

This updates the trust-db immediately and no save is required. – lanes Oct 23 '13 at 11:09
12

This sets the owner-trust not the key-validity. Ultimate Trust is only for your own Keys. i.e. Everything signed by an Ultimately Trusted Identity is handled as signed by your self. So DO NOT SET TRUST TO ULTIMATE if it is not your key. The problem is the key-validity. To solve/workaround this you should sign the key. (consider a local-only signature and fingerprint verification) – x539 Jul 26 '14 at 13:00
3

x539 is right. after `gpg2 --edit-key ` you do **`lsign`** and `save`. I think the trust 5 is wrong use for this (misunderstood), and (for me) it was even ineffective (useless), becuase what x539 told. – n611x007 Jan 19 '16 at 07:15
Note that this also works for normal `gpg`, not only for `gpg2` :) – Markus Aug 25 '20 at 15:54

score 10 · Answer 3 · answered Feb 27 '12 at 14:07

10

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.

answered Feb 27 '12 at 14:07

David Souther

7,863
2
33
51

1

I tried the sign key method, both gpg2 --edit-key USER sign, now it shows that it is signed, but still trust:unknown. And the batch still will not run w/o prompting – nycynik Aug 22 '12 at 19:40
2

I think `lsign` would be a better idea. Is it not that if you lsign ie. locally sign a key, that sign stays on your computer. But if you simply sign, that's considered public, and thus would be sent to keyservers when you do a `--send-keys` ? – n611x007 Jan 19 '16 at 07:23

score 2 · Answer 4 · edited Nov 21 '16 at 12:27

2

Use this command, it will help you

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

edited Nov 21 '16 at 12:27

Rohan Khude

3,604
5
43
37

answered Nov 21 '16 at 10:54

Anil

21
1

score 1 · Answer 5 · answered Jun 15 '15 at 20:33

1

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

answered Jun 15 '15 at 20:33

jorfus

2,057
19
21

1

No, don't do that. Adding a `trusted-key` line to `gpg.conf` will cause `gpg` to _always_ trust that key _as fully as one of the user's own keys_, [which is a bad thing](https://stackoverflow.com/q/9460140#comment38816101_14658006). Passing `--trusted-key` as an _argument_, and only in _this specific case_ is acceptable (as is [passing `--trust-model=always` in the same way](https://stackoverflow.com/a/9466566)). – Blacklight Shining Dec 13 '15 at 20:46
It is my key. Isn't marking it as trusted exactly what I want? – jorfus Feb 09 '16 at 20:21
1

If it's _actually_ your key, then yes, mark it as ultimately trusted (though I personally prefer to do that with `--edit-key`, not by adding a `trusted-key` line). The asker didn't say that it was _their own_ key that `gpg` was complaining about. – Blacklight Shining Feb 11 '16 at 11:06

score 1 · Answer 6 · answered Apr 16 '18 at 19:25

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.

score 0 · Answer 7 · answered Oct 23 '13 at 12:05

0

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

answered Oct 23 '13 at 12:05

lanes

1,622
1
15
19

5

Trusting the owner has nothing to do with this problem. Only set the owner trust if you trust him in regard to signing/verifying other keys and their owners – x539 Jul 26 '14 at 13:08
Ianes why not edit your answer to update about key trust? Currently may be misleading... Also `--lsign-key` may be a better idea, no? see [my other comment](https://stackoverflow.com/questions/9460140/gpg-encrypt-file-without-keyboard-interaction#comment57479879_9466332) about lsign – n611x007 Jan 19 '16 at 07:26

score 0 · Answer 8 · edited Jun 22 '18 at 09:48

enter image description here

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)

F1Linux · Answer 9 · 2021-01-22T21:08:13.257

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

gpg encrypt file without keyboard interaction

9 Answers9

Linked