Not sure why but the idea of port knocking always seems over complex for little benefit.
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.
At worst, the internet will just keep filling your logs with access attempts, none of which will actually accomplish anything.
I did recently decide to start using fail2ban though, not because I'm worried about someone hacking ssh, but because I wanted a centralized system that would monitor various forms of abuse (including obvious spammers).
Do not allow password logins. Do. Not.
Have a method to redact keys quickly. The advice of the article becomes irrelevant. If someone gets hold of an unencrypted/crackable private key, they'll likely also have access to the secret portnumber, knock sequence and username, so nothing much gained there.
Consider the Debian PRNG flaw from a couple years ago. As I understand it, most SSH/SSL keys generated on Debian and Debian-derived boxes over a period of about two years were (rather) easily guessable. Even if you were able to redact any compromised keys as soon as this was publicly revealed, who knows how long malicious attackers may have known about it before it was made public. If your server had port knocking enabled you would have had a bit of insulation from this attack.
http://www.fail2ban.org/wiki/index.php/Main_Page
http://denyhosts.sourceforge.net/
denyhosts has the difference that it synchronises this data amongst many hosts.
nmap -sV -p1-65000 ip
I thumbs downed the article because as a security professional we try to stress the importance of actual security rather than obscuring the problem for long term success.
Take port knocking for example, interesting idea but what a pain in the ass... just disable root and set a strong password.
Changing the port from 22 will prevent all of the automated botnet driven SSH brute force attacks, which do little more than messy up your log directories.
Best thing you can do is use SSH brute force blocking script which reports attackers back to a webapp which the security community can use to track infected hosts. example: http://danger.rulez.sk/projects/bruteforceblocker/blist.php
Fail2ban is a nice one too as it supports many services including http-auth.
also, everyone keeps talking up these scripts to stop brute forcing... two iptables rules will do this for you.
Do you have a username/password or username+certificate that a script kiddy is likely to hit in their first 10,000 attempts?
If yes, you have a much larger problem that can't be solved by port knocking or moving ssh to a different port.
If not, then you're trying to solve a problem which doesn't exist anyway.
http://danielmiessler.com/study/security_and_obscurity/
Ask yourself why, if obscurity is worthless, does every military put camouflage on its tanks?
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.
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).
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.
http://danielmiessler.com/study/security_and_obscurity/
Hint: Why do we camouflage tanks?
If you're just opening up SSH on your personal computer, you don't need every advantage you can get. Just make sure that your authentication is strong, and you'll be fine.
Difference between using usual 22 and "unusual" 24 port, 18000 attempts vs. 5 attempts over one weekend.
Seems to weed out script kiddies quite quickly.
Personally, I don't see anything wrong with having 3 locks on the door:
ACl
port knocking
nonstandard port
Of course, one still wants to have a difficult to pick key after all that.
It's awesome, gets rid of a bunch of brute forcing ips that you see in your secure.log.
No, it doesn't. Running a port scan and finding your "hidden" SSH port takes very little time.
Placing your SSH port behind a hosts.allow restriction ensures that you've reduced your attack surface to only the hosts (or networks) you've permitted.
Better still, set up OpenVPN, use its HMAC[1] support to stop unknown users early, and don't expose any other daemons to the internet.
[1] http://openvpn.net/index.php/open-source/documentation/manua... (See --tls-auth file option).
To quote:
The rationale for this feature is as follows. TLS requires a multi-packet exchange before it is able to authenticate a peer. During this time before authentication, OpenVPN is allocating resources (memory and CPU) to this potential peer. The potential peer is also exposing many parts of OpenVPN and the OpenSSL library to the packets it is sending. Most successful network attacks today seek to either exploit bugs in programs (such as buffer overflow attacks) or force a program to consume so many resources that it becomes unusable. Of course the first line of defense is always to produce clean, well-audited code. OpenVPN has been written with buffer overflow attack prevention as a top priority. But as history has shown, many of the most widely used network applications have, from time to time, fallen to buffer overflow attacks.
So as a second line of defense, OpenVPN offers this special layer of authentication on top of the TLS control channel so that every packet on the control channel is authenticated by an HMAC signature and a unique ID for replay protection. This signature will also help protect against DoS (Denial of Service) attacks. An important rule of thumb in reducing vulnerability to DoS attacks is to minimize the amount of resources a potential, but as yet unauthenticated, client is able to consume.
--tls-auth does this by signing every TLS control channel packet with an HMAC signature, including packets which are sent before the TLS level has had a chance to authenticate the peer. The result is that packets without the correct signature can be dropped immediately upon reception, before they have a chance to consume additional system resources such as by initiating a TLS handshake.
Once the correct port is located, you're in precisely the same situation that you are if you hadn't moved ssh.
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?
Do not under estimate the zerg. Although ssh servers on different ports are "harder" to find, they are still not invisible. Try changing your banner, using 'port knocking', TCIP fingerprint spoofing, and other obfuscation techniques. Nothing is 100%, but you can still have really secure boxes. Proper admins are your best line of defense.
OpenVPN is capable of providing a much, much smaller attack surface than OpenSSH (see http://news.ycombinator.com/item?id=1665773), and can be run entirely chroot'd and setuid such that even if an attacker does compromise OpenVPN, they can not necessarily gain further access.
There seems to be a prevailing lack of understanding that bad passwords are not the only concern when using SSH. The daemon itself may be vulnerable to exploit (and in the past, it has been).
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?
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.
Now I get to drive out to the datacenter. Whoops.