FWIW,

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"
    else
        SSH_AGENT="/usr/bin/ssh-agent"
    fi
fi

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:

  /etc/xdg/plasma-workspace/env/ssh-agent-startup.sh
  /etc/xdg/plasma-workspace/shutdown/ssh-agent-shutdown.sh

Example contents can be found f.ex. from this posting: https://forum.kde.org/viewtopic.php?f=309&t=153769

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

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

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/ssh-agent-startup.sh
    -rwxr-xr-x. 1 root root 64 May  2 19:18 /etc/xdg/plasma-workspace/shutdown/ssh-agent-shutdown.sh

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

    # cat /etc/xdg/plasma-workspace/shutdown/ssh-agent-shutdown.sh 
    #!/usr/bin/sh
    [ -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_AUTH_SOCK=/tmp/ssh-4TZdr3uAynUU/agent.15063
    SSH_AGENT_PID=15064
    SSH_ASKPASS=/usr/bin/ksshaskpass

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

After logout the ssh-agent process is killed again.

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?

(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.

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.

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

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.

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.

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

Another option:
https://unix.stackexchange.com/questions/339840/how-to-start-and-use-ssh-agent-as-systemd-service

(In reply to Rex Dieter from comment #11)
> Another option:
> https://unix.stackexchange.com/questions/339840/how-to-start-and-use-ssh-
> agent-as-systemd-service

Yeah, doing it this way would make some sense.

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.

Implementation details:

1. set environment variable (to be usable from .service)
SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"

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:

[Unit]
Description=SSH key agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

I've seen differing examples that use
Type=simple
vs
Type=forking


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

This combination should do it:

https://src.fedoraproject.org/rpms/kde-settings/c/28d6612330ac747f94bca671a1030695b0622c43

https://src.fedoraproject.org/rpms/plasma-workspace/c/b543dcfebe424456c4c675f0e0ea9eadacdf0ff7

builds underway

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 

https://src.fedoraproject.org/rpms/kde-settings/blob/rawhide/f/ssh-agent.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

With plasma-workspace-5.21.1-3 I see two ssh-agent, one started from startplasma-x11, second from ssh-agent.service

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:
ConditionEnvironment=!SSH_AGENT_PID
service runs prior to xinit, so SSH_AGENT_PID isn't set yet

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

* move /etc/xdg/plasma-workspace/env/ssh-agent.sh 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)

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.

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

(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 
> 
> https://src.fedoraproject.org/rpms/kde-settings/blob/rawhide/f/ssh-agent.
> 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.

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.

> 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)

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/ssh-agent.sh

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?

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
SuccessExitStatus=2
resolves that portion

See
https://src.fedoraproject.org/rpms/openssh/pull-request/19

openssh-clients-8.5p1-1.fc34 installs /usr/lib/systemd/system/ssh-agent.service

https://koji.fedoraproject.org/koji/rpminfo?rpmID=25477192

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

Yes, my bad, should be fixed in openssh-8.5p1-2

FEDORA-2021-f68a5a75ba has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f68a5a75ba

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: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f68a5a75ba

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

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.