search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.89k stars 498 forks source link

DietPi-Software | Dropbear: Password timeout via chage not respected #3233

Open CupOfTea696 opened 4 years ago

CupOfTea696 commented 4 years ago

ADMIN EDIT

Workaround: Replace Dropbear by OpenSSH server

dietpi-software install 105

Creating a bug report/issue

Required Information

Additional Information (if applicable)

Steps to reproduce

  1. ssh dietpi@192.168.x.x
  2. sudo -i
  3. chage -d 0 dietpi
  4. exit
  5. exit
  6. ssh dietpi@192.168.x.x

Expected behaviour

After entering the password when ssh-ing back into DietPi (step 6), a prompt should appear informing the user that the password needs to be changed immediately.

Actual behaviour

It just logs in normally, and the user has access to the system without having to change their password.

Extra details

I'm trying to force a password change after install via the Automation_Custom_Script.sh, so that the user immediately needs to change the password after logging in to the DietPi for the first time. While the password does seem to expired when checking with chage -l dietpi, the user never gets prompted to change their password. I used the same script when I set up my RPi 4, and I did get the password change prompt as expected there. 

$ chage -l dietpi
Last password change                    : password must be changed
Password expires                    : password must be changed
Password inactive                   : password must be changed
Account expires                     : never
Minimum number of days between password change      : 0
Maximum number of days between password change      : 99999
Number of days of warning before password expires   : 7
MichaIng commented 4 years ago

@CupOfTea696 Many thanks for your report.

I'll try to replicate....

Confirmed:

Nov 18 21:40:18 VM-Buster chage[1182]: changed password expiry for dietpi Nov 18 21:40:23 VM-Buster dropbear[1185]: Child connection from 192.168.178.21:49865 Nov 18 21:40:27 VM-Buster dropbear[1185]: Password auth succeeded for 'dietpi' from 192.168.178.21:49865 Nov 18 21:40:36 VM-Buster dropbear[1185]: Exit (dietpi): Exited normally

Issue with Dropbear? But this must be a PAM-related thing, hence Dropbear should not be able to skip this.

On the other hand, su asks for the password change:

root@VM-Buster:~# su dietpi
You are required to change your password immediately (administrator enforced)
Changing password for dietpi.
Current password:
New password:
Retype new password:
Password unchanged
New password:
Retype new password:
You must choose a longer password
New password:
Retype new password:

Switching to OpenSSH:

login as: dietpi
dietpi@192.168.178.30's password:
You are required to change your password immediately (administrator enforced)
Linux VM-Buster 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Nov 18 21:48:06 2019 from 192.168.178.21
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for dietpi.
Current password:

Since having the need to change ones password regularly is a basic part of security concept, I would call this even a bug which should be reported to Dropbear dev, probably to passwd devs or related to block login with expired password if no immediate change is forced. I have no deep insights, probably this limitation is well known and accepted, but it does not hurt to throw it back into discussion.

Workaround: Replace Dropbear by OpenSSH server

dietpi-software install 105
CupOfTea696 commented 4 years ago

It's weird, though, because I think I was using Dropbear on my RPi 4 as well? I'll check later.

MichaIng commented 4 years ago

@CupOfTea696 Maybe you logged in via local console instead of SSH on RPi4? There it works. Since both are Buster-based and I tested on x86_64 Buster VM, it is pretty sure the same issue on all Buster-based systems when logging in via Dropbear SSH.

I just mailed Matt (Dropbear), lets see what he thinks about it.

CupOfTea696 commented 4 years ago

Maybe you logged in via local console instead of SSH on RPi4? There it works. Since both are Buster-based and I tested on x86_64 Buster VM, it is pretty sure the same issue on all Buster-based systems when logging in via Dropbear SSH.

I'm gonna double check just to make sure, but that might've been the case.

MichaIng commented 4 years ago

@CupOfTea696 Okay, so indeed the chage password timeout/change is a PAM feature, and if/how much PAM is used/supported or not, is an optional thing, hence it can be completely avoided, e.g. see the OpenSSH UsePAM option, which if set to "no" should as well not send password change requests anymore.

Dropbear has limited PAM support, password timeout/reset is not included, and more importantly Debian APT repo builds have Dropbear PAM support not enabled at all: https://buildd.debian.org/status/fetch.php?pkg=dropbear&arch=amd64&ver=2019.78-2&stamp=1564266264&raw=0

configure: Disabling PAM

But just the same day of my conversation with Matt, a patch was added via mailing list to add exactly this feature:

When this has been added, we could open a request to Debian to enable PAM support for their builds. I can imagine that the missing password change dialog was a reason to disable PAM support, since, if I understood correctly, otherwise, when the password has expired, login via Dropbear is not possible anymore at all, which of course means that users can lock themselves out on headless systems.

CupOfTea696 commented 4 years ago

@MichaIng thanks for all the effort you're putting into this getting in touch with external dependencies!