If you have root login enabled by default, you're using the wrong distribution. This is 2011, not 1996.
* Change the SSH port
Why are you doing this? What will you achieve by it? In what way does this reduce your overall risk of compromise, and by whom?
* Install fail2ban or denyhosts
That's the only thing out of your trifecta that should be in there. Aside from that, here's why your trifecta isn't a good move:
You're still using password authentication for SSH. Switch to public key authentication. This, combined with fail2ban or denyhosts means bots are not getting in. Period.
You aren't addressing your attack surface area - look at what information assets are exposed to the wider world and how. Once you know what your information assets are and how they can be accessed (either legitimately or unscrupulously) from the outside world you know what you have to protect and how people can get to it. That way you can focus on real countermeasures.
What about your applications? Have you checked your code to make sure you're validating input correctly? How are you protecting against SQL injection or Cross-Site Scripting? How are you handling state?
I put to you an alternative trifecta:
* Know your assets
* Know your threats
* Use appropriate measures to protect your assets from your threats.
"Why are you doing this? What will you achieve by it?"
Changing the port does not improve security. It does, however:
- dramatically reduce the noise associated with the fleet of password guessing bots that hit open SSH server daily.
- make it reasonable to assume that a password guess attempt is specifically targeting your serve, and therefor consideration for escalation and follow up.
Signal to noise ratio. Less noise make it possible to discover the signal.
> - dramatically reduce the noise associated with the fleet of password guessing bots that hit open SSH server daily.
But if you're already using fail2ban or denyhosts (as suggested in the trifecta) then you won't get that much noise anyway, and if you're only using public key auth then the noise from password guessing bots doesn't matter anyway.
> - make it reasonable to assume that a password guess attempt is specifically targeting your serve, and therefor consideration for escalation and follow up.
Unfortunately a failed authentication attempt regardless of port isn't enough to conclude that it's a targeted attack. Plenty of bots port scan common ports before running the tools to make sure they're attacking the right service. In fact some bots can do full portscans of hosts (although this is rare as it's quicker to scan for the attacks you have built in, thus you get more attack attempts in less time) - usually this is done to build a database of services, so that they can be exploited later when a new vulnerability comes out.
Regardless, as you say it doesn't improve security, there's no reason for it to be in any security-related trifecta.
* Disable root login
If you have root login enabled by default, you're using the wrong distribution. This is 2011, not 1996.
* Change the SSH port
Why are you doing this? What will you achieve by it? In what way does this reduce your overall risk of compromise, and by whom?
* Install fail2ban or denyhosts
That's the only thing out of your trifecta that should be in there. Aside from that, here's why your trifecta isn't a good move:
You're still using password authentication for SSH. Switch to public key authentication. This, combined with fail2ban or denyhosts means bots are not getting in. Period.
You aren't addressing your attack surface area - look at what information assets are exposed to the wider world and how. Once you know what your information assets are and how they can be accessed (either legitimately or unscrupulously) from the outside world you know what you have to protect and how people can get to it. That way you can focus on real countermeasures.
What about your applications? Have you checked your code to make sure you're validating input correctly? How are you protecting against SQL injection or Cross-Site Scripting? How are you handling state?
I put to you an alternative trifecta:
* Know your assets
* Know your threats
* Use appropriate measures to protect your assets from your threats.