Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[André Colomb]

On 2018-01-22 18:06, André Colomb wrote:
>> the systemd user service takes care of automatically launching the
>> gpg-agent when the user connects to it via the ssh-agent protocol, so
>> this isn't required when using systemd.
> 
> I can't see how it does that in my packaged Ubuntu version (2.1.15),
> there is no gpg-agent.socket unit file anywhere?

Seems like the relevant systemd unit file examples were added in commit
57e95f5413e21cfcb957af2346b292686a5647b7, shortly after 2.1.15 (included
in Debian / Ubuntu) was released.

As far as I can see, the new socket-activated user units should be
installed with current packages in Debian testing and Ubuntu bionic.  I
might try manually upgrading to 2.2.4-1ubuntu1 and report any findings.

Regards
André
-- 
Greetings...
From: André Colomb 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[Doron Behar]

I'm glad to hear your comments guys. I've posted a bug report on ssh'
bug tracker: https://bugzilla.mindrot.org/show_bug.cgi?id=2824

On Mon, Jan 22, 2018 at 08:43:41AM +0100, Werner Koch wrote:
> On Sun, 21 Jan 2018 17:41, doron.be...@gmail.com said:
> 
> > As far as I understand, because I use `systemd`'s user service, whenever
> > I want to unlock an authentication key I need to run the command
> > `gpg-connect-agent updatestartuptty /bye`.
> 
> Although I have no experience with the peculiarities of the --supervised
> mode, there is no need to run the updatestartuptty command.  That command
> is only used to switch gpg-agent's default $DISPLAY and tty to the one
> active in the shell you run this command.  This is required because the
> ssh-agent protocol has no way to tell gpg-agent (or ssh-agent) the
> DISPLAY/tty which shall be used to pop-up the Pinentry.
> 
> Another problem with ssh is that ssh can't start gpg-agent on the the
> fly.  Thus you need to make sure that gpg-agent has already been started
> when you use ssh.  A way to ensure this is to run 
> 
>   gpg -K
> 
> which lists all your private keys and as a side-effects starts
> gpg-agent.  You can also do
> 
>   gpg-connect-agent /bye
> 
> because it exhibits the same side-effect.  The suggested way to start
> gpg-agent for ssh is to use
> 
>   gpgconf --launch gpg-agent
> 
> 
> Salam-Shalom,
> 
>Werner
> 
> 
> p.s.
> And the best solution would be to extended the ssh-agent protocol
> and openssh to allow starting of an arbitrary process and conveying some
> environment variables.
> 
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[André Colomb]

Hello Daniel,

I'm on Ubuntu 17.10 with GnuPG 2.1.15, by the way.

Daniel Kahn Gillmor  wrote on 2018-01-22 12:53
(UTC+0100)
> It may also depend on how the session itself is started.  Maybe one of
> you is starting the user session in non-graphical mode (either a vt
> login, or maybe ssh?), while the other one is starting it directly from
> a graphical display manager?

The session is started by GDM3, using the vanilla gnome-session scripts
(not the adapted ubuntu-session, also based on GNOME 3).  The systemd
user unit file is copied from /usr/lib/systemd/user/gpg-agent.service
and the Upstart-specific "initctl" command line commented out.

The main difference I see here is that I have enabled the user unit by
symlinking from ~/.config/systemd/user/default.target.wants/, whereas
the Ubuntu package includes the symlink in
/usr/lib/systemd/user/graphical-session-pre.target.wants/.

acolomb@barnov:~$ systemctl --user status gpg-agent.service
   Loaded: loaded (/home/acolomb/.config/systemd/user/gpg-agent.service;
enabled; vendor preset: enabled)

> do you have dbus-user-session installed?  (it is recommended)

Yes.

(from your other message:)
> the systemd user service takes care of automatically launching the
> gpg-agent when the user connects to it via the ssh-agent protocol, so
> this isn't required when using systemd.

I can't see how it does that in my packaged Ubuntu version (2.1.15),
there is no gpg-agent.socket unit file anywhere?

Any other ideas on how to debug this?  What logging should I enable for
gpg-agent and how?

Btw. it affects both my Yubikey as well as file-based authentication
subkeys, so not specific to scdaemon apparently.

Regards
André
-- 
Greetings...
From: André Colomb 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[Daniel Kahn Gillmor]

On Mon 2018-01-22 11:52:21 +0100, Peter Lebbing wrote:
> It works for me out-of-the-box on Debian stretch/stable, supervised by
> systemd... if I SSH before I do any GnuPG stuff, it correctly prompts me
> in the (graphical) session that started the agent. So something must be
> different in your installation.

It may also depend on how the session itself is started.  Maybe one of
you is starting the user session in non-graphical mode (either a vt
login, or maybe ssh?), while the other one is starting it directly from
a graphical display manager?

do you have dbus-user-session installed?  (it is recommended)

   --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[Daniel Kahn Gillmor]

