Bug 770251 - Provide native systemd service
Summary: Provide native systemd service
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: dropbear
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lennert Buytenhek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 751869
TreeView+ depends on / blocked
 
Reported: 2011-12-24 22:45 UTC by Jóhann B. Guðmundsson
Modified: 2012-04-23 16:09 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-20 15:14:50 UTC
Type: ---
Embargoed:


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

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.


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