Works for a lot of other ports too, but ssh is the obvious one.
The substantive difference, though, is that port knocking can be used to hide the service entirely, rendering you safe (mostly) from 0day attacks, DoS against a specific service, etc. It can also be use to make things that shouldn't be on the Internet (say, an RDP route to the CEO's computer) a little safer. Still, though, it's not like VPNs are very difficult to use...
The worrying thing in this report though is how many hosts seems to be running ancient (now unsupported) versions such as the stock variant from Debian 4. I bet most of those hosts have no key-based auth and easily guessed passwords too...
From the description:
This program is called by /etc/hosts.deny whenever someone connects to port 22. Unless they type in a plaintext password or type the wrong password, they get an ssh-compatible error message, and a syslog message is generated. If they type in the right password, they are added to /etc/hosts.allow, and their next connection will reach the real sshd.
I'm much more in favour of adding increasing delays for password abuse in ssh.
* Disable root logins (require su/sudo)
* Disable password logins (require public keys)
* Run Denyhosts, to block IP addresses that have too many repeated failed login attempts.
* Use Jumphosts (AKA Bastions). One (or a few) servers that listen to ssh from the open Internet and have no private keys stored on them (use key forwarding). All other servers only listen to ssh from an internal network interface the Jumphosts are also on, or from the Jumphosts IP address directly.
With jumphosts, though, you can run denyhosts, redirect to tarpits, or other clever things, and not effect performance on your other servers.
I think the motivation to use jumphosts is to minimize the surface area of your other servers as much as possible. Each daemon on each server listening for incoming connections is a liability. If an sshd exploit is found (unlikely as that is), bots that mass scan and find my ssh ports and connect won't be able to delete any production files (right away, at least) if all they gain access to is my jumphost and not one of the prod db servers.
But having a script like denyhosts or fail2ban that analyzes auth logs for IPs to block requires memory for the interpreter running the script, as well as however much of the log gets read into memory.
Blocking external ssh connections can avoid that performance hit, however large or small it ends up being.
It's a client/server thing, so you have to have the server running on the PC you intend to connect to (like when using ssh).
Never used it in any other way than with the CLI and not with every server I admin or use as there's other best practices also mentioned in the thread that are typically good enough without throwing in port knocking like:
https://news.ycombinator.com/item?id=6384313 (and the child reply)
https://news.ycombinator.com/item?id=6384418
https://news.ycombinator.com/item?id=6384457
Most things you can just use knocking and connect with ssh forwarding/proxy and tunnel everything through it like DB clients, IDE connections instead of having a bunch of ports open to internet. Assuming you don't kill the connection, then you can keep reusing it as a tunnel for anything else until rebooting or losing internet connection.