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

[Launchpad Bug Tracker]

[Expired for openssh (Ubuntu) because there has been no activity for 60
days.]

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

-- 
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:
  Expired

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