Mailing List Archive

GnuPG and SSH_AUTH_SOCK value
Hello,

I'm using GnuPG together with an OpenPGP card among other things for ssh
access. The SSH_AUTH_SOCK value is to be set like this

# set SSH_AUTH_SOCK
#
unset SSH_AGENT_PID
unset SSH_AUTH_SOCK
SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)";
export SSH_AUTH_SOCK

What I do not understand is, why this value without the KDE5 environment
is

$ gpgconf --list-dirs agent-ssh-socket
/home/guru/.gnupg-ccid/S.gpg-agent.ssh

and after start of Xorg and KDE5 it is:

$ gpgconf --list-dirs agent-ssh-socket
/var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg-agent.ssh

Why is this change/difference?

matthias

--
Matthias Apitz, ? guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: ???????? ????????????! Thank you very much, Russian liberators!
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
On Fri, 21 Jun 2019 11:20, guru@unixarea.de said:

> What I do not understand is, why this value without the KDE5 environment
> is
>
> $ gpgconf --list-dirs agent-ssh-socket
> /home/guru/.gnupg-ccid/S.gpg-agent.ssh

That is because you have a
GNUPGHOME=/home/guru/.gnupg-ccid
and /var/run/users/1001 does not exist.

> and after start of Xorg and KDE5 it is:
>
> $ gpgconf --list-dirs agent-ssh-socket
> /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg-agent.ssh

/var/run/users/1001 has been created (systemd mess?) and thus GnuPG
expects ist sockets below /var/run/user/<UID>. The token is the hash of
the homedir's name so that we don't get a too long path.

$ echo -n /home/guru/.gnupg-ccid | sha1sum | cut -d ' ' -f1 | undump |zb32
m4rfaasqebhjmgto9ddm6m7yfhgj8yc8

undump does the obvious and zb32 is like base64 but encodes using
Zooko's Base32 encoding.


Shalom-Salam,

Werner


ps:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=wk-misc.git;a=blob;f=zb32.c
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=wk-misc.git;a=blob;f=undump.c

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
El día viernes, junio 21, 2019 a las 03:13:45p. m. +0200, Werner Koch via Gnupg-users escribió:

> On Fri, 21 Jun 2019 11:20, guru@unixarea.de said:
>
> > What I do not understand is, why this value without the KDE5 environment
> > is
> >
> > $ gpgconf --list-dirs agent-ssh-socket
> > /home/guru/.gnupg-ccid/S.gpg-agent.ssh
>
> That is because you have a
> GNUPGHOME=/home/guru/.gnupg-ccid
> and /var/run/users/1001 does not exist.
>
> > and after start of Xorg and KDE5 it is:
> >
> > $ gpgconf --list-dirs agent-ssh-socket
> > /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg-agent.ssh
>
> /var/run/users/1001 has been created (systemd mess?) and thus GnuPG
> expects ist sockets below /var/run/user/<UID>. The token is the hash of
> the homedir's name so that we don't get a too long path.

Thanks for the explanation. But why GNUPGHOME is not also used for the
place where the sockets should be created when X11/KDE is up?

matthias
--
Matthias Apitz, ? guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: ???????? ????????????! Thank you very much, Russian liberators!
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
On Fri, 21 Jun 2019 16:39, guru@unixarea.de said:

> Thanks for the explanation. But why GNUPGHOME is not also used for the
> place where the sockets should be created when X11/KDE is up?

That seems to be deep in the innards of KDE's X startup or Wayland or
Systemd configuration. I try to avoid all this and use the old
fashioned but easy to debug ~/.xsession


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
El día sábado, junio 22, 2019 a las 09:47:12a. m. +0200, Werner Koch via Gnupg-users escribió:

> That seems to be deep in the innards of KDE's X startup or Wayland or
> Systemd configuration. I try to avoid all this and use the old
> fashioned but easy to debug ~/.xsession

I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE:

$ cat ~/.xinitrc

