Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

24hr password reset still occurs if password updated manually #142

Closed
eenblam opened this issue Jul 11, 2018 · 7 comments
Closed

24hr password reset still occurs if password updated manually #142

eenblam opened this issue Jul 11, 2018 · 7 comments

Comments

@eenblam
Copy link
Member

eenblam commented Jul 11, 2018

Excerpt from meeting

  • juul - not formally logged, but seems like there's no documentation on the 24 hour password reset bug with autoconf.
    ** cronjob runs every 24 hours
    ** Idea: log in before then and change password. Otherwise, cronjob changes it for you.
    ** Problem: If you don't remove the cronjob when you change your password, it just changes it again to something you don't know.
    ** eenblam - let's just fix that tonight.
    ** juul - have a tiny script for installing your ssh public key onto a node to bypass these quirks https://gist.github.com/Juul/726d85b429b394e2bdde375ef7de2e71
@gobengo
Copy link
Contributor

gobengo commented Jul 11, 2018

crontab: https://github.com/sudomesh/sudowrt-firmware/blob/master/files/etc/crontabs/root

This is what cron runs: https://github.com/sudomesh/sudowrt-firmware/blob/master/files/opt/mesh/pw_reset

@Juul noted that the crontab is set to run at midnight. We dont' think it's actually wwaiting 24hrs...

@gobengo
Copy link
Contributor

gobengo commented Jul 11, 2018

I suggested it would be a good design goal to have these scripts that run via cront not rm files when they run. Instead, they could create a file that's like '/opt/sudomesh/thing-did-run'. And then the script that runs on cron gets surrounded by a big if ! [ -f /opt/sudomesh/thing-did-run ] (if the file doesn't exist, go do some work and then create the file. Subsequent runs would not go down the if statement path. But nothing would be getting deleted, so debugging later wouldn't be so hard (no one would destroy evidence).

@Juul
Copy link
Member

Juul commented Jul 11, 2018

Here's a proposed fix in the form of an edit to /opt/mesh/pw_reset:

#!/bin/sh

DEFAULT_ROOT_PWHASH="$1$0gxKX05m$amoqWHXrWF/IwR/ZxGWs.0"
COUNTER_FILE=/opt/mesh/pw_counter

if [ ! -f "$COUNTER_FILE" ]; then
  echo "0" > $COUNTER_FILE
fi

COUNTER=$(cat $COUNTER_FILE)

# This script is run every hour and increments a counter file
# until it reaches 24.

# Don't run this script if it's been less than 24 hours
if [ "$COUNTER" -ne "24" ]; then
  echo $(($COUNTER + 1)) > $COUNTER_FILE
  exit
fi

if grep $DEFAULT_ROOT_PWHASH shadow; then
    # if the `passwd -d` command doesn't work
    # sed -i.old 's/^root:.*/root:*:16031:0:99999:7:::/' shadow
    passwd -d root
    echo "password deleted, to set new password run, 'passwd username'" >  /root/pw_reset_succeeded
else
    echo "password was manually changed. doing nothing"
fi

# remove this cronjob
sed -i '/pw_reset/d' /etc/crontabs/root

Every time the router is on when the hour changes (e.g. exactly 6:00 pm, exactly 7:00 pm) a counter is increased in the file /opt/mesh/pw_counter and when it reaches 24 it will remove the root password but only if the root password hasn't been changed by the user.

Question: In case the password isn't changed, and no ssh keys have been added to authorized_keys, after 24 hours should we install an ssh key so we can remotely reset the password for people?

Warning that I haven't actually tested the above on a sudowrt router yet.

@Juul
Copy link
Member

Juul commented Jul 11, 2018

Oh and for the above script change to work you will have to change /etc/contabs/root/ to:

*/1 * * * * /opt/mesh/retrieve_ip
0 * * * * /opt/mesh/pw_reset

@bennlich
Copy link
Collaborator

@Juul I like the password reset script change. 👍

@gobengo I like the idea of not destroying evidence. Wondering if we can do it with fewer moving parts and unexpected behaviors (e.g. when deleting the "this_thing_happened" file, which could easily look like cruft, and accidentally enabling some sleeping tasks). What about leaving a commented version of the cron job in place, with an additional line of explanation. Like:

*/1 * * * * /opt/mesh/retrieve_ip
# pw_reset job below was canceled because root password was configured manually. good job node admin.
# 0 * * * * /opt/mesh/pw_reset

paidforby pushed a commit that referenced this issue Aug 6, 2018
@paidforby
Copy link

I think I've addressed the issue with a lightly modified version the script suggested by @Juul . Tested on a virtual machine, and currently testing on an actual node (with an actual build of the firmware!). passwd -d appears to work and is a much better way of reseting passwords, good thinking! This password reset thing was a bit of an after-thought amongst all the autoconfiguration craziness. Thanks for the input everybody!

@bennlich
Copy link
Collaborator

bennlich commented Aug 7, 2018

❤️❤️❤️ cool that it works with the admin password now too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants