Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1761817 - ssh-agent is not started via systemd user unit and thus doesn't activate on Wayland
Summary: ssh-agent is not started via systemd user unit and thus doesn't activate on W...
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-desktop
Version: 34
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1882465
TreeView+ depends on / blocked
Reported: 2019-10-15 12:52 UTC by Göran Uddeborg
Modified: 2021-03-23 00:15 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-03-23 00:15:28 UTC
Type: Bug

Attachments (Terms of Use)

Description Göran Uddeborg 2019-10-15 12:52:03 UTC
Description of problem:
After upgrading to Fedora 31, I decided to try out Wayland again.  One feature I miss is automatically getting an ssh-agent running for the session.

Version-Release number of selected component (if applicable):
I'm not sure exactly which package to list here.  Assigning this report to plasma-worspace initially is just a guess.

How reproducible:
Every time

Steps to Reproduce:
1. Start a Plasma Wayland session
2. Start a terminal window
3. ssh-add

Actual results:
Ssh-add can not connect to any authentication agent.  (Checking with ps, there isn't any running.)

Expected results:
Asking for passphrase, and adding the private keys into the agent.

Additional info:
To me this feels as a regression, but it could of course be an intentional change.  I'm also not sure if it is on Fedora level or belong upstreams.  Just let me know, and I could bring it upstreams.  If it is intentional, I believe I can figure out how to do it myself.

Comment 1 Rex Dieter 2019-10-15 17:41:40 UTC

xinit handles launching ssh-agent for plasma (among others, though I don't believe gnome-shell uses xinit for awhile):

/etc/X11/xinit/xinitrc-common snippet:

# Prefix launch of session with ssh-agent if available and not already running.
if [ -z "$SSH_AGENT" ] && [ -z "$SSH_AUTH_SOCK" ] && [ -z "$SSH_AGENT_PID" ] && [ -x /usr/bin/ssh-agent ]; then
    if [ "x$TMPDIR" != "x" ]; then
        SSH_AGENT="/usr/bin/ssh-agent /bin/env TMPDIR=$TMPDIR"

Comment 2 Stefan Becker 2020-05-02 16:03:10 UTC
This feels like a duplicate, but I can't find the bug. I know I discussed this way back (certainly pre-31) with Rex on IRC, when I tried Plasma on Wayland for the first time.

What is missing are these files:


Example contents can be found f.ex. from this posting:

ksshaskpass f.ex. already installs its setup file there.

As a workaround you can add those files per user under $HOME/.config/plasma-workspace/...

Comment 3 Stefan Becker 2020-05-02 16:30:45 UTC
I've now tested on my F32 system:

    # ls -l /etc/xdg/plasma-workspace/*/ssh*
    -rw-r--r--. 1 root root 50 May  2 19:08 /etc/xdg/plasma-workspace/env/
    -rwxr-xr-x. 1 root root 64 May  2 19:18 /etc/xdg/plasma-workspace/shutdown/

    # cat /etc/xdg/plasma-workspace/env/ 
    [ -n "$SSH_AGENT_PID" ] || eval "$(ssh-agent -s)"

    # cat /etc/xdg/plasma-workspace/shutdown/ 
    [ -z "$SSH_AGENT_PID" ] || eval "$(ssh-agent -k)"

(NOTE: the shutdown script must be an executable shell script)

After login into a KDE Plasma Wayland session I now get the expected:

    $ env | fgrep SSH

    $ ssh-add -l
    256 SHA256:WJ+.... (ED25519)

After logout the ssh-agent process is killed again.

Comment 4 Göran Uddeborg 2020-05-03 20:56:11 UTC
Thanks!  I had arrived at a slightly simpler variant of that.

A question about a detail: is there really any point of eval:ing the output of ssh-agent in the shutdown script?  It is a separate script so it won't unset variables for any other process, and it's anyway run when everything is being shut down.  Do I miss something, or was it just a copy-and-paste mistake?

Comment 5 Stefan Becker 2020-05-04 09:50:15 UTC
(In reply to Göran Uddeborg from comment #4)
> A question about a detail: is there really any point of eval:ing the output
> of ssh-agent in the shutdown script?

Yeah, you are correct, the situation is different than for the startup script. I just copy & pasted from the example.

The only thing the eval will give you is that it will remove the two "unset ..." lines from the script output.

Comment 6 Stefan Becker 2020-05-04 10:55:12 UTC
I wonder if ksshaskpass would be the correct package to add those scripts?

Another option would be plasma-workspace-wayland, but the reference to SSH might be unwanted there.

Comment 7 Rex Dieter 2020-05-04 15:46:47 UTC
Once upon a time, we had similar startup/shutdown scripts for gpg-agent, and those lived in kde-settings.  That would probably be a good fit for this too.

marking FutureFeature

Comment 8 Neal Gompa 2021-01-04 18:30:09 UTC
The issue here is that we're relying on SSH agent starting via xinit, and we should be relying on this starting via a systemd user unit, like how the GPG agent was changed some time ago.

This is something that the OpenSSH maintainers should fix.

Comment 9 Jakub Jelen 2021-01-05 11:59:23 UTC
There was never anything in openssh packages that would start ssh agent automatically.

The file /etc/X11/xinit/xinitrc-common is shipped by xorg-x11-xinit.

In gnome desktop, ssh agent is started through gnome-keyring. The gnome-desktop handles starting gnome-keyring (through gnome-keyring package in /etc/xdg/autostart/gnome-keyring-ssh.desktop). If KDE wants to start ssh-agent automatically, it is something that should be handled there to avoid conflicts with gnome desktop.

Comment 10 Rex Dieter 2021-02-23 15:29:33 UTC
We'll try to implement something plasma-specific for f34.

I still argue users (and fedora distro as a whole) would be better-served if this were handled globally by openssh, instead of adhoc solutions by each DE

Comment 12 Tomáš Mráz 2021-02-23 16:02:11 UTC
(In reply to Rex Dieter from comment #11)
> Another option:
> agent-as-systemd-service

Yeah, doing it this way would make some sense.

Comment 13 Tomáš Mráz 2021-02-23 16:04:55 UTC
Although there is still the issue that various DEs might have different idea what utility should actually their ssh agent service be. As Gnome probably wants to use gnome-keyring instead of the regular ssh-agent and that means the "default" service should be somehow overridable by individual DE.

Comment 14 Rex Dieter 2021-02-25 15:32:33 UTC
Implementation details:

1. set environment variable (to be usable from .service)

I think I'll also consider creating an environment file for this (e.g. /etc/sysconfig/ssh-agent-service), to allow users to customize more easily.

2. create ssh-agent.service file:

Description=SSH key agent

ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK


I've seen differing examples that use

3. enable service:
systemctl --user enable --now ssh-agent
(or possibly add a unit dependency on it somewhere)

Comment 16 Rex Dieter 2021-02-26 18:09:17 UTC
openssh maintainers, I feel it would be nice for other consumers to be able to more-easily opt-in to this way of enabling and using ssh-agent, any objection if this service unit

lived in openssh-clients package instead (default off, opt-in only for now)?

If not, I'll be happy to submit PR for it

Comment 17 nucleo 2021-02-28 14:46:25 UTC
With plasma-workspace-5.21.1-3 I see two ssh-agent, one started from startplasma-x11, second from ssh-agent.service

Comment 18 Rex Dieter 2021-02-28 17:18:33 UTC
Well, that's annoying. :-/

I'm having trouble conditionalizing this, due to the current "running ssh-agent via xinit" method being fairly inflexible.

Any hints/suggestions on how to make a systemd user unit run only on a wayland session welcome.  What I've tried so far that doesn't work:

* add to ssh-agent.service:
service runs prior to xinit, so SSH_AGENT_PID isn't set yet

* add to ssh-agent.service:
service runs prior to session start, so this variable isn't set yet

* move /etc/xdg/plasma-workspace/env/ to /etc/profile.d
doesn't help, xinit checks for SSH_AGENT_PID being set, and I've not yet found a way for a user service to export a variable (PassEnvironment doesn't do that, only to child processes of the service)

Comment 19 Göran Uddeborg 2021-02-28 18:41:35 UTC
Would it be possible to use the "environment block" in systemd for this? I'm thinking of putting (as in "systemctl import-environment") the environment from the ssh-agent service in the daemon, which could then be seen by the session when started. It sounds from the manual page as if it would be usable, but I don't really know these functions, so I might be completely wrong here.

Comment 20 nucleo 2021-02-28 19:37:01 UTC
Why startplasma-wayland can't start ssh-agent as startplasma-x11?

root         616  0.1  0.4 355776 17376 ?        Ssl  21:29   0:00 /usr/bin/sddm
root         634 11.6  2.1 252336 84732 tty1     Ssl+ 21:29   0:02  \_ /usr/libexec/Xorg -nolisten tcp -auth /var/run/sddm/{b82f4ef3-9a23-413f-9674-eac29c24ebd8} -background none -noreset -displayfd 16 -seat seat0 vt1
root         666  0.0  0.4 280232 16708 ?        S    21:29   0:00  \_ /usr/libexec/sddm-helper --socket /tmp/sddm-auth8bdc8b7c-0ab0-4c13-b0d4-e2dcedc3ed92 --id 1 --start /usr/bin/startplasma-x11 --user user --autologin
user         682  0.2  0.4 357860 19204 ?        Sl   21:29   0:00      \_ /usr/bin/startplasma-x11
user         703  0.0  0.0   7184   516 ?        Ss   21:30   0:00          \_ /usr/bin/ssh-agent /bin/sh -c exec -l /bin/bash -c "/usr/bin/startplasma-x11"

root         598  0.1  0.4 356016 17752 ?        Ssl  21:27   0:00 /usr/bin/sddm
root        1092  3.5  1.6 230276 65076 tty1     Ssl+ 21:27   0:00  \_ /usr/libexec/Xorg -nolisten tcp -auth /var/run/sddm/{424a1456-1df8-4fd5-a5d3-e3f7d4dc53e7} -background none -noreset -displayfd 16 -seat seat0 vt1
root        1131  0.6  0.4 280404 17616 ?        S    21:27   0:00  \_ /usr/libexec/sddm-helper --socket /tmp/sddm-autha3c3d5ea-3559-489e-b768-b68919c0fded --id 2 --start /usr/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplas
user        1140  1.0  0.4 357548 18708 tty2     Ssl+ 21:27   0:00      \_ /usr/bin/startplasma-wayland
user        1182  0.0  0.0   2376   744 tty2     S+   21:27   0:00          \_ /usr/bin/kwin_wayland_wrapper --xwayland /usr/libexec/startplasma-waylandsession
user        1183 43.1  3.7 3184484 149728 tty2   Rl+  21:27   0:03              \_ kwin_wayland --wayland_fd 4 --xwayland /usr/libexec/startplasma-waylandsession
user        1194  1.2  1.5 147784 60752 tty2     S+   21:27   0:00                  \_ /usr/bin/Xwayland -displayfd 34 -rootless -wm 37 -auth /run/user/1000/xauth_jABBji

Comment 21 Jakub Jelen 2021-03-01 09:51:13 UTC
(In reply to Rex Dieter from comment #16)
> openssh maintainers, I feel it would be nice for other consumers to be able
> to more-easily opt-in to this way of enabling and using ssh-agent, any
> objection if this service unit 
> service
> lived in openssh-clients package instead (default off, opt-in only for now)?
> If not, I'll be happy to submit PR for it

I would not mind if it would be something generic that could be used by other
DE. But this looks like it is closely tied to plasma/kde with the "After"
keyword as well as with the comment describing the environment and I do not
see a way how it could be reused. Do I miss something?

If it is the case, I would rather see it as part of kde packages, which will
make also the updating/modifications simpler for you.

Comment 22 Rex Dieter 2021-03-02 14:44:18 UTC
I've removed the After= from ssh-agent.service and added Before=ssh-agent.service to plasma's relevant target(s) to address your first concern.  

It is true that this implementation currently requires environments using it to set SSH_AUTH_SOCK somehow to match the well-known socket referenced in ssh-agent.service, at least until ssh-agent can be adjusted to support systemd socket activation.

If that's agreeable, I can move forward with a PR , otherwise, we can leave things as-is.

Comment 23 Rex Dieter 2021-03-02 14:45:45 UTC
> Why startplasma-wayland can't start ssh-agent as startplasma-x11?

x11 plasma sessions simply inherit ssh-agent that is launched via xinit (that cannot be used under wayland)

Comment 24 Jakub Jelen 2021-03-02 21:47:31 UTC
I think something like the current version linked above can live inside of openssh-clients package. Maybe also the comment could be more generic saying something like

# Requires SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"
# set in environment, handled for example in plasma via
# /etc/xdg/plasma-workspace/env/

The service can be also tweaked a bit more for example with

  Documentation=man:ssh-agent(1) man:ssh-add(1) man:ssh(1)

Not sure if you tried also the restart and kill of the agent. Does it work with default values or are some special ones needed?

Comment 25 Rex Dieter 2021-03-02 23:18:13 UTC
OK, PR on the way.  

As far as restart/kill(stop)... Looks like systemctl stop is unhappy since ssh-agent appears to have a non-zero exit code responding to signals, adding
resolves that portion

Comment 27 nucleo 2021-03-08 00:42:50 UTC
openssh-clients-8.5p1-1.fc34 installs /usr/lib/systemd/system/ssh-agent.service

Should it be in /usr/lib/systemd/user?

Comment 28 Rex Dieter 2021-03-09 15:20:18 UTC
Yes, my bad, should be fixed in openssh-8.5p1-2

Comment 29 Fedora Update System 2021-03-09 15:51:49 UTC
FEDORA-2021-f68a5a75ba has been submitted as an update to Fedora 34.

Comment 30 Fedora Update System 2021-03-09 22:45:42 UTC
FEDORA-2021-f68a5a75ba has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f68a5a75ba`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 31 Fedora Update System 2021-03-23 00:15:28 UTC
FEDORA-2021-f68a5a75ba has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.