Red Hat Bugzilla – Bug 805338
openssh-server unconditionally installs sshd-keygen.service, slows down boot
Last modified: 2012-04-11 23:36:01 EDT
Testing Fedora 17, with openssh-server-5.9p1-19.fc17 on low-power OLPC XO laptops.
We ship then openssh server in our distribution as a development/debug tool, but we ship it by default (developers need to start the service manually the first time). On F14 and older we had this set up so that the SSH keys would only be generated the first time the developer manually starts the SSH service (the key generation takes quite a while on our low-power hardware).
On F17, this ability seems to have been lost. Just installing openssh-server installs a sshd-keygen systemd unit file which is pulled into multi-user.target by default (even when sshd is not enabled), meaning that our first-boot experience is paused by a lengthy key generation process.
Would it be possible to adjust the unit files here? Could sshd.service pull in sshd-keygen.service as a dependency, and then keygen would only happen if and when sshd gets started?
Created attachment 571760 [details]
This is unit file for sshd-keygen.service which is installed to sshd.service.wants so that sshd-keygen is run only before sshd.service is started.
Please try service file from #c1:
# cp sshd-keygen.service /etc/systemd/system
# systemctl daemon-reload
# systemctl disable sshd-keygen.service
# systemctl enable sshd-keygen.service
That seems to work, thanks.
Another option, and a little simpler, is to delete the [Install] section from sshd-keygen.service.
Then modify sshd.service to add Wants=sshd-keygen.service
Then the only service that needs enable/disable consideration is sshd, and when starting it pulls in sshd-keygen.
I've tested this too, and it's working. But I'm not a systemd expert so there may be something I'm missing.
You are right, Wants=sshd-keygen.service is simpler here. I've also added BindTo=sshd.service to sshd-keygen.service so that sshd-keygen.service is automatically stopped when sshd.service is stopped.
openssh-5.9p1-20.fc17 has been submitted as an update for Fedora 17.
Thanks for the quick fix - much appreciated!
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openssh-5.9p1-20.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
This change must have triggered bug https://bugzilla.redhat.com/show_bug.cgi?id=810419 - sshd.service active after boot (even though it is disabled).
I can see now that the change BindTo=sshd.service to sshd-keygen.service in connection with its symlink to /etc/systemd/system/multi-user.target.wants/ ( that was NOT removed during the upgrade process) caused bug 810419. How are these symlinks created/removed in updates?
I've removed sshd-keygen.service completely. sshd-keygen is run from
# cat /usr/lib/systemd/system/sshd.service
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
openssh-5.9p1-22.fc17 has been submitted as an update for Fedora 17.
openssh-5.9p1-22.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
openssh-5.9p1-20.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.