# set SSH_AUTH_SOCK
#
unset SSH_AGENT_PID
unset SSH_AUTH_SOCK
SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)";
export SSH_AUTH_SOCK
echo SSH_AUTH_SOCK: $SSH_AUTH_SOCK >> /tmp/xinit
#
setxkbmap de,us -option terminate:ctrl_alt_bksp
xrandr --output default --mode 1366x768
/usr/local/bin/xbindkeys
exec ck-launch-session startkde

The idea is to set env var SSH_AUTH_SOCK correctly for all the xterm/urxvt
processes "below" KDE. But, before the start of KDE (last line) the
SSH_AUTH_SOCK is still
/home/guru/.gnupg-ccid/S.gpg-agent.ssh
and later when KDE is up the 'gpgconf --list-dirs agent-ssh-socket'
returns /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg-agent.ssh
i.e. the env var SSH_AUTH_SOCK is set wrong and I have to reset it
in any terminal.

matthias


--
Matthias Apitz, ? guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: ???????? ????????????! Thank you very much, Russian liberators!
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
Hi.

Am Sonntag, den 23.06.2019, 10:21 +0000 schrieb Matthias Apitz:
> El día sábado, junio 22, 2019 a las 09:47:12a. m. +0200, Werner Koch
> via Gnupg-users escribió:
>
> > That seems to be deep in the innards of KDE's X startup or Wayland
> > or
> > Systemd configuration. I try to avoid all this and use the old
> > fashioned but easy to debug ~/.xsession
>
> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE:
>
> $ cat ~/.xinitrc
>
> # set SSH_AUTH_SOCK
> #
> unset SSH_AGENT_PID
> unset SSH_AUTH_SOCK
> SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)";
> export SSH_AUTH_SOCK
> echo SSH_AUTH_SOCK: $SSH_AUTH_SOCK >> /tmp/xinit
> #
> setxkbmap de,us -option terminate:ctrl_alt_bksp
> xrandr --output default --mode 1366x768
> /usr/local/bin/xbindkeys
> exec ck-launch-session startkde
>
> The idea is to set env var SSH_AUTH_SOCK correctly for all the
> xterm/urxvt
> processes "below" KDE. But, before the start of KDE (last line) the
> SSH_AUTH_SOCK is still
> /home/guru/.gnupg-ccid/S.gpg-agent.ssh
> and later when KDE is up the 'gpgconf --list-dirs agent-ssh-socket'
> returns /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg-
> agent.ssh
> i.e. the env var SSH_AUTH_SOCK is set wrong and I have to reset it
> in any terminal.

I am not running KDE, but Gnome. For my case I have a SystemD user
service which starts a gpg-agent instance in background and sets the
environment variables for the user on login. Originally I found this
solution on the internet and I adapted it for my usecase with a few
modifications.

GPG doesn't start the agent becuse there is already a running instance
and the authentication socket is available. SSH authentication, gpg and
all other things work just fine.

If this is what you want to achieve and if you want to have a look at
this, tell me and I'll send you the needed Files.

Regards,
Dirk

--
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
Hi.

Additionally to my previous reply:

This is my $HOME/.config/systemd/user/gpg-agent.service:
---
[Unit]
Description=GnuPG Agent
IgnoreOnIsolate=true

[Service]
Type=forking
Environment=SSH_AUTH_SOCK=%t/gnupg/S.gpg-agent.ssh
ExecStart=/usr/bin/gpg-agent --homedir %h/.gnupg --enable-ssh-support
--daemon
ExecStartPost=/usr/bin/systemctl --user set-environment
SSH_AUTH_SOCK=${SSH_AUTH_SOCK}

[Install]
WantedBy=default.target
---

There one could add the home directory for GnuPG, if needed.

Regards,
Dirk

--
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
Hi Matthias,

On 23.06.19 12:21, Matthias Apitz wrote:
> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE:

This makes your setup depend on a suid binary.
There have been some security issues about that, so maybe it's wise to revise that decision?
For example: https://www.exploit-db.com/exploits/45908

Bye
Michael
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote:
> On 23.06.19 12:21, Matthias Apitz wrote:
>> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE:
>
> This makes your setup depend on a suid binary.

