ssh sign request failed: IPC syntax error <Pinentry> in KDE

cfr · 2017-10-05 04:02:03

I'm just installing Arch on a new laptop. I did have ssh working with gpg-agent to access a remote box configured for passwordless authentication. However, I screwed something up on the server side and accidentally enabled password authentication. That is fixed, but I cannot now authenticate using my public key.

I had this working with gpg-agent in a minimal X session using lwm. However, I can't reproduce the configuration I had on my defunct laptop, which used the same process to access the same server in KDE. I also couldn't get it to work reliably even with lwm - sometimes it worked; sometimes I had to reboot and I couldn't tell why.

ssh -v <hostname> produces

OpenSSH_7.5p1, OpenSSL 1.1.0f  25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for fenw
debug1: /etc/ssh/ssh_config line 32: Applying options for *
debug1: Connecting to <ip address> port 22.
debug1: Connection established.
debug1: identity file /home/myusername/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myusername/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myusername/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myusername/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myusername/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myusername/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myusername/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myusername/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5
debug1: match: OpenSSH_7.5 pat OpenSSH* compat 0x04000000
debug1: Authenticating to <ip address> as 'myusername'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:+BZPkgOdvHtL4bvgJ/3mgD9FG+mzRE5t3D/KNSN2oS0
debug1: Host 'ip' is known and matches the ECDSA host key.
debug1: Found key in /home/myusername/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,null>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myusername/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
sign_and_send_pubkey: signing failed: agent refused operation
debug1: Trying private key: /home/myusername/.ssh/id_dsa
debug1: Trying private key: /home/myusername/.ssh/id_ecdsa
debug1: Trying private key: /home/myusername/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

I *think* this means that the problem is with opening the private key on my end. No pinentry programme is being triggered to allow me to unlock the key, so it isn't surprising that signing fails. What I can't work out is why the agent is not triggering the pinentry request.

~/.pam_environment

# https://wiki.archlinux.org/index.php/GnuPG#Start_gpg-agent_with_systemd_user

SSH_AGENT_PID   DEFAULT=
SSH_AUTH_SOCK   DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"

# vim: set nospell:

.gnupg/gpg-agent.conf

# GPGConf disabled this option here at Dydd Llun 08 mis Medi 2014 21:43:30 BST
# default-cache-ttl 300
# GPGConf disabled this option here at Dydd Llun 08 mis Medi 2014 21:43:30 BST
# max-cache-ttl 999999
###+++--- GPGConf ---+++###
default-cache-ttl 300
max-cache-ttl 3000
###+++--- GPGConf ---+++### Dydd Llun 08 mis Medi 2014 21:43:30 BST
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.
pinentry-program /usr/bin/pinentry-qt
enable-ssh-support
# vim: set nospell:

Permissions on my home directory and ~/.ssh are 700. ~/.ssh/id_rsa has permissions of 400 and ~/.ssh/id_rsa.pub and ~/.ssh/known_hosts have permissions of 644. These files are restored from backup, so I'm certain they are no different. In any case, although I'm checking these obsessively, I assume they don't have a particular dislike of KDE, so it isn't clear why it worked with lwm. It must be something else I've done or missed.

/etc/bash.bashrc includes

<stuff unrelated to GPG/SSH>
...

export GPG_TTY=$(tty)

# also from man gpg-agent (gpg-agent info is no longer used, I think)
unset SSH_AGENT_PID
# I don't really understand what this does - what is the purpose of the check exactly?
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
        export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
fi

This is also restored from backup.

$ printenv | grep "\(SSH\)\|\(GPG\)"
GPG_TTY=/dev/pts/0
SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh
$ tty
/dev/pts/0
$ ls /run/user/1000/gnupg/
S.dirmngr=  S.gpg-agent=  S.gpg-agent.browser=  S.gpg-agent.extra=  S.gpg-agent.ssh=  S.scdaemon=

Finally, journalctl -b includes repeated instances of

yd 05 04:27:23 mycomputer gpg-agent[1663]: scdaemon[1665]: pcsc_establish_context failed: no service (0x8010001d)
Hyd 05 04:27:23 mycomputer gpg-agent[1663]: failed to unprotect the secret key: IPC syntax error
Hyd 05 04:27:23 mycomputer gpg-agent[1663]: failed to read the secret key
Hyd 05 04:27:23 mycomputer gpg-agent[1663]: ssh sign request failed: IPC syntax error <Pinentry>

