Let the server and client share a secret. Use that secret to encrypt the UTC date (2020-09-21), and sample some decimals from the first few bits (adding 100 or so, to avoid low-ports).
You could use that mechanism to rotate ports every 24 hours. This way, the bots wouldn't be able to learn the ssh port for more than 24 hours, without the shared secret.
Sounds like fun, or an easy way to lock yourself out of a box by mistake, depending on your perspective. :)
I imagine the people who had to use these things locked themselves out all the time. :)
So yes, it's a FANTASTIC way to lock yourself out!
I think I'd sooner implement port knocking rather than port-hopping
Maybe you'd knock to get a number, and hash the number to get the real port.
Defense in depth! :)
This is THE way to go !
When I see this in practice, the first thing I check is how auth is being done and the overall security of the host. Then, I look for how they are doing SIEM because cleaner logs is a common reason and they'd be better off with a more proactive management approach.
You don't see a difference in a 2-orders-of-magnitude noise reduction when looking for attacks!?
/s
//Side note, you should never allow login as root, and you should not really allow remote password login at either, only keys
That's a minimal (read: insufficient) improvement, but if it were behind a real layer of security then it would strictly be an improvement.
> Side note, you should never allow login as root, and you should not really allow remote password login at either, only keys
I'm on board with keys, but why not allow root? If it's secured by a key, what's the harm?