[pkg-gnupg-maint] Bug#934237: Bug#934237: yubikey communication fails on startup

Antoine Beaupré anarcat at debian.org
Fri Aug 9 03:35:14 BST 2019


On 2019-08-09 09:08:35, NIIBE Yutaka wrote:
> Antoine Beaupre <anarcat at debian.org> wrote:
>> When I login in the morning, my Yubikey setup fails to let me connect
>> to remove SSH servers:
>
> How do you invoke gpg-agent?  If it is through your first SSH
> invocation, gpg-agent wouldn't know the place where to ask PIN (TTY and
> DISPLAY).

I don't directly invoke it. It might be through the first SSH connexion,
or earlier (see below). But it's running under `systemd --user`.

> You can check if you can use your tokan with SSH after your first
> invocation of:
>
> 	$ gpg --card-status
>
> or
>
>         $ gpg-connect-agent UPDATESTARTUPTTY /bye
>
> Then, that's the case.

`gpg --card-status` works, as I said.

> gpg-agent should know the place where to ask PIN (TTY and DISPLAY), and
> it is told by gpg frontend or gpg-connct-agent.  But in the case of SSH
> (external/foreign program), there is no such mechanism telling the
> place.

Oh god, that TTY thing. I have this in my .bashrc because of problems
with GPG on that front:

# see http://bugs.debian.org/719908
export GPG_TTY=$(tty)

I have no idea what it does or why it matters. It might be related.

It wouldn't explain why this suddenly started failing.

You know what, now that I think of it, one thing that changed recently
in my startup sequence, and that might affect this, is this:

|  .config/systemd/user/{multi-user.target.wants => default.target.wants}/smd-pull.service    | 0

This is me switching my "systemd --user"-level services from
`multi-user.target` (which does nothing) to `default.target` (which does
start services on session start.

This peculiar service is something that connects over SSH to fetch my
mail. It *might* try to talk to the Yubikey and fire up GPG agent (maybe
even before Xorg comes up, and definitely before the Yubikey is
entered).

This might be the actual trigger for this problem I'll test this (and an
older version of GPG) to see if I can backtrack the issue.

>> aoû 08 09:51:37 curie gpg-agent[3298]: smartcard signing failed: Ioctl() inapproprié pour un périphérique 
>> aoû 08 09:51:37 curie gpg-agent[3298]: ssh sign request failed: Ioctl() inapproprié pour un périphérique <Pinentry> 
>
> If it is "Inappropriate ioctl for device", it means that pinentry failed
> because of no place to ask.

Thanks! That's very useful information, although I can't help but think
that a better error message would be useful here.. ;)

>> Once gpg-agent is restarted, the Yubikey works fine again. And that
>> is, even if it's unplugged and plugged back in again.
>
> For me, it sounds like... it is your first invocation of SSH (by systemd
> watching the socket), which invokes gpg-agent.

For what it's worth, gpg-agent runs as "supervised" here, i.e. it seems
to be under the control of `systemd --user`. Not sure what that means,
but when it's running, it's running under systemd and I can restart it
with `systemctl --user restart gpg-agent`.

But thanks for all the great information, I have a lot of things to move
forward with now!

A.

-- 
Uncompromising war resistance and refusal to do military service under
any circumstances.
                       - Albert Einstein



More information about the pkg-gnupg-maint mailing list