On Mon 2018-01-22 08:43:41 +0100, Werner Koch wrote:
> Another problem with ssh is that ssh can't start gpg-agent on the the
> fly.  Thus you need to make sure that gpg-agent has already been started
> when you use ssh.  A way to ensure this is to run 
>
>   gpg -K

the systemd user service takes care of automatically launching the
gpg-agent when the user connects to it via the ssh-agent protocol, so
this isn't required when using systemd.

 --dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[Peter Lebbing]

On 22/01/18 09:36, André Colomb wrote:
> Strange thing is, I could use the GPG part of gpg-agent already before
> issuing that command.  Why does that behave differently?

Because GnuPG *does* pass TTY and display to the agent.

> Can something be done to the systemd user unit file so the process gets
> told the correct $DISPLAY at least?

It works for me out-of-the-box on Debian stretch/stable, supervised by
systemd... if I SSH before I do any GnuPG stuff, it correctly prompts me
in the (graphical) session that started the agent. So something must be
different in your installation.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[André Colomb]

On 2018-01-22 08:43, Werner Koch wrote:
>> As far as I understand, because I use `systemd`'s user service, whenever
>> I want to unlock an authentication key I need to run the command
>> `gpg-connect-agent updatestartuptty /bye`.
> 
> Although I have no experience with the peculiarities of the --supervised
> mode, there is no need to run the updatestartuptty command.  That command
> is only used to switch gpg-agent's default $DISPLAY and tty to the one
> active in the shell you run this command.  This is required because the
> ssh-agent protocol has no way to tell gpg-agent (or ssh-agent) the
> DISPLAY/tty which shall be used to pop-up the Pinentry.

I can confirm that it actually IS necessary to send "updatestartuptty"
for ssh-agent functionality to work in this scenario.  The gpg-agent
process started by systemd's user session has no $DISPLAY and no
$GPG_TTY set (looking at /proc/###/environ).  Its cmdline does not
contain --supervised either.

I always wondered why I got the message "agent refused operation" when
using an SSH key from gpg-agent.  Restarting gpg-agent manually after
logging in was my workaround thus far, but today I found out that
updatestartuptty suffices.

Strange thing is, I could use the GPG part of gpg-agent already before
issuing that command.  Why does that behave differently?

Can something be done to the systemd user unit file so the process gets
told the correct $DISPLAY at least?

Kind regards
André

-- 
Greetings...
From: André Colomb 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[Werner Koch]

On Sun, 21 Jan 2018 17:41, doron.be...@gmail.com said:

> As far as I understand, because I use `systemd`'s user service, whenever
> I want to unlock an authentication key I need to run the command
> `gpg-connect-agent updatestartuptty /bye`.

Although I have no experience with the peculiarities of the --supervised
mode, there is no need to run the updatestartuptty command.  That command
is only used to switch gpg-agent's default $DISPLAY and tty to the one
active in the shell you run this command.  This is required because the
ssh-agent protocol has no way to tell gpg-agent (or ssh-agent) the
DISPLAY/tty which shall be used to pop-up the Pinentry.

Another problem with ssh is that ssh can't start gpg-agent on the the
fly.  Thus you need to make sure that gpg-agent has already been started
when you use ssh.  A way to ensure this is to run 

  gpg -K

which lists all your private keys and as a side-effects starts
gpg-agent.  You can also do

  gpg-connect-agent /bye

because it exhibits the same side-effect.  The suggested way to start
gpg-agent for ssh is to use

  gpgconf --launch gpg-agent


Salam-Shalom,

   Werner


p.s.
And the best solution would be to extended the ssh-agent protocol
and openssh to allow starting of an arbitrary process and conveying some
environment variables.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp4HSm2LlCqy.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Why exactly does pinentry fails with gpg-agent and ssh support?

[Doron Behar]

Hello everyone,

I've recently encountered the problem explained in item #3 here:
https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html
and I would like to discuss it.

I use the `systemd` user service provided with Arch Linux and it's
`ExecStart` is:

/usr/bin/gpg-agent --supervised

I followed the recommended instructions on the official website and on
the Arch Linux's wiki
(https://wiki.archlinux.org/index.php/GnuPG#SSH_agent)

I also read the following bugs / threads:

https://unix.stackexchange.com/questions/217737/pinentry-fails-with-gpg-agent-and-ssh
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851440
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854376

As far as I understand, because I use `systemd`'s user service, whenever
I want to unlock an authentication key I need to run the command
`gpg-connect-agent updatestartuptty /bye`.

## My question is this:

The official documentation says:

> SSH has no way to tell the gpg-agent what terminal or X display it is
> running on. So when remotely logging into a box where a gpg-agent with
> SSH support is running, the pinentry will get popped up on whatever
> display the gpg-agent has been started.

Perhaps it would be possible to create some kind of feature request /
patch / merge request for ssh and enabling users to run this command
before connecting to an ssh server?

BTW I encountered a stackoverflow question on the subject that raises
the same problem:
https://stackoverflow.com/questions/32574142/can-i-set-up-a-before-hook-on-certain-ssh-hosts

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users