Unfortunately people have taken this a little too seriously, I wrote this as a joke/PoC of silly "Security by obscurity" methods, and yet people are for some reason viewing this as a serious solution...

I recognize that this is a joke, in the words of the OP. However I think SPA-type port knocking is completely legitimate, and I second the use of fwknopd. I depend on fwknopd a lot, so if that is not secure idea, I would like someone to point that out to me. NOTE that fwknopd does not depend on expecting a client to connect to a short sequence of different port numbers. That is not what fwknopd does, at least not the latest fwknopd. Instead, fwknopd listens for an encrypted packet on a specified port, which it will not acknowledge. The firewall does not allow the packet through, technically speaking. But fwknopd recognizes the arrival of the packet by scanning logs when the firewall drops the packet and logs the dropped packet. etc. etc. If you know this type of fwknopd deployment and don't think it is a good idea, please comment.

Again, I am not taking the OP seriously, but I do take seriously that people either don't know about fwknopd, or maybe, don't think that is good security (in which case I want to hear from you).

Correct me if I am wrong here, but would the following changes to SSH give you the same result:

Change protocol from TCP to UPD and port from 22 to 62201.

Remove greeting.

If first message is not the correct password, do not send a reply.

If everyone used this, do you think SSH would become more secure and eliminate password scanners? Personally I think that if ssh took in a fwknopd patch and used that as default, any benefit you see now would disappear. I also suspect that logging every UDP package to 62201 would be a bad idea, probably worse than logging every failed attempt on TCP port 22.

Ssh does a fingerprint verification and establishes a secure channel before it does the password exchange. Avoiding replay attacks can be a challeng as well. Putting strong authentication in a single packet is deceptively nontrivial. It can be done, but at that point you'd be reimplementing Fwknopd. Additionally, Fwknop can protect more than just ssh, and do fancy things like providing access to a machine without a public IP address.

Disclaimer: I'm one of the Fwknop devs. =)

People get their wires crossed about port knocking because it doesn't add much security when I'm trying to find a way to hack you. It does add something when I'm trying randomly to find you to hack.

They make the valid criticism of the first case while you argue the second and somehow the arguments miss in the middle.

If you do not have the ability to eavesdrop on the network between my client and my server, then port knocking is essentially unhackable. Port knocking only fails when the malicious party can monitor the network traffic. This is a valid concern, and I would never say that port knocking by itself is all the security one needs. It does however completely block all regular "outsiders" from ever being able to even open a connection to sshd.

If I require 5 ports to be hit in sequence, and blacklist IPs that hit unknown ports, it is extremely unlikely you will ever connect. Now if someone on my local network, at my ISP, or at my hosting provider sniffs my traffic to determine a static knocking sequence... good for them. They're the one unauthorized person who can connect to sshd, without a valid ssh key to authenticate with.

It's a reality that most businesses are not going to invest in setting up a network that cannot be accessed from the internet at large. For such setups, a little bit of obscurity via something like port knocking to prevent every single port scanner in existence from discovering your sshd server must be better than nothing at all.

> blacklist IPs that hit unknown ports

so what happens when someone hits an unknown port on your system from every IP on the internet?

You reject all packets from "bad IPs" for a period of time. 5 minutes, 30 minutes, whatever. If you're in a position to spoof IPs and you manage to spoof one I need to connect from (or I make a mistake and get myself blacklisted), it's a temporary inconvenience.

That, and having out-of-band access to the server always helps. ;)

How does that not add security? If you use a secret token or some authenticated website for opening the port how can an attacker easily circumvent this?

It does seem a little silly, the readme does also mention it was written as a joke.

Was looking at ways to decrease logspam from ssh login bots some years ago, port knocking seemed like the most elegant solution. I ended up simply moving ssh away from port 22, the logspam disappeared.

I've used fail2ban in other setups, it also has the advantage of being easy to integrate with other systems such as wordpress, sftp/ftps, nginx, apache.

"I don't understand why this is seen as acceptable, yet port knocking is derided every time it's brought up."

I have been in this business for a long time and I still look very fondly at port-knocking as a thing that genuinely makes things better.

Almost zero complexity added, super stable knockd daemon, and does a single, simple thing very, very well.

I love port knocking, I love using it, I love the idea of it, and I wouldn't build a server without hiding sshd (and others) behind a knock.

All criticism of port knocking (weirdly) assumes that you also disable all other forms of security and that you rely solely on port knocking, which of course is false.

It is true that port knocking adds just a marginal additional amount of security, but it's still additive and it's still a high return on the (very low) complexity and maintenance.

If you chain two sshd and have a certificate on the first and password on the second, the second sshd will have the exact same number of attempts as your current setup.