Signing outgoing emails using GPG in mutt: "Permission Denied?"

dogemeister · 04-27-2024, 02:33 AM

I'm having the timiest of times getting the mutt email client to sign outgoing emails with my GPG key. Here's my .muttrc currently, as suggested here:

Code:

set crypt_use_gpgme=yes
set postpone_encrypt = yes
set pgp_self_encrypt = yes
set crypt_use_pka = no
set crypt_autosign = no
set crypt_autoencrypt = no
set crypt_autopgp = yes
set pgp_sign_as=0xblahblahblah

Eventually I'd like to have autosign on, but for now I hit 'p', then 's' to sign with the key specified above. I keep getting the following error after hitting 'y' to send:

Code:

error signing data: Permission denied?

Google gives me nothing when I quote this message.

I've got gpg-agent and pinentry installed. Working in an ssh session (not trying to tunnel or anything like that). Running mutt as root. Root attained via "su -" from a standard user. No X server running. I've tried several things:

environment variables

export GPG_TTY=$(tty)
export GPG_AGENT_INFO=~/.gnupg/S.gpg-agent

.gnupg/gpg-agent.conf options (of varying combinations):

pinentry-program /usr/bin/pinentry
allow-loopback-pinentry
use-standard-socket
enable-ssh-support

My best hunch at the moment is some permissions quirk of using "su -", but that's just where I'm at now. I've tried running mutt as a regular user (with its own generated GPG key) to no avail, still the same "Permission denied?" message after trying to send. Makes me worried it could be some missing package. Could use some help on this one!

BrunoLafleur · 04-27-2024, 05:17 AM

It seems that doing su in a user ssh session will throw an error with gpg.

Some explanation and a remedy if you do want to work with su (is beeing root really necessary for your task ?) :

https://askubuntu.com/questions/1080...mission-denied

dogemeister · 04-27-2024, 09:13 AM

Thanks for mentioning that. I thought I had already accounted for that by using the same .muttrc with a user with lesser privileges. However, that user was *not* the same as the one I ssh'd to, and I had used 'su -' already. To clarify, the following did not work:

Code:

me@elsewhere:~$ ssh usera@place
usera@place:~$ su - root
root@place:~$ *fail to sign mutt email*

me@elsewhere:~$ ssh usera@place
usera@place:~$ su - root
root@place:~$ su - userb
userb@place:~$ *fail to sign mutt email*

me@elsewhere:~$ ssh usera@place
usera@place:~$ su - userb
userb@place:~$ *fail to sign mutt email*

What did work:

Code:

me@elsewhere:~$ ssh usera@place
usera@place:~$ *successfully sign and send mutt email*

So I could just add userb to my AllowUsers in sshd_config. However, I did figure out what my problem was with using 'su -' beforehand. Had to do with the tty ownership remaining with the initial user usera before 'su -' was invoked.

Code:

userb@place:~$ ls -lh $(tty)
crw--w---- 1 usera tty 136, 2 Apr 27 17:09 /dev/pts/2

So long as the active user owned the tty it was using, mutt had no problem signing the email.

SlackCoder · 04-30-2024, 07:49 AM

My bet is it is an environment variable issue, try 'su --login ..' or 'sudo --login ..', and check GNUPGHOME is set correctly.