SUSE Support

Here When You Need Us

gpg prompts for passphrase after upgrade to SLES 15 which includes gpg2 package 2.2.5

This document (000020595) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15

Situation

A scripted gpg command to decrypt a file was in use on SLES 11 or SLES 12, which uses gpg2 package version 2.0.x-x.  The command includes a passphrase, so it should not need to prompt for one.  This is important because this script will run unattended.  For example:

gpg --yes --batch --passphrase "xxxxx" --output unencrypt.txt --decrypt source.txt.asc

However, after upgrade to SLES 15 which includes gpg2 package version 2.2.5-x, the above command still prompts for a passphrase (if one is not already held in cache).

Resolution

Remove the "--batch" option and replace it with "--pinentry-mode loopback".  For example:

gpg --yes --pinentry-mode loopback --passphrase "xxxxx" --output unencrypt.txt --decrypt source.txt.asc

Cause

The default behavior of gpg has changed as of gpg2 v2.1.  In the man page for gpg, within the explanation of the
--passphrase option, the following statement is now present:

     "Since Version 2.1 the --pinentry-mode also needs to be set to loopback."

Additional Information

While testing various syntax for whether or not gpg prompts for a passphrase, it can be frustrating that the same syntax will sometimes prompt for passphrase but sometimes it will not.  This is usually because a correctly accepted passphrase will be cached for a period of time (10 minutes by default), making it unnecessary to request it on subsequent executions.  Therefore, while testing for correct command syntax, it can be useful to turn off the cache.

One confirmed way to do this:

In the home directory of the user who will be executing gpg, edit (or create) the file:
~/.gnupg/gpg-agent.conf

Within that file, set the option:   default-cache-ttl 0

Save that.  Then find the gpg-agent for that user with:
ps aux | grep gpg-agent | grep <username>

For example:

sles15sp2:~ # ps aux | grep gpg-agent | grep root
root       8748  0.0  0.1 166368  1292 ?        Ss   17:38   0:00 gpg-agent --homedir /root/.gnupg --use-standard-socket --daemon
root       8819  100  0.0   7424   860 pts/1    S+   17:49   0:00 grep --color=auto gpg-agent


In the above example, the PID of the agent is 8748.

Kill the process with it's PID.  In this example, the command would be:
kill 8748
 
Then make new attempts at using gpg from the command line.  This should automatically cause gpg-agent to launch again, and will now use the new cache time (0 = no cache).  With the cache off, testing gpg and interpreting the results should be more reliable.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:000020595
  • Creation Date: 24-Feb-2022
  • Modified Date:16-Mar-2022
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

tick icon

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

tick icon

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

tick icon

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.