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.
Should probably branch this off into a new thread now that the login issue has been identified, but I’m unable to launch/create any servers with MineOS under Bullseye. They start and then stop a few seconds later. I first tried running the built-in version of Java, then tried with different versions (e.g., 16.0.2, 17-aarch64), but nothing’s working. Would report the logs messages/errors, but I’m still learning how to view log output using the command line.
Here’s what I’m seeing with the “systemctl status mineos” command:
I’m also having the same issue by not able to login to MineOS web interface.
If done a reinstall and have done a reset but it still did not worked.
Im using an x64 image for PC and a have changed the root and dietpi password. I’ve tried the default and my changed password and it did not worked as well.