I am having this same issue on a TP-Link Archer C7 Rev2 that I just built. I also had the same issue on a Rev 5 yesterday.
Try ssh:ing into the device, changing the password (don't log off), open a new ssh/http session, and try to login.
See what the logs say, using the existing session.
2 Likes
Yeah SSH'ing gives a Permission Denied error.
I should also clarify something from my post above:
"I am having this same issue on a TP-Link Archer C7 Rev2 that I just built. I also had the same issue on a Rev 5 yesterday."
Both are using the latest firmware on the website (for their respective revisions), and both were setup to be access points with static IP's. I am not sure that it matters or not, but I figured I should mention it.
That's not what you were asked to test.
Make sure there's no other device using the same IP as your AP.
I verified that trying using a 6 char very simple password, and also tried a blank password hitting Enter directly. After I use passwd, I become unable to enter by SSH and LuCI, and no password I try works.
I did that too. I keep a session opened and try logging on another. The one I'm in keeps active and I'm able to change password on it.
Not what you were asked to test/do.
That's what I understood on the quote. I logged and kept the session active, changed password then tried to login on another session and on LuCI.
As long as I don't logoff I keep the access and can do anything, but after changing password I'm unable to make new logins.
You missed the most relevant, 2nd paragraph.
ah ok sorry
What log should I look at? how to see it?
Try dmesg 1st...
1 Like
Ok I changed password to one very simple. When I try to login it gives permission denied, for empty, wrong and right password.
dmesg prints no log for these login attempts.
It won't show up in dmesg, use logread -f then try to login from the second session.
1 Like
Mon Jan 3 18:54:49 2022 authpriv.info dropbear[4948]: Child connection from 192.168.xxxxx:49786
Mon Jan 3 18:54:53 2022 authpriv.notice dropbear[4948]: Auth succeeded with blank password for 'root' from 192.168.212.121:49786
Mon Jan 3 18:55:06 2022 authpriv.info passwd[4958]: password for 'root' changed by 'root'
Mon Jan 3 18:55:12 2022 authpriv.info dropbear[4961]: Child connection from 192.168.xxxxx:49796
Mon Jan 3 18:55:15 2022 authpriv.warn dropbear[4961]: User account 'root' is locked
Mon Jan 3 18:55:17 2022 authpriv.warn dropbear[4961]: User account 'root' is locked
Mon Jan 3 18:55:19 2022 authpriv.warn dropbear[4961]: User account 'root' is locked
Mon Jan 3 18:55:19 2022 authpriv.info dropbear[4961]: Exit before auth from <192.168.xxxxx:49796>: (user 'root', 3 fails): Max auth tries reached - user 'root'
Mon Jan 3 18:59:40 2022 user.info : luci: failed login on /admin/network/firewall/rules for root from 192.168.xxxxx
So, looks like changing the password is locking root?
Three failed login attempts...
yes, I tried until it gave up
It appears SSH honors the password, but LuCI doesn't care.
So if you have LuCI access, can you reflash the sysupgrade image for the OpenWRT version you're running.
That should preserve your config settings (except for packages you installed later) and totally re-install OpenWRT...which should clear the password.
Might also be a good opportunity to use a password manager, so you'll know exactly what was entered and saved in LuCI...and what SSH is expecting.
I tried myself to change the password with passwd logged in with SSH.
The new password worked immediately both in new SSH and Luci.
What is the output of the following?
ubus call system board
Sadly, as I said, I had tried bank password, wrong password, strong password, weak password. They all fail with same msg, on SSH and LuCI. I also tried changing password with passwd and on LuCI.
I use a custom image, so it's easy to boot the PC and patch it back. It comes with current or very recent configs and I just use rsync to bring updated ones.
I don't have issue restoring access to it, the issue is I'm leaving it with no password.
yep it never happened before. I'm leaving for work, when I get back home I'll try it.
Pure guess, but are you sure that you are using vanilla passwd from busybox? (So that you are not using shadow-utils passwd or similar?)
There has earlier been trouble with more exotic/modern password hash algorithms, so I just want to make sure that you are using the defaults.
Does you password line in /etc/shadow start normally with $1$ ?
root@router1:~# cat /etc/passwd
root:x:0:0:root:/root:/bin/ash
root@router1:~# cat /etc/shadow
root:$1$oGk.../:18699:0:99999:7:::
see e.g.
Ps. musl C library password hash options were changed a few days ago in master, so I wonder if your problems might be a fallout from that.
1 Like