Bug 770251

Summary: Provide native systemd service
Product: [Fedora] Fedora Reporter: Jóhann B. Guðmundsson <johannbg>
Component: dropbearAssignee: Lennert Buytenhek <buytenh>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: buytenh, colin, gwync, itamar
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-20 15:14:50 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:
Bug Depends On:    
Bug Blocks: 751869    
Attachments:
Description Flags
Native systemd service for dropbear
none
Native systemd service for dropbear keygen none

Description Jóhann B. Guðmundsson 2011-12-24 22:45:26 UTC
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 22:46:27 UTC
Created attachment 549456 [details]
Native systemd service for dropbear

Comment 2 Jóhann B. Guðmundsson 2011-12-24 22:49:18 UTC
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 20:02:19 UTC
Lennert, any objection to my doing this?

Comment 4 Lennert Buytenhek 2012-04-20 01:23:12 UTC
Absolutely not -- please go ahead.  Sorry for dropping the ball on this.

Comment 5 Gwyn Ciesla 2012-04-20 15:14:50 UTC
No worries, done.

Comment 6 Colin Guthrie 2012-04-22 10:31:44 UTC
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 10:34:19 UTC
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 10:35:04 UTC
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 15:58:41 UTC
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 16:09:07 UTC
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.