Bug 805338

Summary: openssh-server unconditionally installs sshd-keygen.service, slows down boot
Product: [Fedora] Fedora Reporter: Daniel Drake <dsd>
Component: opensshAssignee: Petr Lautrbach <plautrba>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: mattias.ellert, mgrepl, plautrba, reklov, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openssh-5.9p1-20.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-12 02:04:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
sshd-keygen.service WantedBy=sshd.service none

Description Daniel Drake 2012-03-20 22:38:18 UTC 
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?
Comment 1 Petr Lautrbach 2012-03-21 16:24:59 UTC 
Created attachment 571760 [details]
sshd-keygen.service WantedBy=sshd.service

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.
Comment 2 Petr Lautrbach 2012-03-21 16:26:39 UTC 
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
Comment 3 Daniel Drake 2012-03-21 20:31:19 UTC 
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.
Comment 4 Petr Lautrbach 2012-03-23 08:25:59 UTC 
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.

Thanks.
Comment 5 Fedora Update System 2012-03-23 08:48:57 UTC 
openssh-5.9p1-20.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/openssh-5.9p1-20.fc17
Comment 6 Daniel Drake 2012-03-23 14:21:04 UTC 
Thanks for the quick fix - much appreciated!
Comment 7 Fedora Update System 2012-03-23 17:11:35 UTC 
Package openssh-5.9p1-20.fc17:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2012-4562/openssh-5.9p1-20.fc17
then log in and leave karma (feedback).
Comment 8 Volker Sobek 2012-04-06 04:40:42 UTC 
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?
Comment 9 Petr Lautrbach 2012-04-06 19:31:44 UTC 
I've removed sshd-keygen.service completely. sshd-keygen is run from
sshd.service now:

# cat /usr/lib/systemd/system/sshd.service 
[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
Comment 10 Fedora Update System 2012-04-06 19:40:48 UTC 
openssh-5.9p1-22.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/openssh-5.9p1-22.fc17
Comment 11 Fedora Update System 2012-04-12 02:04:48 UTC 
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.
Comment 12 Fedora Update System 2012-04-12 03:36:01 UTC 
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.