[Bug 2094529] Re: Impossible to Reset MaxAuthTries After Lockout

[Nick Rosbrook]

Thanks for your detailed bug report.

> 1. Install the current release of `openssh-server`.

Can you please be more specific? The output of `apt policy openssh-
server` on the affected server would be most helpful.

> 3. Exceed the configured number of attempts. For good measure, I
suggest attempting 15 or 20 times.

You mention PuTTY in your bug report. Is that the specific client you
are reproducing this with? Or do you see the same behavior with openssh-
client on an Ubuntu machine?

>From an initial look and test, my understanding is that MaxAuthTries is
applied on a *per-connection basis*, and it is not persistent across
multiple connections from the same client. For example, if I continually
attempt to connect to a server with an unauthorized public key, I do not
ever exceed MaxAuthTries (because it is reset on each connection, and my
client is not continually attempting to use that key). However, if I
configure password-based authentication, and increase
NumberOfPasswordPrompts for my client, then I will eventually hit the
limit with incorrect passwords. *However*, I am allowed to try again
once I establish a new connection (i.e. when I run `ssh
ubuntu@${server_ip}` again).

> - `systemctl stop ssh && systemctl stop ssh.socket && pkill -f pam && pkill -f ssh && pkill -f ssh-agent && killall ssh && killall sshd && systemctl start ssh && systemctl start ssh.socket` (Thoroughness)
> - Rebooted client PCs
> - Verified client passwords

I wonder if the client is configured in a way that it is automatically
trying (many) incorrect credentials before getting to the correct one.
This would give the illusion that the server is storing AuthMaxTries
persistently. Debug-level logs would help answer this question. Can you
please enable debug logs for sshd by running:

$ cat > /etc/ssh/sshd_config.d/log-level.conf << EOF
LogLevel DEBUG
EOF
$ systemctl reload ssh

And then make a connection attempt from the problematic client, and
gather logs with:

$ journalctl -b -u ssh.service --since "1min ago"

Adjust the "--since" time if needed, and take care to redact your logs
if necessary.

** Changed in: openssh (Ubuntu)
       Status: New => Incomplete

** Changed in: openssh (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2094529

Title:
  Impossible to Reset MaxAuthTries After Lockout

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ---
  **Issue Report: Unable to Reset `MaxAuthTries` in OpenSSH-Server**
  ---

  I find myself increasingly frustrated as I reluctantly open this issue
  report. This specific issue is consuming precious time I simply don’t
  have. There appears to be no way to reset the `MaxAuthTries` counter
  once it has been exceeded by a client due to incorrect attempts, such
  as when PuTTY attempts to reconnect after a password change.

  In this scenario, my employee has almost full root access, except for
  the ability to modify system files and reboot the server. Despite
  numerous attempts, including verification on my part, the
  `MaxAuthTries` counter does not reset. It seems there is currently no
  mechanism to reset this counter for a specific username. I was able to
  log in as the affected user via web TTY provided by the VPS provider,
  indicating that the account itself is not physically locked.

  **Steps to Reproduce:**
  1. Install the current release of `openssh-server`.
  2. Set up an account and configure (uncomment) `MaxAuthTries` in /etc/ssh/sshd_config to any value, for example, 10.
  3. Exceed the configured number of attempts. For good measure, I suggest attempting 15 or 20 times.
  4. Attempt to reset `MaxAuthTries`. Despite consulting Google and AI resources, this task remains impossible.

  **What Was Tried to Verify This Bug / What Was Tried To Reset MaxAuthTries Without System File Modification:**
  - `systemctl restart ssh`, `systemctl restart ssh.socket`
  - `systemctl disable/enable ssh`, `systemctl disable/enable ssh.socket`
  - `apt reinstall openssh-server` (reinstalled multiple times)
  - `eval $(ssh-agent)`
  - `pam_tally2 -u <user>`
  - `pam_tally -u <user>`
  - `systemctl stop ssh && systemctl stop ssh.socket && pkill -f pam && pkill -f ssh && pkill -f ssh-agent && killall ssh && killall sshd && systemctl start ssh && systemctl start ssh.socket` (Thoroughness)
  - Rebooted client PCs
  - Verified client passwords
  - `passwd username` from another account, followed by attempting the new password on the locked-out account and IP
  - Manually logging into the server without providing automatic username and password. Still doesn't work, so it's not a password issue, it's a openssh-server lockout issue. An undocumented hard lockout mechanism with no recourse?

  **Observations:**
  - The `auth.log` shows the connection attempts, indicating this is not a firewall issue. Fail2ban did not ban the IPs, and the IP subnets are whitelisted. UFW is not installed.
  - Different usernames at different locations (different IPs) were not affected.
  - It’s astonishing that there is no way to reset this counter. Not even reinstalling `openssh-server` resolves it. This is the most shocking aspect.
  - Common suggestions online and in forums recommend modifying `/etc/ssh/sshd_config` and doubling the `MaxAuthTries` value, and unlock the affected account / IP. This is not feasible, and completely unexpected, as I cannot allow employees to modify system files.

  **Expected Behavior:**
  - It is reasonable to expect a method to reset the `MaxAuthTries` counter. While employees cannot modify system files, upper-tier personnel can perform almost any other task. I anticipate that there should be a straightforward way to reset `MaxAuthTries`, such as through service restart or `openssh-server` reinstallation. The current lack of such a method is perplexing.
  - Additionally, I’ve observed that when modifying `/etc/ssh/sshd_config` to change the port number, a server reboot or `openssh-server` reinstallation is required for the changes to take effect. Restarting the service alone does not apply the new port number. Why doesn’t restarting `openssh-server` reflect these changes? Where are these states being stored?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2094529/+subscriptions