Dropbear does not set DBUS_SESSION_BUS_ADDRESS in SSH sessions

[Hosh]

Creating a bug report/issue

Hi I'm trying to run a systemd unit as the dietpi user but I'm struggling to get anything from systemctl with the --user flag.

Required Information

dietpi@DietPi:~$ cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=7
G_DIETPI_VERSION_SUB=3
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
dietpi@DietPi:~$ cat /etc/debian_version
10.10
dietpi@DietPi:~$ uname -a
Linux DietPi 5.10.17-v7+ #1421 SMP Thu May 27 13:59:01 BST 2021 armv7l GNU/Linux

Additional Information (if applicable)

• Systemd
• Can this issue be replicated on a fresh installation of DietPi? Not sure.

Steps to reproduce

1. Edit /boot/dietpi.txt and set AUTO_UNMASK_LOGIND=1
2. unmask/enable/start systemd-login: systemctl unmask systemd-logind.service && systemctl enable systemd-logind.service && systemctl start systemd-logind.service
3. Run systemctl --user as non-root user

Expected behaviour

• It should give me systemctl output

Actual behaviour

Getting the error:

Failed to connect to bus: No such file or directory

Extra details

dietpi@DietPi:~$ grep UNMAS /boot/dietpi.txt
AUTO_UNMASK_LOGIND=1

dietpi@DietPi:~$ sudo systemctl status systemd-logind | grep Active
   Active: active (running) since Fri 2021-07-23 10:19:51 BST; 14min ago
dietpi@DietPi:~$ sudo systemctl status systemd-logind
● systemd-logind.service - Login Service
   Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled)
   Active: active (running) since Fri 2021-07-23 10:19:51 BST; 14min ago

dietpi@DietPi:~$ systemctl status --user
Failed to connect to bus: No such file or directory

[Hosh]

One thing I forgot to mention, I've tried rebooting after updating the /boot/dietpi.txt but still no luck.

[MichaIng]

Many thanks for your report.

Please try to install dbus for this:

apt install dbus

[Hosh]

Thanks for the quick response! dbus is already installed.

dietpi@DietPi:~$ sudo apt install dbus
Reading package lists... Done
Building dependency tree
Reading state information... Done
dbus is already the newest version (1.12.20-0+deb10u1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

[MichaIng]

Ah, and it is running as well?

systemctl status dbus
systemctl start dbus

I'll try to replicate.

[Hosh]

Yep!

dietpi@DietPi:~$ sudo systemctl status dbus
● dbus.service - D-Bus System Message Bus
   Loaded: loaded (/lib/systemd/system/dbus.service; static; vendor preset: enabled)
   Active: active (running) since Fri 2021-07-23 10:19:51 BST; 20min ago

dietpi@DietPi:~$ sudo systemctl enable --now dbus
Synchronizing state of dbus.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable dbus
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.

Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

dietpi@DietPi:~$ systemctl status --user
Failed to connect to bus: No such file or directory

[MichaIng]

Ah, to register user sessions, the following is required as well:

apt install libpam-systemd

Logout/login and the session should be registered.

[Hosh]

That appears to have been already installed too

dietpi@DietPi:~$ sudo apt install libpam-systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
libpam-systemd is already the newest version (241-7~deb10u7+rpi1).
libpam-systemd set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

[MichaIng]

I recognised that it does not work from SSH sessions but only from regular login sessions on local console. Via SSH a workaround is to login as root but then run the login command to login as dietpi. I'll check back what the reason for this is.

Within the SSH session, $DBUS_SESSION_BUS_ADDRESS is not set automatically.
... ahh, Dropbear has limited PAM support, I think this is the reason. Trying with OpenSSH.

[MichaIng]

Jep that's it, Dropbear is the "culprit" as PAM support is very limited. You can switch the SSH server via dietpi-software and on new unprivileged SSH sessions, the missing variable is set automatically and systemd --user works.

[Hosh]

Awesome thank you! I do prefer Dropbear so I'll keep it like that and just su as other users. Much appreciated. I'll changed the title to reflect the issue better, but otherwise this sounds like this might be an upstream fix. I'll leave it for you to close if it's something that can't be addressed.

[MichaIng]

I reported it at: mkj/dropbear#132
Depending on how large the support implementation is, it might stay a limitation of Dropbear intentionally, but let's see. I remember a similar case with missing support for "chage" password rotation, also due to missing support for the related PAM module. A patch for this has been sent already, actually, but seems to not have been merged until today: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2019q4/002175.html
The changed/added code lines are manageable: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2019q4/002174.html

[MichaIng]

I'll mark this as closed. Request can be followed or pushed upstream, see links above.