SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

expoodo · 2024-01-30 22:48:28

In the wiki article for gnome keyring, it says to set `SSH_AUTH_SOCK` to `$XDG_RUNTIME_DIR/gcr/ssh` when using the gcr-ssh-agent implementation, which I have done in my `~/.xprofile`. However, when I do `echo $SSH_AUTH_SOCK`, it outputs `$XDG_RUNTIME_DIR/keyring/ssh`. I've tried putting `set -x` in my `/etc/profile` to log any commands and see if anything else is setting `SSH_AUTH_SOCK`, but there wasn't any.

`/etc/xdg/autostart/gnome-keyring-ssh.desktop` is disabled in my xdg autostart (I've set Launch GNOME services on startup to true in my XFCE session settings).
`gnome-keyring-daemon.service` also doesn't have `ssh` in its components (although it seems to have something to do with `/usr/bin/ssh-agent`?):

● gnome-keyring-daemon.service - GNOME Keyring daemon
     Loaded: loaded (/usr/lib/systemd/user/gnome-keyring-daemon.service; disabled; preset: enabled)
     Active: active (running) since Tue 2024-01-30 17:09:01 EST; 28min ago
TriggeredBy: ● gnome-keyring-daemon.socket
   Main PID: 14808 (gnome-keyring-d)
      Tasks: 6 (limit: 19024)
     Memory: 12.9M (peak: 13.7M)
        CPU: 88ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/gnome-keyring-daemon.service
             ├─14808 /usr/bin/gnome-keyring-daemon --foreground --components=pkcs11,secrets --control-directory=/run/user/1000/keyring
             └─16470 /usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh

Jan 30 17:09:01 canada-desktop systemd[14630]: Started GNOME Keyring daemon.
Jan 30 17:09:01 canada-desktop gnome-keyring-daemon[14808]: GNOME_KEYRING_CONTROL=/run/user/1000/keyring
Jan 30 17:09:01 canada-desktop gnome-keyring-daemon[14808]: The Secret Service was already initialized
Jan 30 17:09:01 canada-desktop gnome-keyring-daemon[14808]: The PKCS#11 component was already initialized
Jan 30 17:09:01 canada-desktop gnome-keyring-d[14808]: The Secret Service was already initialized
Jan 30 17:09:01 canada-desktop gnome-keyring-d[14808]: The PKCS#11 component was already initialized
Jan 30 17:09:04 canada-desktop gnome-keyring-daemon[14808]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk
Jan 30 17:09:04 canada-desktop gnome-keyring-d[14808]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk
Jan 30 17:09:05 canada-desktop gnome-keyring-daemon[14808]: asked to register item /org/freedesktop/secrets/collection/login/5, but it's already registered
Jan 30 17:09:05 canada-desktop gnome-keyring-d[14808]: asked to register item /org/freedesktop/secrets/collection/login/5, but it's already registered

Am I doing something wrong or is this expected behavior? I'm using XFCE 4.18.
Thanks,

Last edited by expoodo (2024-02-22 02:09:06)

seth · 2024-01-30 23:16:11

Are other variables from ~/.xprofile sourced?
Try to add eg. "export FOO=BAR"
How do you start the xfce4 session?

expoodo · 2024-01-30 23:23:31

Are other variables from ~/.xprofile sourced?

My ~/.xprofile is just this

# ~/.xprofile
export SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gcr/ssh

Try to add eg. "export FOO=BAR"

I did that and logged in and out using `xfce4-session-logout`, and $FOO was set correctly

How do you start the xfce4 session?

I'm using lightdm-gtk-greeter and lightdm as my display manager ( I didn't use a saved session )

Last edited by expoodo (2024-01-30 23:24:46)

seth · 2024-01-31 15:41:55

It's not like I know much about gnome, but the two services seem mutually exclusive and the status above also complains about "The Secret Service was already initialized"

You probably have gnome-keyring-daemon.socket and gcr-ssh-agent.socket in "systemctl --user"?
What if you disable/mask the gnome-keyring-daemon.socket ?

icar · 2024-01-31 16:56:43

Have you tried https://wiki.archlinux.org/title/GNOME/ … #Disabling?

To disable the gnome-keyring-daemon implementation in an account-local way, copy /etc/xdg/autostart/gnome-keyring-ssh.desktop to ~/.config/autostart/ and then append the line Hidden=true to the copied file. Also undo any gnome-keyring-daemon.service edits you made as per the above instructions.

expoodo · 2024-02-01 21:03:08

seth wrote:

