Description of problem: ssh-agent.service user unit has no installation config settings in the [Install] section. Version-Release number of selected component (if applicable): openssh-clients-8.8p1-1.fc36.1.x86_64 How reproducible: Always Steps to Reproduce: 1. systemctl --user enable ssh-agent.service Actual results: The unit files have no installation config (WantedBy=, RequiredBy=, Also=, Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: • A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. • A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. • A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). • In case of template units, the unit is meant to be enabled with some instance name specified. Expected results: No error, unit should get enabled. Additional info: Due to the above, the unit cannot be enabled easily in MATE session (after disabling gnome-keyring SSH component and applying https://src.fedoraproject.org/rpms/xorg-x11-xinit/pull-request/5).
Would you mind suggesting a patch?
I checked a few random user services and found they're all static. However, they're either triggered by a socket or dbus-activated. For example, gpg-agent-ssh.service is triggered by gpg-agent-ssh.socket, so maybe the same should be done for ssh-agent. We would have to hard-code the socket path in that case, but then it'd work similar to gpg-agent-ssh.service, which I think is desirable. If nobody beats me to it, I'll try to post a patch soon.
I've been using my own (similar) set of user units just to recently learn openssh-clients includes them. Which made me happy to hear. Sadly I ran into this RHBZ when trying to actually use it. I took a stab at fixing this here https://src.fedoraproject.org/rpms/openssh/pull-request/35
FEDORA-2022-fae4ff2403 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fae4ff2403
FEDORA-2022-fae4ff2403 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
So looks like on the installation images this breaks SSH access to the installation environment, see bug 2136916. Basically, if inst.sshd is passed as boot option, the Anaconda installer tries to start sshd. that used to work, but with openssh-9.0p1-6.fc38 sshd.socket is now active and already bind to the point, breaking the anaconda-sshd service. Not really sure how the SSH agent unit/socket changes do that, but it does happen.
That is quite an unfortunate occurrence. Later today I will read closer into how Anaconda ssh works and hopefully use a systemd directive like "Conflicts" to avoid the ssh-socket being used during installation. Better yet, really understand how this breaks things because it shouldn't..
Any updates on this ? This still blocking CI image refresh for our Web UI tests (making it more and more likely it breaks with the outdated image) as well as making any runtime installation issues hard to debug. A speedy fix or revert of the patch causing this issues would be appreciated!
Closing as we found that the issue is not related to openssh but instead it seems it is a systemd issue. Will be handled in bug 2136916 .