Back at the company I used to work at, all systems run SSH on an alternate port (we run it on 2022). That resolved the majority (80+%) of SSH hacking attempts right out of the gate. The majority of scripts rely on SSH being on the default port at all times.
Don't really resolve this issue all that much, just an interesting bit of info I picked up being the security guy for a web hosting company.
I too set up machines with an alternative port + keys instead of passwords. As you said it isn't a solution, but a bandaid.
What I've also done in the past with some services was to firewall off the port, have a web interface where you logged in on. The login would record your IP in a separate log file, and a script would scrape that log adding the firewall rule to allow that IP address with a TTL. You then set it so that it keeps any existing connections upon firewall reset and after say 5 minutes the port is closed down to all IP's again.
Back at the company I used to work at, all systems run SSH on an alternate port (we run it on 2022). That resolved the majority (80+%) of SSH hacking attempts right out of the gate. The majority of scripts rely on SSH being on the default port at all times.
Don't really resolve this issue all that much, just an interesting bit of info I picked up being the security guy for a web hosting company.
It is interesting :)
I teach networking and ethical hacking, so stories and anecdotes like yours are always appreciated!
I too set up machines with an alternative port + keys instead of passwords. As you said it isn't a solution, but a bandaid.
What I've also done in the past with some services was to firewall off the port, have a web interface where you logged in on. The login would record your IP in a separate log file, and a script would scrape that log adding the firewall rule to allow that IP address with a TTL. You then set it so that it keeps any existing connections upon firewall reset and after say 5 minutes the port is closed down to all IP's again.