You probably have gnome-keyring-daemon.socket and gcr-ssh-agent.socket in "systemctl --user"?
What if you disable/mask the gnome-keyring-daemon.socket ?

Tried doing that and it only made `/usr/bin/gnome-keyring-daemon` run without any components or a control directory, but $SSH_AUTH_SOCK was still set to `$XDG_RUNTIME_DIR/keyring/ssh`

icar wrote:

Have you tried https://wiki.archlinux.org/title/GNOME/ … #Disabling?
To disable the gnome-keyring-daemon implementation in an account-local way, copy /etc/xdg/autostart/gnome-keyring-ssh.desktop to ~/.config/autostart/ and then append the line Hidden=true to the copied file. Also undo any gnome-keyring-daemon.service edits you made as per the above instructions.

Yes I have done that before but nothing changed.

I've tried grepping my entire filesystem to see if any file is setting $SSH_AUTH_SOCK, and didn't get anything. So I suppose its hardcoded into gnome-keyring? If that's the case then there's probably nothing I can do, so I'll leave this unsolved for now.

seth · 2024-02-01 21:52:11

https://unix.stackexchange.com/question … -auth-sock ?

Edit: no, you're using xfce

Last edited by seth (2024-02-01 21:54:55)

expoodo · 2024-02-01 22:26:02

seth wrote:

https://unix.stackexchange.com/question…-auth-sock ?

Went through both of the answers and comments and didn't get any results + `/usr/share/upstart/sessions/gnome-keyring-ssh.conf` didn't exist on my system so its probably an Ubuntu only thing

seth · 2024-02-01 22:47:58

The blablaSKIPblabla environment seems dead anyway - the environment beinghardcoded on wayland kinda triggered me. But you're not even meeting that parameter.
(And yes, upstart is/was ubuntu only)

https://gitlab.gnome.org/GNOME/gnome-ke … =heads#L61
https://gitlab.gnome.org/GNOME/gnome-ke … heads#L394