The scdaemon failure is expected, I think, as I do not have a smart card or a smart card reader or any similar gadget for it to use. So I assume the IPC syntax error is the problem, but I am not sure what this means or where to look for it.

A web search turns up results of limited use. The most promising was https://unix.stackexchange.com/question … nt-and-ssh is about a failure to keep the output of tty in sync with the agent, but that seems not to be my problem here; (The other results were either using deprecated methods or specific to other distros' packaging or both. I was surprised that I got very few results, though.)

Last edited by cfr (2017-10-05 04:07:30)

cfr · 2017-10-05 22:30:13

If I edit .xinitrc to start lwm rather than kde and ssh to the server there, the pinentry box appears and everything works. Rather oddly, the journal says,

Hyd 05 17:08:30 mycomputer systemd[914]: Started GnuPG cryptographic agent and passphrase cache.
Hyd 05 17:08:30 mycomputer gpg-agent[1079]: gpg-agent (GnuPG) 2.2.1 starting in supervised mode.
Hyd 05 17:08:30 mycomputer gpg-agent[1079]: using fd 3 for extra socket (/run/user/1000/gnupg/S.gpg-agent.extra)
Hyd 05 17:08:30 mycomputer gpg-agent[1079]: using fd 4 for ssh socket (/run/user/1000/gnupg/S.gpg-agent.ssh)
Hyd 05 17:08:30 mycomputer gpg-agent[1079]: using fd 5 for std socket (/run/user/1000/gnupg/S.gpg-agent)
Hyd 05 17:08:30 mycomputer gpg-agent[1079]: using fd 6 for browser socket (/run/user/1000/gnupg/S.gpg-agent.browser)
Hyd 05 17:08:30 mycomputer gpg-agent[1079]: listening on: std=5 extra=3 browser=6 ssh=4
Hyd 05 17:08:30 mycomputer gpg-agent[1079]: scdaemon[1081]: pcsc_establish_context failed: no service (0x8010001d)
Hyd 05 17:08:30 mycomputer pinentry-qt[1084]: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files
Hyd 05 17:08:30 mycomputer gpg-agent[1079]: Failed to lookup password for key s/32B6769304DF63C87A1309B954D5B22BBA5A67A9 with secret service: The name org.freedesktop.secrets was not provided by any .service files

I don't know if this just means that the password is not cached, so the pinentry dialog is triggered. However, for whatever reason, it does work.

If I then kill X (gracelessly as I can't figure out how to do it nicely right now), edit .xinitrc to use startkde rather than lwm and startx, I can now ssh to the server using the cached credentials.

Moreover, if I later disconnect from the server, go home, eat dinner, mess around for a bit and wake the laptop from sleep, still in a KDE environment, I can ssh to the server successfully as the pinentry diaglog is now happily triggered in my plasma session.

The environmental variables containing SSH and GPG all seem fine (similar to those shown in the first post). In particular GPG_TTY varies, but always matches the output of tty.

So, the problem is definitely in my Arch config and not my server-side config and everything is somehow setup correctly, except that running startkde somehow causes gpg-agent (I guess) to refuse to spawn the dialogue for pin entry.

Is something special required in the case of a DE? This is the setup I was using on my old machine, with no problems. The main difference is that I was using sddm there and I'm not doing that now because the X server terminates when I use sddm, due to a PAM error related to sddm-helper. (sddm-helper is looking for a PAM module which doesn't exist, for reasons I have not yet managed to ascertain.)

jasonwryan · 2017-10-05 22:32:39

What difference, if any, exists in your environment (printenv) between a KDE session and a basic X one?

cfr · 2017-10-06 16:42:59

jasonwryan wrote:

What difference, if any, exists in your environment (printenv) between a KDE session and a basic X one?

It seems I spoke too soon. I cannot reliably connect from a plain X session either, but get the same errors - sometimes.

However, I discovered that

gpg-connect-agent updatestartuptty /bye

seems to fix the problem in either a KDE setup or an lwm one. So I ran printenv in KDE before doing this, having checked first to ensure that ssh failed as usual. Then I ran the above command, sshed successfully and ran printenv again.

$ diff printenv-kde-before printenv-kde-after
$

Nothing. No difference. Yet ssh successfully triggers pin entry only after the update command and not before.

So now I'm most confused. I thought that the whole point of the update command was to ensure that gpg-agent knew the correct TTY and that this would be equivalent to ensuring that GPG_TTY matched the output of tty. Does it do something else in addition?

seth · 2017-10-06 20:12:32

