Description of problem:
Let's get the ball rolling on this one...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
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.
Description=Dropbear SSH Key Generatior
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
Description=Dropbear SSH Server Daemon
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.