1. nice approach:
Try to set the environment in /usr/lib/systemd/user/gcr-ssh-agent.service (you can hack that in there for a test, the correct approach is https://wiki.archlinux.org/title/System … unit_files - "systemctl --user edit gcr-ssh-agent.service", mind the section header!)
2. naughty approach:

mkdir $XDG_RUNTIME_DIR/keyring # make sure there's an empty directory
sudo chattr +i $XDG_RUNTIME_DIR/keyring

This will prevent the creation of the socket there, gkd_ssh_agent_service_start will fail and the environment hopefully be left alone.

expoodo · 2024-02-01 23:38:19

seth wrote:

1. nice approach:
Try to set the environment in /usr/lib/systemd/user/gcr-ssh-agent.service (you can hack that in there for a test, the correct approach is https://wiki.archlinux.org/title/System … unit_files - "systemctl --user edit gcr-ssh-agent.service", mind the section header!)

I tried creating an override for gcr-ssh-agent.service (can you verify if the way I did it is correct?) and rebooting. I wasn't sure what you had in mind when setting the environment for the service though. However it didn't work.

### Editing /home/canada/.config/systemd/user/gcr-ssh-agent.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

[Service]
Environment=
Environment=SSH_AUTH_SOCK=${XDG_RUNTIME_DIR}/gcr/ssh

### Edits below this comment will be discarded


### /usr/lib/systemd/user/gcr-ssh-agent.service
# [Unit]
# Description=GCR ssh-agent wrapper
# 
# Requires=gcr-ssh-agent.socket
# 
# [Service]
# Type=simple
# StandardError=journal
# Environment=SSH_AUTH_SOCK=%t/gcr/ssh
# ExecStart=/usr/lib/gcr-ssh-agent %t/gcr
# Restart=on-failure
# 
# [Install]
# Also=gcr-ssh-agent.socket
# WantedBy=default.target

seth wrote:

2. naughty approach:
mkdir $XDG_RUNTIME_DIR/keyring # make sure there's an empty directory
sudo chattr +i $XDG_RUNTIME_DIR/keyring

Tried doing that with these steps and rebooting:

sudo rm -r $XDG_RUNTIME_DIR/keyring
mkdir $XDG_RUNTIME_DIR/keyring
sudo chattr +i $XDG_RUNTIME_DIR/keyring

Though it didn't work and then I realised /run on my system is a tempfs, and I rather prefer not to mess with the arch/systemd whatever mount defaults

Edit: I'm not sure if you meant this, but would patching out the lines in the gnome-keyring source files you linked and building from source be another possible solution ?

Last edited by expoodo (2024-02-01 23:44:04)

seth · 2024-02-01 23:54:49

1. Yes, but "Environment=SSH_AUTH_SOCK=%t/gcr/ssh" the service does it anyway
2.

I rather prefer not to mess with the arch/systemd whatever mount defaults

https://wiki.archlinux.org/title/System … rary_files

h    /run/user/1000/keyring                   -    -    -     -           +i

Since I just randomly saw that, what if you

export GNOME_KEYRING_CONTROL=/run/user/1000/gcr

in ~/.xprofile?

expoodo · 2024-02-02 00:25:39

seth wrote:

https://wiki.archlinux.org/title/System … rary_files
h    /run/user/1000/keyring                   -    -    -     -           +i

I tried created /etc/tmpfiles.d/keyring.conf, /etc/tmpfiles.d/user.conf and vice versa with /usr/share/user-tmpfiles.d and added in the text you sent, although after a reboot it didn't affect /run/user/1000/keyring at all. Is there a special naming scheme or is there something else I'm doing wrong?

seth wrote:

Since I just randomly saw that, what if you
export GNOME_KEYRING_CONTROL=/run/user/1000/gcr
in ~/.xprofile?

It didn't do anything (at least for $SSH_AUTH_SOCK)

seth · 2024-02-02 08:41:51

Sorry, https://wiki.archlinux.org/title/system … rary_files

expoodo · 2024-02-03 02:04:35

I'm getting this error:

 Operation not permitted while setting flags on /run/user/1000/keyring

Tried setting `AmbientCapabilities=CAP_LINUX_IMMUTABLE` in the override for `systemd-tmpfiles-setup.service` following this source

But then I get this error:

× systemd-tmpfiles-setup.service - Create User's Volatile Files and Directories
     Loaded: loaded (/usr/lib/systemd/user/systemd-tmpfiles-setup.service; enabled; preset: enabled)
    Drop-In: /home/canada/.config/systemd/user/systemd-tmpfiles-setup.service.d
             └─override.conf
     Active: failed (Result: exit-code) since Fri 2024-02-02 20:55:48 EST; 54s ago
       Docs: man:tmpfiles.d(5)
             man:systemd-tmpfiles(8)
    Process: 40315 ExecStart=systemd-tmpfiles --user --create --remove --boot (code=exited, status=216/GROUP)
   Main PID: 40315 (code=exited, status=216/GROUP)
        CPU: 17ms

Feb 02 20:55:48 canada-desktop systemd[40283]: Starting Create User's Volatile Files and Directories...
Feb 02 20:55:48 canada-desktop (tmpfiles)[40315]: systemd-tmpfiles-setup.service: Failed to determine supplementary groups: Operation not permitted
Feb 02 20:55:48 canada-desktop systemd[40283]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=216/GROUP
Feb 02 20:55:48 canada-desktop systemd[40283]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'.
Feb 02 20:55:48 canada-desktop systemd[40283]: Failed to start Create User's Volatile Files and Directories.

Setting User and Group to root in the service file just makes the service spit out permission denied errors.
Im stuck, is there something else that can be done?

seth · 2024-02-03 09:35:07

Ah, the greatness of systemd - system tempfiles get shadowed by session mounts and session tempfiles can't do shit.
Since we might be chasing a wild goose anyway, create and chattr the directory in your .xprofile and simply grant yourself NOPASSWD in your sudoers for the precise chattr command.
If this works at all, we can start focussing on how to get there in a slightly less hackish way…

expoodo · 2024-02-05 22:16:55

Honestly, I'm going to leave this post unsolved for now because I'm getting a bit too tired on finding a fix for this topic, and its not too big of a deal anyways. Thanks for taking the time to help me and sorry too

Kisuke-CZE · 2024-02-20 11:31:40

Hi,

I was facing same issue since start of February and this thread helped me a lot. I was not aware about changes in Gnome Keyring.

For me adding

export SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gcr/ssh

into

/etc/profile.d/ssh_auth_gcr.sh

was the solution.

===========================================

For some reason

Environment=SSH_AUTH_SOCK=%t/gcr/ssh

in

/usr/lib/systemd/user/gcr-ssh-agent.service

from package does not do the trick...

Last edited by Kisuke-CZE (2024-02-20 11:32:47)

murkl · 2024-02-21 11:23:18

This works for me (interactive shell only):

systemctl --user enable gcr-ssh-agent.socket

echo 'SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gcr/ssh' > ~/.config/environment.d/ssh_auth.conf

expoodo · 2024-02-22 02:08:09

Kisuke-CZE wrote:

Hi,
I was facing same issue since start of February and this thread helped me a lot. I was not aware about changes in Gnome Keyring.
For me adding
export SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gcr/ssh
into
/etc/profile.d/ssh_auth_gcr.sh
was the solution.

Wow, that actually fixed the problem. Thank you!!!

Last edited by expoodo (2024-02-22 02:08:22)

seth · 2024-02-22 07:58:02

So basically your .xprofile doesn't get sourced after all?
Edit: or at least it's not relevant to the gcr context.

Last edited by seth (2024-02-22 07:58:50)

expoodo · 2024-02-22 22:54:08

seth wrote:

So basically your .xprofile doesn't get sourced after all?
Edit: or at least it's not relevant to the gcr context.

That's what I think.

TE · 2024-02-25 15:32:21

murkl wrote:

This works for me (interactive shell only):

systemctl --user enable gcr-ssh-agent.socket
echo 'SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gcr/ssh' > ~/.config/environment.d/ssh_auth.conf

I'm using MATE and came across this thread because "stuff stopped working right after my weekly upgrade", this didn't work for MATE (reading the systemd man pages, this environment data is passed along under certain unit conditions only and it appears MATE doesn't do things the way, say, XFCE does etc.) but it got me to the same working solution:

(a) ensure the SOCKET unit is linked globally (service unit not required):

/etc/systemd/user/sockets.target.wants/gcr-ssh-agent.socket -> /usr/lib/systemd/user/gcr-ssh-agent.socket

(b) add to the end of my ~/.bashrc:

SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gcr/ssh
export SSH_AUTH_SOCK

I tested various methods - .profile, ,pam_environment, etc. and found adding it to .bashrc to be the only working solution (use .zshrc etc. as needed) for my generic MATE desktop that does not run terminals as login commands. At runtime, what you should then see is the socket launch ssh-agent as needed like so in the process list:

PID    PPID   CMD
880    1      /usr/lib/systemd/systemd --user
892    880    /usr/lib/gcr-ssh-agent --base-dir /run/user/1000/gcr
1765   892    /usr/bin/ssh-agent -D -a /run/user/1000/gcr/.ssh

Last edited by TE (2024-02-25 18:44:19)

raven2cz · 2024-02-26 08:46:15

For me, the propagation of the SSH_AUTH_SOCK variable stopped working after today's system update!

It would be good to have someone who can take a proper look at what the problem is. Your workaround works, but it's not a general solution.

The update made the following changes:

[2024-02-26T09:37:45+0100] [ALPM] upgraded networkmanager (1.44.2-3 -> 1.46.0-2)
[2024-02-26T09:37:45+0100] [ALPM] upgraded openssh (9.6p1-1 -> 9.6p1-3)

Last edited by raven2cz (2024-02-26 08:49:36)

TE · 2024-02-26 16:30:59

I think I found the upstream chatter regarding this issue, which points at evidence we're struggling with the change to gnome-keyring not working as expected.

https://gitlab.gnome.org/GNOME/gnome-ke … issues/140

You can then find links to attempts at change and others having the same problems and hack solutions we're having in this thread.

Cbhihe · 2024-02-26 17:49:19

I solved a very similar issue last week.

See https://bbs.archlinux.org/viewtopic.php?id=293029

Arch Linux

#1 2024-01-30 22:48:28

SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#2 2024-01-30 23:16:11

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#3 2024-01-30 23:23:31

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#4 2024-01-31 15:41:55

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#5 2024-01-31 16:56:43

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#6 2024-02-01 21:03:08

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#7 2024-02-01 21:52:11

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#8 2024-02-01 22:26:02

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#9 2024-02-01 22:47:58

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#10 2024-02-01 23:38:19

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#11 2024-02-01 23:54:49

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#12 2024-02-02 00:25:39

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#13 2024-02-02 08:41:51

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#14 2024-02-03 02:04:35

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#15 2024-02-03 09:35:07

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#16 2024-02-05 22:16:55

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#17 2024-02-20 11:31:40

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#18 2024-02-21 11:23:18

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#19 2024-02-22 02:08:09

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#20 2024-02-22 07:58:02

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#21 2024-02-22 22:54:08

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#22 2024-02-25 15:32:21

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#23 2024-02-26 08:46:15

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#24 2024-02-26 16:30:59

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

#25 2024-02-26 17:49:19

Re: SSH_AUTH_SOCK not being set to `$XDG_RUNTIME_DIR/gcr/ssh` [SOLVED]

Board footer