Seen
https://askubuntu.com/questions/762541/ … -operation
https://stackoverflow.com/questions/442 … -operation
(same, check "ssh-add -l")
https://unix.stackexchange.com/question … -operation
(signature scheme, no idea whether that'S relevant)
?

cfr · 2017-10-06 23:29:27

Thanks, Seth.

seth wrote:

Seen
https://askubuntu.com/questions/762541/ … -operation

I don't think this can be related. At least, I'm failing to see quite how. I'm not using ssh-agent at all, but gpg-agent. Moreover, I've reproduced the problem in an X session running lwm, rather than KDE, The only keyring related package I have installed seems to be archlinux-keyring. I do not have gnome-keyring installed at all.

https://stackoverflow.com/questions/442 … -operation
(same, check "ssh-add -l")

Again, I'm not using ssh-agent, so ssh-add isn't relevant. However, the comment https://stackoverflow.com/questions/442 … 7_44250739 is relevant. Is this a bug which just happens to coincide with my installing on a new machine? Notice that the workaround line given in the comment is the one I gleaned from the manual page and reported earlier. What I don't understand is what it is doing. Because it is not changing any variable in my environment reported by printenv )

https://bugs.debian.org/cgi-bin/bugrepo … bug=835394

This, however, seems to strike gold: a bug in the latest gpg with precisely the symptoms I'm experiencing. BUT those posts are from June. Why am I only running into the bug now? It is too bad that bug report gets side-tracked by unrelated issues to do with deprecated methods of invoking the agent.

I guess the question is whether this is considered a bug upstream and, if so, whether it is systemd or gpg-agent. Or whether I'm supposed to have changed something I'm currently oblivious about.

Does gpg-agent now ignore GPG_TTY? Somehow, it seems to be looking for a match between outdated tty information and the current value. But this seems pernicious. Isn't the whole point of exporting GPG_TTY as $(tty) that it is supposed to keep in sync? Can the agent be made to use the environmental variable? I don't want it working on some tty-I-known-not-which!

https://unix.stackexchange.com/question … -operation
(signature scheme, no idea whether that'S relevant)
?

This isn't relevant as far as I can tell. The agent accepts the keys OK - it is just persuading the agent to let me sign them for sending to the server.

Last edited by cfr (2017-10-06 23:32:55)

cfr · 2017-10-07 00:16:50

I can't work out from the documentation and upstream bug discussions whether this is a bug or expected behaviour. Is it possible that it is just expected that the update command must be used, and that the wiki should be updated to reflect that?

What I'm not clear about still is what is being updated, since it is not an environment variable.

cfr · 2017-10-08 01:19:07

I've just got a display manager working (well, sort of working) and this seems to do something different such that the workaround is not needed and ssh works from the get-go. However, I would really like to understand what is going on here when I don't use a display manager and what exactly is getting corrected by the update command, since it isn't the environment.

yum3 · 2019-06-27 15:18:41

Thank you so much for putting an end to the problem that's been irritating me for more than a year!
I tried to forward gpg-agent so that only my local PC (and not the remote server) has my private key.
It never worked and I was always greeted with "IPC syntax error" when I used agent-socket-extra which is recommended by the gpg-agent manual, so I've been using agent-socket instead of agent-socket-extra.
There were very small number of documents online and sadly they were not helpful, until I saw this. This is the only solution that worked. gpg-connect-agent UPDATESTARTUPTTY /bye completely fixes this problem.
I can't believe the bug is not fixed to this day.

Arch Linux

#1 2017-10-05 04:02:03

ssh sign request failed: IPC syntax error <Pinentry> in KDE

#2 2017-10-05 22:30:13

Re: ssh sign request failed: IPC syntax error <Pinentry> in KDE

#3 2017-10-05 22:32:39

Re: ssh sign request failed: IPC syntax error <Pinentry> in KDE

#4 2017-10-06 16:42:59

Re: ssh sign request failed: IPC syntax error <Pinentry> in KDE

#5 2017-10-06 20:12:32

Re: ssh sign request failed: IPC syntax error <Pinentry> in KDE

#6 2017-10-06 23:29:27

Re: ssh sign request failed: IPC syntax error <Pinentry> in KDE

#7 2017-10-07 00:16:50

Re: ssh sign request failed: IPC syntax error <Pinentry> in KDE

#8 2017-10-08 01:19:07

Re: ssh sign request failed: IPC syntax error <Pinentry> in KDE

#9 2019-06-27 15:18:41

Re: ssh sign request failed: IPC syntax error <Pinentry> in KDE

Board footer