Yeah, at least as far as my logs go, just disabling password login seems to cover a superset of the attacks that changing ports would cover, so I don't see much reason to avoid the default port. Every automated attack I've found in my logs is: 1) on the default port; and 2) a password attempt. It seems the recommendation here is to change #1, but to me just changing #2 is easier, and has some other benefits as well. The main place I could see an argument for #1 is if you run a large multiuser server, where it's quite possibly easier to explain to your users how to use a nonstandard ssh port, versus trying to explain to them how to use ssh keys.
Hostgator's nonstandard port for hosting is my biggest complaint about their service, especially because I cannot set up key-based authentication, and I have to ad -e 'ssh -p 2222' to my rsync statements.
But if I'm being honest, back when I signed up with them keypairs would have been a little more difficult than working out that option for rsync.
Comments
Yeah, at least as far as my logs go, just disabling password login seems to cover a superset of the attacks that changing ports would cover, so I don't see much reason to avoid the default port. Every automated attack I've found in my logs is: 1) on the default port; and 2) a password attempt. It seems the recommendation here is to change #1, but to me just changing #2 is easier, and has some other benefits as well. The main place I could see an argument for #1 is if you run a large multiuser server, where it's quite possibly easier to explain to your users how to use a nonstandard ssh port, versus trying to explain to them how to use ssh keys.
Hostgator's nonstandard port for hosting is my biggest complaint about their service, especially because I cannot set up key-based authentication, and I have to ad -e 'ssh -p 2222' to my rsync statements.
But if I'm being honest, back when I signed up with them keypairs would have been a little more difficult than working out that option for rsync.