initializing gnome-keyring-daemon in autostart

johnraff · 2016-02-05 04:35:58

xaos52 wrote:

I am now experimenting with moving the gnome-keyring-daemon --start thing to $HOME/.config/openbox/environment and first results are promising.
This seems to do the trick:
## GNOME Keyring
# WARNING: interpreter is dash!
while read -r _line
do
    _var=${_line%=*}
    _value=${_line#*=}
    eval if [ -z \$"$_var" ]\; then export "$_var"="$_value"\; fi
done <<EOF
$(gnome-keyring-daemon --start --components=pkcs11,secrets,ssh,gpg)
EOF
unset _line _var _value
Had to resort to
1. using eval.
It is safe here because only using output from gnome-keyring-daemon.
2. Here-doc because the exports can not be done in a subshell. That would prevent the variables to be set in the openbox environment.

Sorry to be dense, but I don't understand the need to do all this processing. Why not just feed the output of the gnome-keyring command directly to export?

I tested it in a shell (not bash) terminal, with a test function that spits out two variable assignments, on two lines.
First terminal:

john@raffles4:~$ sh
$ f() { echo "one=first
> two=second"; }
$ f
one=first
two=second
$ urxvt # variables have not been set in new terminal
$ export $(f)
$ urxvt

and in the urxvt window which opened:

john@raffles4:~$ echo $one
first
john@raffles4:~$ echo $two
second

...this was not in a vm btw.

xaos52 · 2016-02-05 09:55:53

Sorry to be dense, but I don't understand the need to do all this processing. Why not just feed the output of the gnome-keyring command directly to export?

If we set the variables spit out by gnome-keyring-daemon unconditionally, they will override the settings of ssh-agent and/or gnupg-agent and we will effectively be thrown back to the functionality offered by gnome-keyring in stead of the (more extensive) functionality offered by ssh-agent and/or gnupg-agent.

So, I don't do it unconditionally.
For each of the environment variables that is spit out by gkd, I first test if it was not set already, and only then do I export that variable.
Now if you can do that with less coding than I offered, I will be glad to buy you a pint.

Have you tried it?
Make sure you have ssh-agent enabled (in /etc/X11/Xsession.options), then feed the output of the gnome-keyring command directly to export.

The result is that SSH_AUTH_SOCK=/run/user/1000/keyring/ssh, the socket to communicate with gnome-keyring!

I just did that test to be absolutely sure, without any doubt whatsoever that what I am saying is true.

me@medion:~$ env| grep -iE 'ssh|gpg'
SSH_AGENT_PID=1478
GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

There you have it.
Both GPG and SSH agent functionality will be provided by keyring, though I have gpg-agent and gnupg-agent enabled.

Now for the case where my suggested code is used in openbox/environment, and ssh-agent and gnupg-agent are enabled, the result is

me@medion:~$ env|grep -iE 'ssh|gpg'
SSH_AGENT_PID=2449
GPG_AGENT_INFO=/tmp/gpg-ez10gl/S.gpg-agent:2450:1
SSH_AUTH_SOCK=/tmp/ssh-09GCH3EOMcBj/agent.2421

Correct sockets to talk to ssh-agent and gnupg-agent.

Perhaps the most important point to note here, and it has not been mentioned earlier in this thread, is the order in which the processes are started when bringing up the graphical environment.

Leaving out the details, it is:

lightdm
lightdm --session-child
gpg-agent
ssh-agent
openbox/environment
openbox itself
openbox/autostart

When entering openbox/environment ssh-agent and gpg-agent are running already and have already exported their environment variables. We should not overwrite them with the values that gkd (gnome-keyring-daemon) spits out.

johnraff · 2016-02-06 04:50:55

Actually, my proposal way back in post 10 was

johnraff wrote:

So I think if we're going to keep gnome-keyring, the way to initialize it in openbox/autostart might be:
export $(gnome-keyring-daemon --start --components=pkcs11,secrets)
Note the lack of a final ampersand, and use of export instead of eval.

Now it's become clear that if we want to export any variables then the place would have to be openbox/environment, but since I'm advocating not initializing ssh or gpg in gnome-keyring, then in fact nothing is output by the command, and the export becomes redundant. Reasons for omitting ssh and gpg here, which you agreed to in the next post.

So, I can see two options for the default BL setup:

In openbox/autostart

gnome-keyring-daemon --start --components=pkcs11,secrets

In openbox/environment

export $(gnome-keyring-daemon --start --components=pkcs11,secrets)

(The second option retains export just in case some enviroment variable for pkcs11 or secrets might be output in the future.)

1) Has the advantage of keeping the command in autostart along with everything else, easy for users to find.
2) Has the advantage that if a user wanted to activate gnome-keyring support for ssh or gpg they wouldn't need to move the command to another file, and add the exporting code.

