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!<p>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.<p>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).<p>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.<p>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.
Wouldn't it be much easier to just restrict access to keyfiles and block anyone who fails more than 3 attempts?<p>Not sure why but the idea of port knocking always seems over complex for little benefit.
Step 1) Setup OpenVPN. Step 2) Block ssh access using iptables or equivalent from all but the VPN connections and one or two trusted IPs (the latter just in case you need to do OpenVPN maintenance). Back in the day, you would have had a separate network for administration. Simulate that with OpenVPN.
For anyone who doubts the merits of obscurity for security:<p><a href="http://danielmiessler.com/study/security_and_obscurity/" rel="nofollow">http://danielmiessler.com/study/security_and_obscurity/</a><p>Hint: Why do we camouflage tanks?
1 and 2 seem to me to be par for the course when setting up a server that you want to be secure... Only allow logins with keys, choose a high port that's not usually scanned, and only allow specific users to log in (law of least privileges).<p>Is 3 really that necessary? Are there often cases where an up-to-date ssh daemon gets cracked even though it is on a high port and allowing only public key logins of specified users with a small number of retries?
I'm not familiar with the bleeding-edge practices for securing a server, I just use techniques like the ones in the article, but shouldn't there be a more RFC-friendly approach to locking down a server?<p>For instance, instead of this irregular "knock" routine, which is a fuss to implement, why can't there be a standard protocol for requesting firewall access? There's a standard for punching holes in local firewalls to open external ports, so why can't the same thing be applied in reverse to remote hosts?<p>With a proper access control mechanism, ssh-key driven, LDAP-backed or otherwise, it should be possible to send a packet to the remote firewall with enough information to verify identity and open the port as required. That would prevent scan attacks from working because none of the probes would be properly signed and the host port would appear closed.
I made a clitd script I back when I had a box set up at highschool. If anyone tried to connect to standard tcp services that I decided were not supported (time/port 7 and such), I would add their subnet to hosts deny for a day. It was pretty useful for fending off attacks that pre-empted with a port scan.
Point and laugh: I just locked myself out of a production machine (a very, very minor production machine that serves almost no traffic) by changing the sshd port number without first poking a hole in the firewall.<p>Now I get to drive out to the datacenter. Whoops.
I'd like to remind people too to use DenyHosts: <a href="http://denyhosts.sourceforge.net/" rel="nofollow">http://denyhosts.sourceforge.net/</a><p>It's awesome, gets rid of a bunch of brute forcing ips that you see in your secure.log.
Conclusion
You've seen three ways of hardening SSH access to your machine: modification of sshd configuration parameters, selecting which users can log in by means of PAM, and use of port-knocking sequences to hide the existence of SSH access. Although I mentioned that there is no way to secure fully any machine, adding these three layers will make your server more than just a little safer.