All these resources state that /etc/ssh/sshd_config must be modified, which I can simply not allow. This shows that other people have this issue. If this is "by design" then at the very least, absolute very least, document this on the Man Page that once the MaxAuthTries has been exceeded, an account is locked out permanently until the sshd_config file is physically modified and a higher number is temporarily added.
Such behavior is not only unexpected, even if this was added to the Man Page, but also doesn't follow any Linux designs regarding lock outs. Not other lockout mechanisms react this way in Linux / Ubuntu. References Resources: Oldest resource and report of this issue is from ServerFault from 2012. How come this hasn't been resolved 13 years later? (2012?! - suggests `pam_tally2 -u <user>` which isn't a command in Ubuntu Server) https://serverfault.com/questions/415321/fix-too-many- authentication-failures (Also from 2012!) https://www.linuxquestions.org/questions/linux- security-4/sshd_config-maxauthtries-when-does-it-reset-4175423344/ Says you have to modify sshd_config: (2017 - 7 years ago) https://visser.io/2017/07/resetting-ssh-access-after-too-many- authentication-failures-for-on-google-cloud-compute-engine/ (2020 - 4 years ago) https://serverfault.com/questions/879778/ssh-logs- i-dont-understand-maximum-authentication-attempts-exceeded No answer to someone reporting this issue on RedHat forums in 2016: https://access.redhat.com/discussions/764173 Answers say you have to modify sshd_config: https://unix.stackexchange.com/questions/574090/maxauthtries-is-being- crazy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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: New 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 Issue:** - `systemctl restart ssh`, `systemctl restart ssh.socket` - `systemctl disable/enable ssh`, `systemctl disable/enable ssh.socket` - `apt reinstall openssh-server` (reinstalled multiple times) - 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` to double the `MaxAuthTries` value, logging in, and then resetting it. This is not feasible 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