Can you give more details? I know that some older systems did rely on X
or startx or something being setuid, but i think more modern systems
don't require that. On a debian testing (buster) system, for example, i
don't believe that any of the binaries are suid.

--dkg
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
Hi Daniel,

On 28.06.19 10:23, Daniel Kahn Gillmor wrote:
> On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote:
>> On 23.06.19 12:21, Matthias Apitz wrote:
>>> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE:
>>
>> This makes your setup depend on a suid binary.
>
> Can you give more details? I know that some older systems did rely on X
> or startx or something being setuid, but i think more modern systems
> don't require that. On a debian testing (buster) system, for example, i
> don't believe that any of the binaries are suid.

The setuid binary is called xserver-xorg-legacy and can be installed in
buster (new installs don't get it afaik, but I'm not sure about upgrading):
https://packages.debian.org/de/buster/xserver-xorg-legacy
Matthias explicitly mentioned he used startx so I think this is
relevant.

Bye
Michael
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
On Fri 2019-06-28 11:09:36 +0200, Michael Kesper wrote:
> On 28.06.19 10:23, Daniel Kahn Gillmor wrote:
>> On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote:
>>> On 23.06.19 12:21, Matthias Apitz wrote:
>>>> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE:
>>>
>>> This makes your setup depend on a suid binary.
>>
>> Can you give more details? I know that some older systems did rely on X
>> or startx or something being setuid, but i think more modern systems
>> don't require that. On a debian testing (buster) system, for example, i
>> don't believe that any of the binaries are suid.
>
> The setuid binary is called xserver-xorg-legacy and can be installed in
> buster (new installs don't get it afaik, but I'm not sure about upgrading):
> https://packages.debian.org/de/buster/xserver-xorg-legacy
> Matthias explicitly mentioned he used startx so I think this is
> relevant.

I also use startx on buster systems, but i don't have
xserver-xorg-legacy installed, so i think this is not the strict
dependency it sounded like originally. I know that i used to depend on
a setuid X server, so i'm gratefuly to the folks who did the work to
remove that setuid requirement!

Anyway, i think we're pretty far off-topic here, so i'll drop off this
thread, just wanted to confirm that i hadn't missed something.

all the best,

--dkg
Re: GnuPG and SSH_AUTH_SOCK value [ In reply to ]
Daniel Kahn Gillmor via Gnupg-users wrote in <87ftnup18e.fsf@fifthhorsem\
an.net>:
|On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote:
|> On 23.06.19 12:21, Matthias Apitz wrote:
|>> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE:
|>
|> This makes your setup depend on a suid binary.
|
|Can you give more details? I know that some older systems did rely on X
|or startx or something being setuid, but i think more modern systems
|don't require that. On a debian testing (buster) system, for example, i
|don't believe that any of the binaries are suid.

..because some packagers do CRUX to avoid it, maybe because they
do not want to violate some policy.
For example, for the MUA i maintain, Debian ships with the
privilege-separated "dotlock" helper, but does not install it
SETUID. This is good enough for the shared mail directory the way
Debian does it, in fact the package maintainer is pretty clever,
right, but of course this is not how it is designed; today: it was
a SETGID helper in the past, but that does not work on eg. OpenBSD
where only root can write in the mail spool. And since this MUA
supports multiple mail spools, it will not work unless they are
setup in exactly the same way. But only normal file-locking, as
is the chosen approach on OpenBSD (for my MUA), is not the way the
Debian maintainer wants to go. Well, this is his choice.

(Besides i am in total favour of not having SETUID, not only
because i had a CVE myself. Here Xorg still is SETUID, but i have
never looked too deep. For graphics hardware access, you need to
have access to hardware, no. Ie., whether hardware is designed so
that this becomes possible, i do not know. Being able to start
a program SETUID, open some files, and then enter a restricted
mode which has lost root rights, i do not feel bad about. Like
the FreeBSD capsicum thing, or even CloudABI. Maybe i even prefer
being able to search SETUID and have a list, instead of having
very complicated configuration settings, and CRUX, hidden here and
there. But i am not a security researcher, i just try to do
a little thing right.)

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

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