I'm not necessarily convinced that in the case of starting gnome-keyring with (e.g.) ssh, but not disabling ssh-agent, then not exporting g-k's variable is all that would need to be done in order for it not to interfere with ssh-agent's (or gpg-agent's) work. Will they be happy with both running simultaneously?

That is, I think that if a user wanted to enable ssh or gpg in gnome-keyring they should also make sure that ssh-agent and/or gpg-agent were not being started. That would make the test for an environment variable from either of them unnecessary.

Last edited by johnraff (2016-02-06 05:14:00)

xaos52 · 2016-02-06 16:37:35

I did agree then and there, considering what I knew about the subject then.

We have three applications providing more or less the same functionality - and yes, it is the environment variables being set that determine which one is used.

Bunsenlabs as a distro can make its own choice of course, and your choice, John, is an acceptable one, but being linux we should allow our users to make their own choice by documenting what the possibilities are and what needs to be changed to the default setup to honour that choice.

I suggest we take a time-out on this for the moment.

I for one am going to explore all possibilities further and come up with a list of viable alternatives from which to choose.

johnraff · 2016-02-07 01:49:32

xaos52 wrote:

...being linux we should allow our users to make their own choice by documenting what the possibilities are and what needs to be changed to the default setup to honour that choice.

I agree completely with this.

I for one am going to explore all possibilities further and come up with a list of viable alternatives from which to choose.

Thank you for this help!

Meanwhile, the current entry in openbox/autostart, provided by bunsen-configs is

eval $(gnome-keyring-daemon -s --components=pkcs11,secrets,ssh,gpg) &

which is clearly not going to work.
I suggest that the next upgrade of bunsen-configs contain this, in openbox/environment:

export $(gnome-keyring-daemon --start --components=pkcs11,secrets)

The export is redundant, but future modifications will be a bit simpler for users because the code is in the right file and the need to export variables is indicated.

This will probably be too late for the RC2 release (unless that is delayed for other reasons) but should be in time for the Main Release.

( The problem with upgrades to files in skel is that changes in $HOME need to be made voluntarily by existing users (quite rightly), although newly created users will get the new code right off. This means we have to get the settings in skel as solid as possible before releasing an .iso. )

Anyway, does the above code look like a reasonable compromise for now?

Meanwhile, agreed, let's think about it some more.

Last edited by johnraff (2016-02-07 02:09:23)

johnraff · 2016-02-07 07:03:09

[a bit off-topic]
From the country with the best beer in the world, an irresistable challenge!

xaos52 wrote:

For each of the environment variables that is spit out by gkd, I first test if it was not set already, and only then do I export that variable.
Now if you can do that with less coding than I offered, I will be glad to buy you a pint.

But I was only able to make a tiny reduction in the code, at the expense of unnecessarily re-exporting variables that are already set.

