[akerl_]

There are a number of controls available for pretty much every threat model, so I’m not sure what you’re claiming about my point that using an non-privileged port adds risk to the system that would need to be accepted or dealt with.

[raesene6]

So to elaborate. Many Internet facing systems are application servers (e.g. web servers). They typically have very few local users, administrative/Ops staff are the primary users.

At that point an attack requiring the ability to execute arbitary code on the host as a local user is possibly less relavant as, if an attacker is in that position, they likely have a number of other options to further their goals.

The reason I made the comment about alternate controls, is that the original discussion and point I was making revolved around Internet focused attackers, rather than local attackers, so it's not too surprising that I didn't try to cover that case :) No sinister intent, honest!

Heck however if we want to then lets theorize that I can just use some form of firewall to port forward the high port that's presented externally to 22/TCP internally to get the best of both worlds, both a less visible external service and an internal port that requires root to bind.

[akerl_]

Gotcha. All valid points, and I’m a big fan of firewall-based port rerouting like you describe.

I agree that an attacker who gets code exec on an app server is in a pretty fun spot already, and has a lot of different paths to escalate/persist/etc that don’t involve misuse of your ssh daemons port.