Wrong password on SSH system locks up

Creating a bug report/issue

If I enter an incorrect password on an ssh connection attempt, and do this multiple times (trying different passwords from 1Pass) the server locks up. Any new ssh attempt never responds, and all DNS (Pi-hole) is suspended until I hard reboot the device. I’m using OpenSSH as I do on many other Amazon and Ubuntu linux servers, and only see this reaction on DietPi.
I would love to know any tips on what to check or change, other than entering the right password of course :wink:

Required Information

  • DietPi version | v8.13.2
  • Distro version | bullseye 0
  • Kernel version | Linux 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux
  • SBC model | RPi 3 Model B+ (aarch64)
  • SD card used | SanDisk ultra

Additional Information (if applicable)

  • Software title | Pi-Hole
  • Was the software title installed freshly or updated/migrated? - No been in place for > 1 year
  • Can this issue be replicated on a fresh installation of DietPi? - have not attempted

Steps to reproduce

  1. ssh to server, enter wrong password multiple times
  2. retry ssh and it does not respond

Expected behaviour

  • Connection reset and ability to retry ssh as long as not hitting any throttled iterations (no fail2ban installed - not sure why the system locks up and does not just prevent immediate retry, such as wait 5 minutes, etc.

Actual behaviour

  • consecutive wrong passwords (4-5?) receive permission denied and connection terminated. Device becomes unusable until hard power reboot, all services seem to be suspended/hung.

Extra details

Did you probably installed fail2ban?

At least our default installation did not contain such feature.

I must have I do see a fail2ban.log but it’s empty. I use that on other servers, but don’t recall this effect as a result of a wrong password. Even so, F2b should have zero effect on the other servers from that bad ssh attempt. But every single time I do this (1/5 maybe when trying to update pihole) it locks up the device.

It should block your IP in general. Just remove F2B and test again.

1 Like

Removed fail2ban and that seems to have been the issue. Makes sense on banning the ip, but not hosing the server and all services. I’ll look for alternatives. Thanks for the help

That’s how F2B is designed to work. It’s going to block your client IP completely and not just single services.

However other clients should be able to continue to work.

1 Like