You are not logged in.

#1 2017-05-30 09:10:06

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 4,681
Website

[WORKAROUND] ssh forwarded gpg-agent: pinentry ignores keyboard

I'm running out of ideas here.

GOAL: to be able to sign files on a remote server with gpg, while keeping the secret signing key on my local computer only and using gpg-agent, forwarded to the remote machine, to do the signing.

(Google 'forward gpg-agent' to get the general idea, but gpg has changed recently so focus on 2016/2017 posts.)

SO FAR: It seems to be almost there. Forwarding of gpg-agent via SSH gives every impression of working: I can do things like 'gpg --list-secret-keys' and after a second or two up it comes. (The remote machine has the public key only, and that gpg command returns nothing if logging-in on a normal ssh connection with no socket forwarding.)

WHAT'S WRONG: In a remote login, when a gpg passhrase is needed (ie the first time the secret key is used in that session) a pinentry comes up OK - either pinentry-curses or pinentry-tty, depending on what's configured in the local machine's ~/.gnupg/gpg-agent.conf. The problem is that keyboard input is ignored, whichever pinentry is used. Pinentry works fine on the local machine.

Local system is a cli Debian Stretch in an encrypted VirtualBox.
Remote is a cli Debian Stretch in a container.

All other functions seem OK in both systems.

Any ideas, suggestions of places to look, places to ask... gratefully received. I'll post any config files, terminal output etc requested.

(I've just spent the last 3~4 days googling this stuff, and getting a bit tired.)

Last edited by johnraff (2017-06-05 06:54:37)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

#2 2017-05-30 15:49:44

unklar
Member
Registered: 2015-10-31
Posts: 741

Re: [WORKAROUND] ssh forwarded gpg-agent: pinentry ignores keyboard

John

I do not know what is wrong.


Have you

ssh -v ......

tried? "Verbose"
Sadly only in German...

Offline

#3 2017-05-30 17:57:09

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: [WORKAROUND] ssh forwarded gpg-agent: pinentry ignores keyboard

I don't have any experience with SSH so I may not be of much help here but can we see the journal contents for a failed attempt?


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#4 2017-06-02 03:42:41

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 4,681
Website

Re: [WORKAROUND] ssh forwarded gpg-agent: pinentry ignores keyboard

Thanks both.

@unklar: That's a nice intro to ssh, quite comprehensible when run through google translate.

In fact I was thinking the problem was with gpg, but I'll certainly look again with ssh, and all the other executables involved like gpg-agent, set to "verbose" and see if any hints come up.

@HoaS which machine's journal should I post? Local (VB guest) or remote? (Or both?)

A couple of possibilities I might check out:

*) VirtualBox issue? To test I'd have to set up an alternative like systemd-nspawn for the local system. (Both local and remote have to be Debian Stretch, in order to get gnupg 2.1 which supports gpg-agent forwarding via an "extra socket" with limited privileges.)

*) Systemd? gpg-agent is managed by systemd in "supervised" mode, which might affect its behaviour. To test, I'd have to disable systemd's socket for gpg-agent (not too hard) and fall back on the previous start-up methods. I had thought that systemd might be an improvement in this case, but not if it's buggy of course. icon_rolleyes.gif

How I tested:
Get a gpg-agent extra socket forwarded back from the remote machine to local, so remote can invoke the local's gpg-agent without needing secret keys in remote's gpg. Test:

echo 'test' | gpg -as

On my host machine (Jessie):
A pinentry-gtk window opens to get my signing key passphrase, and a signature is sent to stdout. OK

On the "local" machine (Stretch cli on VB):
Pinentry-curses or pinentry-cli (whichever is configured in ~/.gnupg/gpg-agent.conf) comes up and gets the passphrase. OK

