SSH password auth suddenly stops working for admin user

[Samosa]

I lost internet connectivity while moving my Proxmox box and forgot to plug the network cable back in. I SSHed into the router and noticed I could not ping bbc.co.uk, so I rebooted the router and retraced my steps. I then realised the network cable was not connected, and once I plugged it back in the connectivity issue was resolved.

After that, I wanted to check something else on the router but found that I could no longer SSH into it, even though I was 100 percent sure I was using the correct username and password.

I tested the same username and password via the web GUI and that worked fine. I was also able to SSH into the router from Proxmox without any issues. However, when I tried to SSH from my PC, I consistently received an invalid user error.

Posting this in case it helps someone else, because this one was very confusing to debug.

Router: GT-AXE16000
Firmware: Asuswrt-Merlin 3006.102.6_0
SSH daemon: dropbear
Single admin user.

Symptoms​

From Windows (PuTTY / OpenSSH), SSH fails with “wrong password”, then eventually:

dropbear: Bad password attempt for 'myuser'
dropbear: Exit before auth: Max auth tries reached - user 'myuser'
dropbear: Exit before auth: Max auth tries reached - user 'is invalid'

However, from the router itself or internal connections:

dropbear: Password auth succeeded for 'myuser' from 192.168.1.1
dropbear: Password auth succeeded for 'myuser' from 192.168.1.25

Same username
Same password
Same router
Different result depending on source

Right before this started happening, the router had a large NTP time correction:

ntpd: Initial clock set
crond: time disparity of 1029315 minutes detected

After that point, Dropbear starts rejecting SSH password logins from Windows and eventually treats the admin user as “invalid” for remote SSH.

This makes it really confusing because:

• GUI login continues to work
• Local SSH continues to work
• Some SSH clients still work
• Windows clients fail consistently

At first it looks like a Windows or PuTTY issue, but it isn’t.

It looks like after uptime events / NTP time jumps / service restarts, Dropbear can get into a state where password SSH auth breaks for the admin user from some clients, even though credentials are correct and still work locally and via GUI.

I believe this was triggered by logging in before the router had internet connectivity. SSH password auth worked while the clock was still wrong. Once WAN came up, NTP corrected the clock with a very large jump, and after that SSH password auth from some clients stopped working. Logs show the NTP correction immediately before Dropbear started rejecting the admin user. This looks like a time-jump related auth state issue rather than a client or password problem.

Not sure if this is expected behaviour or a bug, but posting in case it helps someone else down the line as I've seen this happen to me frequently.

After a reboot, I was able to successfully SSH into the router again from the PC that previously couldn’t log in.