Public bug reported:
---
**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?
** Affects: openssh (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
- Certainly! Here’s a polished and refined version of your issue report:
-
---
-
**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?
--
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