On the "remote" machine (Stretch cli in container on server):
Pinentry-curses or pinentry-cli (whichever is configured in the local machine's ~/.gnupg/gpg-agent.conf) comes up and asks for the passphrase but accepts no keyboard input, as if STDIN was disconnected. Pinentry times out and the signing fails.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

#5 2017-06-02 06:57:14

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: [WORKAROUND] ssh forwarded gpg-agent: pinentry ignores keyboard

johnraff wrote:

@HoaS which machine's journal should I post? Local (VB guest) or remote? (Or both?)

I think the useful stuff will be on the remote but we should probably see both.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#6 2017-06-02 09:40:25

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 4,681
Website

Re: [WORKAROUND] ssh forwarded gpg-agent: pinentry ignores keyboard

I'll work on journals, but it'll presumably need enabling.

I've already exported GPG_TTY=$(tty) on the local machine, and
'echo UPDATESTARTUPTTY | gpg-connect-agent' (see here) was necessary to get a remote pinentry at all.

One small step: https://www.isi.edu/~calvin/gpgagent.htm towards the bottom says:

if using pinentry-curses (no GUI), you will not be prompted for your passphrase and will need to "pre-seed" it with gpg-preset-passphrase or the following:

gpg2 --output /dev/null --sign -u 0xKEY_ID /dev/null

But instead I tried running 'echo 'test' | gpg -as' on the local machine before making the ssh connection. This preloaded the passphrase, making the remote pinentry unnecessary, and the signing worked. Hmm...


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

#7 2017-06-02 21:00:35

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: [WORKAROUND] ssh forwarded gpg-agent: pinentry ignores keyboard

johnraff wrote:

it'll presumably need enabling

No, the only enabling that needs to be done is for persistent logging and that should only be needed after an unrecoverable crash.

You can attempt the connection now then use

journalctl -xe

immediately afterwards.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#8 2017-06-05 06:54:09

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 4,681
Website

Re: [WORKAROUND] ssh forwarded gpg-agent: pinentry ignores keyboard

I had to add the remote user to 'systemd-journal', but the result didn't look too useful after all. After ssh login and failed attempt to use pinentry, (sanitized):

Jun 05 06:37:06 hostname sshd[10179]: Accepted publickey for username from xxx.xxx.xx.xx port xxxxx ssh2: RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Jun 05 06:37:06 hostname sshd[10179]: pam_unix(sshd:session): session opened for user username by (uid=0)
Jun 05 06:37:06 hostname systemd-logind[62]: Existing logind session ID 2 used by new audit session, ignoring
Jun 05 06:37:06 hostname systemd[1]: Started Session c67 of user username.
-- Subject: Unit session-c67.scope has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit session-c67.scope has finished starting up.
-- 
-- The start-up result is done.
Jun 05 06:37:06 hostname systemd-logind[62]: New session c67 of user username.
-- Subject: A new session c67 has been created for user username
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat
-- 
-- A new session with the ID c67 has been created for the user username.
-- 
-- The leading process of the session is 10179.

It just seems to document the session start, with no error messages.

--------------------------

But... I'm starting to think the workaround posted in the above blog would be acceptable in this case. Running a "dummy" gpg signing command (that calls for the signing key passphrase) on the local system before making the ssh connection means that gpg-agent has the key available for signing remote files too, with no further need for pinentry to get the passphrase. Since all the commands will be in a script, the work flow will be identical: Enter passphrase once, everything else runs - regardless of whether the passphrase was entered before or after making the connection.

It would be nice to fix the remote-triggered pinentry, but at least one other person was unable to get pinentry-curses working (pinentry-gtk in an X session seems to be OK though), and I'm eager to move on, so I'll go with that workaround for now.

Thanks unklar and HoaS for your encouragement anyway.

To people who find this later:
The "fix" is to run a dummy gpg command in the local machine, so gpg-agent has the key. The remote system can then use the signing key via the gpg-agent "extra" socket without needing pinentry. Example:

gpg --output /dev/null --sign --local-user 0x12345678 /dev/null

John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

Board footer

Powered by FluxBB