## GNOME Keyring
# WARNING: interpreter is dash!
while read -r _line
do
    _var=${_line%=*}
    _value=${_line#*=}
    eval export \${$_var:=$_value}
done <<EOF
$(gnome-keyring-daemon --start --components=pkcs11,secrets,ssh,gpg)
EOF
unset _line _var _value

A half-pint?

xaos52 · 2016-02-07 09:46:57

^^ agreed (for now)

We should provide advice to the user on how to disable gnome-keyring-daemon altogether, without removing the package. Remember I was removing the package to do just that, as did Sector11 IIRC.
But hopefully now that they can store web page passwords, it will get more use
.
gnome-keyring-daemon now gets started at login by PAM services. This would probably be the best place to modify for NOT starting it.

^ The whole purpose of the exercise was to NOT overwrite environment variables already set.
You don't get half a pint for that.
And I don't want people to think I am the kind of person to deal out HALF pints.

xaos52 · 2016-02-07 17:10:52

Please ignore this post completely.
It was written by my alter ego after a copious dinner with too much wine.
You don't check if a variable is set by checking the environment.

WARNING!
Run this script

#!/bin/sh
unset SSH_AUTH_SOCK GPG_AGENT_INFO
eval $(gnome-keyring-daemon)
env|grep -iE 'ssh|gpg'

and you can see that eval does not work here! The environment variables are not set!

Replace 'eval' by 'export' and it does work!

Could be this is a bug in gnome-keyring! Or perhaps gnome-keyring never advocated the use of 'eval', only 'export'?

It looks like gnome-keyring mimics the ssh-agent behaviour here, but ssh-agent spits out these variables:

SSH_AUTH_SOCK=/tmp/ssh-01gU1DW9YJpT/agent.1739; export SSH_AUTH_SOCK;
SSH_AGENT_PID=1740; export SSH_AGENT_PID;
echo Agent pid 1740;

(notice the export commands!) which eval can handle,

while gnome-keyring-daemon spits out

me@medion:~/tmp/today/quicktests$ gnome-keyring-daemon
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1

The 'export' command can handle this, but apparently the 'eval' command can not.

Conclusion:
Seems like the eval command we used in the past to start gnome-keyring-daemon either never worked or at some time in development of gnome-keyring stopped working.

johnraff · 2016-02-08 02:58:38

xaos52 wrote:

We should provide advice to the user on how to disable gnome-keyring-daemon altogether, without removing the package...
...gnome-keyring-daemon now gets started at login by PAM services. This would probably be the best place to modify for NOT starting it.

Modifying system files like /etc/pam.d/lightdm and /etc/pam.d/common-password would disable gnome-keyring for all users, in which case we might as well not install it. Would it not be enough simply to allow the first stage of the daemon startup to take place as normal, but not perform the necessary second stage, which is our line in openbox/environment?

If you google "disable gnome-keyring" you'll find the vast majority of cases is of people who want to disable ssh support, which we have already done. People who want it back can add ssh to the --components option, and ssh-agent's enviroment variable (if it exists) will be overwritten by gnome-keyring's.

^ The whole purpose of the exercise was to NOT overwrite environment variables already set.
You don't get half a pint for that.

But... but... if the variable is already set, then that construction does not change its value. The export is just re-flagging the variable as exported - redundant, but harmless, no? But never mind...

xaos52 · 2016-02-08 17:42:14

Seems like Ubuntu has struggled a bit with the same problem.
See this thread

Usage of upstart does trouble the waters a bit (I have no experience with it at all).

If I understand correctly their default setup is for gnome-keyring to handle all components (for 'simple' users). More advanced users are supposed to tick a box to start ssh and/or gnupg, which then overrides the 'simple' setup.

The default bl setup that you chose does the inverse. It favours the 'advanced' user setup for ssh (and gpg when the user chooses to install it), which covers all scenarios except that of a simple user disabling ssh-agent usage (by editing /etc/X11/Xsession.options) to find out that he then has to edit openbox/environment as well to start the ssh component of gnome-keyring to be able to cache his ssh key. But I suppose a user that does this can not be qualified as being 'simple'.

tknomanzr · 2016-02-08 23:53:29

I am a bit lost with this thread. However, I wanted to chime in here and point out that I just setup ssh-agent for github the other day. I can say 1.) I have not messed with the degault gnome-keyring settings as of yet and 2.) ssh-agent is definitely running and I had no issued getting ssh to work with github via it. I don't know if that helps any or if I am missing something obvous that prompted this discussion.

However, setting up ssh-agent showed me the way around having to use ssh-pass with plain text passwords in some of my ssh scripts.

johnraff · 2016-02-09 04:59:10

This thread was a bit messy at first, but actually I don't think we have any major problems here now.

The CrunchBang Waldorf start-up command for gnome-keyring in ~/.config/openbox/autostart was broken for us, possibly even for Waldorf, but it's fixed in the lastest bunsen-configs, so should make it to RC2.

