gpg encrypt file without keyboard interaction
BashCrontabGnupgBash Problem Overview
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) <[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)
Bash Solutions
Solution 1 - Bash
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.
Solution 2 - Bash
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
Solution 3 - Bash
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.
Solution 4 - Bash
Use this command, it will help you
echo "PASSPHRASE" | gpg --passphrase-fd 0 --always-trust -r USER --encrypt FILENAME.TX
Solution 5 - Bash
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
Solution 6 - Bash
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.
Solution 7 - Bash
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
Solution 8 - Bash
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)
Solution 9 - Bash
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