Bug 770251 - Provide native systemd service
Provide native systemd service
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dropbear (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lennert Buytenhek
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 751869
  Show dependency treegraph
 
Reported: 2011-12-24 17:45 EST by Jóhann B. Guðmundsson
Modified: 2012-04-23 12:09 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-20 11:14:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Native systemd service for dropbear (215 bytes, text/plain)
2011-12-24 17:46 EST, Jóhann B. Guðmundsson
no flags Details
Native systemd service for dropbear keygen (421 bytes, text/plain)
2011-12-24 17:49 EST, Jóhann B. Guðmundsson
no flags Details

  None (edit)
Description Jóhann B. Guðmundsson 2011-12-24 17:45:26 EST
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:
Comment 1 Jóhann B. Guðmundsson 2011-12-24 17:46:27 EST
Created attachment 549456 [details]
Native systemd service for dropbear
Comment 2 Jóhann B. Guðmundsson 2011-12-24 17:49:18 EST
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...
Comment 3 Gwyn Ciesla 2012-04-19 16:02:19 EDT
Lennert, any objection to my doing this?
Comment 4 Lennert Buytenhek 2012-04-19 21:23:12 EDT
Absolutely not -- please go ahead.  Sorry for dropping the ball on this.
Comment 5 Gwyn Ciesla 2012-04-20 11:14:50 EDT
No worries, done.
Comment 6 Colin Guthrie 2012-04-22 06:31:44 EDT
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.
Comment 7 Colin Guthrie 2012-04-22 06:34:19 EDT
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
Comment 8 Colin Guthrie 2012-04-22 06:35:04 EDT
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 :)
Comment 9 Gwyn Ciesla 2012-04-23 11:58:41 EDT
Lennert, I've enabled pam and fixed the unit file as above.  Not sure about any further fixes required, you should have a look.
Comment 10 Colin Guthrie 2012-04-23 12:09:07 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.