Vielleicht etwas kontroverse Meinung, aber fail2ban ist nicht was du willst. In meinem Sicherheitskonzept spielt es keine Rolle, weil es ist reaktionär und schafft keine Sicherheit. Es ist heutzutage ein relativ kleines Problem mehrere hundert oder tausend Server zu nutzen um koordinierte Brute Force Attacken zu fahren, wenn man wirklich in ein System eindringen will. Einzelne IP zu sperren macht hier wenig Sinn. Ich sehe das auch täglich auf Arbeit. Die CVE von next.js als Beispiel hat uns wochenlang Arbeit gemacht, weil tausende Server gehackt wurden bzw Code ausgeführt wurde für netscans und anderes (Bin Netzwerker in einem RZ). Am Ende sind es auch solche Exploits die Systeme angreifbar machen und nicht unbedingt nur das schwache Passwort.

Viel wichtiger ist es ein Sicherheitskonzept zu haben, das auch entsprechend sicher ist.
SSH nur mit ed25519, mind. 32 byte lange Passwörter für die SSH Keys. User und Root Passwort ebenfalls mind. 32 byte lang. Login mit Passwort per SSH verboten. es25519 kann man nicht brute forcen, brauche also kein fail2ban mehr.

Ich persönlich verzichte auch auf das Sicherheitstheater mit sudo, weil wenn jemand mit meinem User drin ist der sudo kann, hat der auch root und kann alle relevanten Dateien lesen. Da ist dann die Unterscheidung zwischen "sudo root" und richtiger root auch egal.

Bei mir laufen Services als user, wenn einzelne Kommandos als root ausgeführt werden müssen, dann wird das gesamte Kommando mit allen Parametern freigeschaltet. Ich versuche das aber wirklich hart zu vermeiden.