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