@xaos52 that Ubuntu problem was with upstart AFAIKS. With our manual startup (we don't even reference the files in /etc/xdg/autostart) it's very simple for us - and users - to start gnome-keyring with whatever components we want.

One question: is there any problem if ssh-agent is started but its SSH_AUTH_SOCK setting subsequently overwritten by a gnome-keyring which has been started with ssh enabled? (ie both running but the envvar pointing to gnome-keyring.) If there's no problem, then all a user who wanted to use gnome-keyring for ssh instead of ssh-agent would have to do, is add ssh to the --components in the startup command in openbox/environment. Disabling ssh-agent in /etc/X11/Xsession.options would be optional? (And would also be a system-wide change, enforced on all users.)

@tk what does 'echo $SSH_AUTH_SOCK' output? That would tell us if it's coming from ssh-agent or gnome-keyring. I suspect the former, though, because of those issues with the previous g-k startup command we were using.

NOTE In contrast with ssh-agent, gpg-agent is not running by default, although it is installed in BL. There is little documentation but /etc/X11/Xsession.d/90gpg-agent implies that adding use-agent to ~/.gnupg/gpg.conf will start it. I've tried that, and sure enough got

john@bunsen:~$ echo $GPG_AGENT_INFO
/tmp/gpg-bxwM6w/S.gpg-agent:1611:1

However, it's not so simple: the gnupg documentation says

(gpg-agent) is automatically started on demand by gpg, gpgsm, gpgconf, or gpg-connect-agent. Thus there is no reason to start it manually.

Meanwhile, the Arch Wiki is somewhat ambivalent. (However they're talking about a newer version of gnupg than what we have.)

gpg-agent also has its own variation of ssh support.

So, for now let's leave gpg-agent to its own devices (not starting it) and let those users who want it, figure things out...

Last edited by johnraff (2016-02-09 05:27:04)

tknomanzr · 2016-02-09 05:08:14

tknomanzr@wtfbox-bl:~$ echo $SSH_AUTH_SOCK
/tmp/ssh-ZroeCR85XzmU/agent.1143

and the relevant portion from autostart

eval $(gnome-keyring-daemon -s --components=pkcs11,secrets,ssh,gpg) &

It does work. I pushed several commits to Github the other night with it setup. The whole subject does interest me, however, because I now see a way to avoid the security problems that using sshpass presents in my scripts. I am going to look into switching my systemd backup script, along with my sshfs script, which is also soon to be converted to autostart via systemd, over to using it. I was already thinking I needed an sha256 hash for the password anyway, but ssh-agent will be much better and I can update those posts to reflect using it.

Last edited by tknomanzr (2016-02-09 05:08:30)

johnraff · 2016-02-09 05:15:26

^OK that means you're using ssh-agent. gnome-keyring is being started but its ssh and/or gpg envvars aren't being exported. The ampersand at the end, and openbox/autostart's status as a child of the startup process, see to that. You might just as well replace that line with

gnome-keyring-daemon -s --components=pkcs11,secrets

for now, to keep things cleaner.

tknomanzr · 2016-02-09 05:27:08

Ok will do. And hopefully in the next few days I will be able to figure out how to implement its usage in my scripts.

xaos52 · 2016-02-09 12:23:30

I intend to report here on a series of tests I am running on ssh, ssh-agent, gpg , gpg-agent and gnome-keyring-daemon.

For starters I am setting up an ssh connection to a server using public key authentication.

I used this ubuntu wiki entry as a guideline.

I will be connecting from a portable PC (hostname 'medion') to another portable PC (hostname 'a1711' Acer 1711SMi, a 17 inch dinosaur desktop repacement PC weighing in at some 7 kilos or so). Both PC's are connected with an ethernet crossover cable.
Network interfaces are configured 'manually' using NetworkManager.
Hostnames are set in /etc/hosts:

on medion:
/etc/hosts

192.168.1.11    a1711

me@medion:~$ ip r
default via 192.168.0.1 dev wlan0  proto static  metric 1024 
192.168.0.0/24 dev wlan0  proto kernel  scope link  src 192.168.0.240 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.10

Follow the wiki entry to set things up.
Do use a passphrase to protect your private key, otherwise your private key will not be encrypted.

Now I am able to connect to the server using public key authentication.
But I still have to enter the passphrase - to unlock your private key - every time I connect to the server.

Enter 'ssh-add' to solve that problem:

me@medion:~/.ssh$ ssh-add
Enter passphrase for /home/me/.ssh/id_rsa: 
Identity added: /home/me/.ssh/id_rsa (/home/me/.ssh/id_rsa)

How does it work?
ssh-add talks to ssh-agent - which is listening on the socket pointed to by SSH_AGENT_SOCK - which stores the passphrase in a safe way.
Next time you try to ssh to the server, ssh talks to ssh-agent (again using the socket from above) which supplies the cached passphrase and ssh moves on.

Result:
No user intervention is needed to ssh into your server during the time period where ssh-agent caches your passphrase. This 'grace period' can be configured with the -t parameter for ssh-agent. Defaults to forever.
And you can run scripts on the client that connect to the server without user intervention.

me@medion:~/.ssh$ ssh me@a1711
Warning: Permanently added 'a1711,192.168.1.11' (ECDSA) to the list of known hosts.

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Feb  9 12:09:33 2016 from 192.168.1.10

Should you want to disable the banner that is shown every time you log in to the server, then, on the server:

me@a1711:~$ sudo sed -i '/pam_motd.so/s/^/#/' /etc/pam.d/sshd

Log out and ssh into the server again:

me@medion:~/.ssh$ ssh me@a1711
Warning: Permanently added 'a1711,192.168.1.11' (ECDSA) to the list of known hosts.
Last login: Tue Feb  9 12:29:33 2016 from 192.168.1.10
me@a1711:~$

What if you don't want ssh-agent to cache your passphrase?
You want gnome-keyring to do the caching for you?

export $(gnome-keyring-daemon --start --components=ssh)

You now get password entry screen. Enter your user password.
You get another password entry screen. Enter your passphrase protecting your private key.
You will get your prompt back.
You are not logged into the server yet.
Connect to the server again and you will be logged into the server automatically.

!!!WARNING!!!
When you are presented with the password entry screen, do not switch windows or switch desktop. You will not be able to switch back to the password entry screen, because that password entry screen has grabbed your keyboard. The only way to get out of this is to switch to a Virtual Console, stop X (sudo systemctl isolate multi-user.target) and restart X (sudo systemctl isolate graphical.target)

The system is now in a state where both ssh-agent and gnome-keyring are caching the passphrase. But only one of those is active at any one time. Which one can be seen by running

env|grep -i ssh

if you get

me@medion:~/tmp/today$ env | grep -i ssh
SSH_AGENT_PID=1593
SSH_AUTH_SOCK=/tmp/ssh-D8KueWVYCR4R/agent.1567
OLDPWD=/home/me/.ssh

then ssh-agent will provide the cached passphrase,
if you get

SSH_AGENT_PID=777
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

then gnome-keyring will provide the cached passphrase.
It is the value of SSH_AGENT_SOCK that makes the difference.

You can switch from gnome-keyring providing the passphrase to ss-agent doing it by

eval $(ssh-agent)

Which proves that it is the setting of SSH_AGENT_SOCK that controls which application is providing the passphrase.

NOTE:
These tests were performed on a bunsenlabs RC2 instance installed to a btrfs subvolume.
So with
- ssh installed
- ssh-agent enabled
- no gpg
- $HOME/.config/openbox/environment set to

## GNOME Keyring
# WARNING: interpreter is dash!
export $(gnome-keyring-daemon --start --components=pkcs11,secrets)

johnraff · 2016-02-10 07:57:06

^Thank you. This makes life simpler.

#61 2016-02-05 04:35:58

Re: initializing gnome-keyring-daemon in autostart

#62 2016-02-05 09:55:53

Re: initializing gnome-keyring-daemon in autostart

#63 2016-02-06 04:50:55

Re: initializing gnome-keyring-daemon in autostart

#64 2016-02-06 16:37:35

Re: initializing gnome-keyring-daemon in autostart

#65 2016-02-07 01:49:32

Re: initializing gnome-keyring-daemon in autostart

#66 2016-02-07 07:03:09

Re: initializing gnome-keyring-daemon in autostart

#67 2016-02-07 09:46:57

Re: initializing gnome-keyring-daemon in autostart

#68 2016-02-07 17:10:52

Re: initializing gnome-keyring-daemon in autostart

#69 2016-02-08 02:58:38

Re: initializing gnome-keyring-daemon in autostart

#70 2016-02-08 17:42:14

Re: initializing gnome-keyring-daemon in autostart

#71 2016-02-08 23:53:29

Re: initializing gnome-keyring-daemon in autostart

#72 2016-02-09 04:59:10

Re: initializing gnome-keyring-daemon in autostart

#73 2016-02-09 05:08:14

Re: initializing gnome-keyring-daemon in autostart

#74 2016-02-09 05:15:26

Re: initializing gnome-keyring-daemon in autostart

#75 2016-02-09 05:27:08

Re: initializing gnome-keyring-daemon in autostart

#76 2016-02-09 12:23:30

Re: initializing gnome-keyring-daemon in autostart

#77 2016-02-10 07:57:06

Re: initializing gnome-keyring-daemon in autostart

Board footer