I’m having MineOS login issues after moving to a fresh Bullseye install.
Here’s what I’m seeing in the terminal:
● mineos.service - MineOS (DietPi)
Loaded: loaded (/etc/systemd/system/mineos.service; disabled; vendor preset: enabled)
Active: active (running) since Sat 2021-09-11 09:14:38 PDT; 28min ago
Main PID: 683 (node)
Tasks: 11 (limit: 9354)
CPU: 14.247s
CGroup: /system.slice/mineos.service
└─683 /usr/local/bin/node webui.js
Sep 11 09:14:41 DietPi MineOS[683]: info: Starting up server, using commit: c04a177 fix misslabled class initialization (#430)
Sep 11 09:16:05 DietPi MineOS[683]: Unsuccessful login attempt for username: root
Sep 11 09:16:13 DietPi MineOS[683]: Unsuccessful login attempt for username: root
[....]
I’m using the root password, although I’ve also tried the global software password too. If it helps with troubleshooting, I installed MineOS during the initial DietPi setup process, whereas I’d previously (on Buster) installed it after the fact.
Any ideas? I can’t get past the MineOS WebUI’s login screen.
Incidentally, there’s a typo: misslabled [sic]. Where should I report that bug?
It’s fine to report it in this forum. Where exactly is the issue you found? I could have a look to DietPi code then. Or due you mean message on service output? This is a message from MineOS and I guess it would need to be reported at MineOS GitHub https://github.com/hexparrot/mineos-node/issues
Regarding the login, MineOS is using OS users to login. Means every user available on your system should work. Did you checked if login as user dietpi is working?
Coincidentally I just did test installs on Stretch, Buster and Bullseye (x86_64 VMs) and it worked well on all of them. I was able to login as root with the root users password. Since we do not touch any password related setting during the install, it is impossible that this comes from anywhere else than from the root user login.
Any progress on any of this? I moved back temporarily to my Buster-based DietPi install, then tried again tonight on the Bullsesye install after updating to 7.6.2. It’s a no go. I still can’t log in to MineOS using the root password or global software password and am seeing the same errors (“Unsuccessful login attempt for username: root”).
This was just working fine on Buster with the exact same configuration (same root/global password, same IP, etc.). I doubt that at least three of us would all be encountering the same problem if it weren’t a legitimate issue.
from DietPi side we do exactly the same installation on all platform or Debian versions. There is nothing special on Bullseye and at least for me it’s working on Bullseye ARMv6 image. As stated above, probably a challenge between Raspbian and Debian repository. Not sure if it would make sense to report it to MineOS GitHub as well as the login process is something done by MineOS directly using the user from OS.
It is strange. I was able to replicate it on x86_64 VM Bullseye. When I do a fresh install of MineOS, login works as expected with root user and its UNIX password. But when I change the password via chpasswd <<< ‘root:testing’, using that new “testing” password on MineOS does not work, also using the old one and/or restarting MineOS does not solve it. Also when reverting the UNIX password to what it was before, it does not work. A different browser also doesn’t help.
Strange also that actually none of the MineOS files has changed at that point, so I have no idea where anything related to the login password should have been stored. I also cleared all Node related cache and userdata (that I am aware of) but that didn’t help either. Even an uninstall and reinstall of MineOS does not help, so that proves that it is nothing stored MineOS wise.
Reboot, no success. Now trying to uninstall and reinstall not only MineOS but also Node itself… also doesn’t help. Resetting the VM and trying again a fresh install.
Btw, the “misslabled” word in the log is part of the commit text which represents the current MineOS version that was installed. The last change in MineOS was obviously fixing a misslabled class initialization. Also the related PR is given: https://github.com/hexparrot/mineos-node/pull/430
Fresh install + changed root user password before installing MineOS and it doesn’t work in the first place. Login with the “dietpi” user still works (I didn’t touch its password). I also tried to fake the password change being in the past:
touch -d "2 years ago" /etc/shadow
I think we need more details about how MineOS is trying to invoke the UNIX user credentials. Probably something about how these are stored or can be accessed has changed with Bullseye. On my VM this was changed last a while back, which is probably key here and may also explain why on different systems if behaves differently: Not the architecture is relevant but the time (Debian package state) when the user password has been set or changed last.
Joulinar
Can you check the timestamps of /etc/shadow on your ARMv6/7/8 systems and verify that it has been changed/set earlier on the ARMv6 image compared to the other two?
Last test: When re-setting the same password that a user had before, login breaks as well. It has definitely to do with how UNIX password info is stored and can be retrieved on Bullseye. A guess is a changed hashing algorithm with MineOS does not know yet.
restores the login ability. I tried all other (less secure) algorithms listed in:
chpasswd --help
But none of them works, only SHA512. Interesting now is that when skipping this option, the created hash in /etc/shadow doesn’t match any of the available ones. So it seems some now algorithm is used, which is not documented and not known by MineOS.
Checked the man page which says:
By default, PAM is used to encrypt the passwords.
So using the above option forces an algorithm while by default PAM is doing this, using an algorithm which is not supported by chpasswd directly. Tested on Buster, and indeed without setting the algorithm explicitly it is SHA512 by default.
And here is the changelog on PAM:
pam (1.4.0-3) unstable; urgency=medium
…
pam-configs/unix: Default to yescript rather than sha512. From a theoretical security standpoint, it looks like yescript has similar security properties, assuming (as we typically do in the crypto protocol community) that sha256 is still reasonable. However, in terms of practical resistant to password cracking, particularly in terms of valuing space complexity as well as time complexity, yescript is superior, Closes: #978553
Thanks for troubleshooting this, MichaIng and Joulinar.
I used the following command:
chpasswd -c SHA512 <<< 'root:password'
using my preferred password, and I’m now able to log into the MineOS UI as root.
Are there any serious drawbacks to using that encryption method instead of yescript until the issue is resolved in MineOS? And how does one revert back to the superior yescript once that change is made?
sha512 was the default until Debian Buster and is generally seen as secure hashing algorithm. So no, I don’t see it as real downside. Also note that this is only relevant if someone had actually read access to the /etc/shadow file to obtain the hash and then still require a high amount of computing power and time to limit the amount of brute force attempts notably. It is good to change to modern algorithms before the older ones really get weak and to cover as well high security use cases, but for sha512 and even sha256 the EOL has not yet come.
To change back to default algorithm simply call chpasswd without the -c option.
