Description of problem: Let's get the ball rolling on this one... http://fedoraproject.org/wiki/Features/SysVtoSystemd https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 549456 [details] Native systemd service for dropbear
Created attachment 549463 [details] Native systemd service for dropbear keygen It's sufficient for user only to start/enable dropbear.service and it will call dropbear-keygen.service which will generate the keys for them...
Lennert, any objection to my doing this?
Absolutely not -- please go ahead. Sorry for dropping the ball on this.
No worries, done.
This isn't technically fixed I'm afraid. Dropbear PAM support needs to be enabled otherwise connected sessions will be killed when restarting the service. I tried to doing this on a different dirstro, but it seems the pam support is somewhat lacking and doesn't seem to work and register a user session with systemd-logind so there will need to be code fixes too I believe. Figured I'd let you know.
Also, just for reference you probably don't want to have an install section in the keygen unit - just reference it from the main unit. Also the main unit probably wants to source extra options from sysconfig. e.g. [Unit] Description=Dropbear SSH Key Generatior Before=dropbear.service ConditionPathExists=!/etc/dropbear/dropbear_rsa_host_key ConditionPathExists=!/etc/dropbear/dropbear_dss_host_key [Service] Type=oneshot ExecStart=/usr/bin/dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key ExecStart=/usr/bin/dropbearkey -t dss -f /etc/dropbear/dropbear_dss_host_key RemainAfterExit=yes And: [Unit] Description=Dropbear SSH Server Daemon After=network.target Wants=dropbear-keygen.service [Service] Type=forking PIDFile=/var/run/dropbear.pid EnvironmentFile=-/etc/sysconfig/dropbear ExecStart=/usr/sbin/dropbear $OPTIONS [Install] WantedBy=multi-user.target
Sorry for spamming today: Make sure you fix the PIDFile patch if you're copying the above... we still use a different path to you :)
Lennert, I've enabled pam and fixed the unit file as above. Not sure about any further fixes required, you should have a look.
Just to provide an easy test case (how I tested): 1. Term 1: root$ systemctl start dropbear.service 2. Term 2: user$ ssh user@localhost 3. Term 1: root$ systemctl status dropbear.service If the pam stuff is not working, then you should see the user's bash process in the output from 3, and issuing a "systemctl restart dropbear.service" will kick the user out. Hope that helps. I'm not a pam expert, but I think it uses the /etc/pam.d/sshd file. Even if that is properly configured to use pam_systemd.so for the session, it still seems to fail, so likely it's misusing pam API in some way.