There is a trade-off here. Weigh up the risks as you think is best and act accordingly, but try not to let the coolness/hacker factor of the solution affect your security decisions!
On one hand, it is clearly going to be harder for a random zombie machine to find your ssh on a non-standard port that requires knocking and a particular less usual username.
On the other hand, you're breaking from your distribution's standard installation. You increase the risk of breaking on a future upgrade. You could lock yourself out, perhaps, and there's a cost associated with this. In the worst case a distribution upgrade will fix a security hole and you'll be left with it (say for example because you modded the config file, dpkg queried it, you rushed through the prompts and it got left alone).
I accept my scenario is unlikely, but it is also unlikely that someone will crack your up-to-date machine using distribution standard ssh, a secure root password and public keys for day-to-day access.
It is far more likely that someone will access your secure machine from an insecure place with a keylogger running and get cracked that way.
1. modifying the default configuration is fine: you do this for your web server (right?) so why not sshd? in fact, sshd is simpler to configure and i cannot think of one backward incompatibility in many years. disable what you don't need, this includes bits of sshd. what's the point of a configuration file if you can't change it?
2. your point about "using distribution standard ssh, a secure root password and public keys" is a little moot in light of the debian ssh keygen bug? in this case you would have been better off with building ssh yourself (and keeping it up to date).
3. in any case, you are at most risk from your users. if they are compromised, you are also (public key or not).
I gave up on a non-standard port because I kept having to figure out configuration for programs that implicitly run ssh (darcs, git, I think there were others..)
On Mac/Linux, setting a different default port for your host in ~/.ssh/config will allow git and other applications to automatically use the new port binding on the server.
…which allows me to just use "ssh server1.example.com" and "git clone foo@server1.example.com:blah/project" to access those resources without explicitly defining the port number.
---
Edit: The standard msysgit installer for Windows may look in the same place too — I haven't tried.
Comments
There is a trade-off here. Weigh up the risks as you think is best and act accordingly, but try not to let the coolness/hacker factor of the solution affect your security decisions!
On one hand, it is clearly going to be harder for a random zombie machine to find your ssh on a non-standard port that requires knocking and a particular less usual username.
On the other hand, you're breaking from your distribution's standard installation. You increase the risk of breaking on a future upgrade. You could lock yourself out, perhaps, and there's a cost associated with this. In the worst case a distribution upgrade will fix a security hole and you'll be left with it (say for example because you modded the config file, dpkg queried it, you rushed through the prompts and it got left alone).
I accept my scenario is unlikely, but it is also unlikely that someone will crack your up-to-date machine using distribution standard ssh, a secure root password and public keys for day-to-day access.
It is far more likely that someone will access your secure machine from an insecure place with a keylogger running and get cracked that way.
1. modifying the default configuration is fine: you do this for your web server (right?) so why not sshd? in fact, sshd is simpler to configure and i cannot think of one backward incompatibility in many years. disable what you don't need, this includes bits of sshd. what's the point of a configuration file if you can't change it?
2. your point about "using distribution standard ssh, a secure root password and public keys" is a little moot in light of the debian ssh keygen bug? in this case you would have been better off with building ssh yourself (and keeping it up to date).
3. in any case, you are at most risk from your users. if they are compromised, you are also (public key or not).
Wasn't the Debian bug in OpenSSL? Building OpenSSH yourself would not do you any good there if you linked to the distribution's OpenSSL.
I gave up on a non-standard port because I kept having to figure out configuration for programs that implicitly run ssh (darcs, git, I think there were others..)
On Mac/Linux, setting a different default port for your host in ~/.ssh/config will allow git and other applications to automatically use the new port binding on the server.
My ~/.ssh/config basically looks like https://gist.github.com/78ec014f31c8a06f656b
…which allows me to just use "ssh server1.example.com" and "git clone foo@server1.example.com:blah/project" to access those resources without explicitly defining the port number.
---
Edit: The standard msysgit installer for Windows may look in the same place too — I haven't tried.
Ah that's very useful. Thanks.
I only recently realized I could abbreviate hostnames in .ssh/config.