You have a Linux server, SSH on port 22 and a log full of strangers trying passwords. Somebody on the team says: “Just port knock it.” Two weeks later you are explaining to a new hire why they have to ping three ports in order before they can log in. It is a clever trick. Whether it earns its place depends on what you expect it to do.
What port knocking is
Port knocking keeps a service port closed by default. A client sends connection attempts to a pre-agreed sequence of ports, for example 7000, 8000, then 9000. A daemon watching the traffic recognises the sequence and tells the firewall to open the real port, usually SSH, for the source address that knocked. Everyone else still sees a closed or silent port.
The point is concealment. A scanner that sweeps your address finds nothing on port 22, so there is nothing to attempt a login against. That is the same logic behind how attackers find open ports: a port that gives no answer never makes the shortlist.
- 1Port closedThe firewall drops SSH traffic
- 2Client knocksSends the secret sequence
- 3Daemon checksMatches the sequence
- 4Port opensFor that client address
Where it falls short
The weakness is in the secret. A sequence of ports is not a password protected by encryption. The knockknock README, written by a developer who built an alternative, says the original approach had a replay problem: “if your port sequence was observed by passive eavesdropping, it was easily replayable.” Anyone who watches the traffic once can knock the same way later.
The fwknop README makes the same case from the other side. It says port knocking has trouble defending against replay attacks, cannot reliably support asymmetric ciphers or HMAC schemes, and can be disrupted by spoofing an extra packet into a knock sequence. It also says the port knocking mode of operation is “generally deprecated” in favour of Single Packet Authorization.
Then there is the plainer limit. A knock decides who can reach the port. It does not decide who may log in. Once the port is open for an address, the SSH daemon is exposed to whoever is behind that address, including everyone sharing a company NAT.
Single packet authorization: the fix
Single Packet Authorization (SPA) replaces the sequence with one packet that carries the authorisation. In fwknop, per its README, the packet uses HMAC for “authenticated encryption in the encrypt-then-authenticate model” and the HMAC is checked before decryption. Replays are “detected and thwarted by SHA-256 digest comparison of valid incoming SPA packets.” The README also notes that the HMAC is optional, and that without one, strong authentication is not possible unless GnuPG is used. So turn it on.
The daemon passively sniffs packets with libpcap, so the host needs no listening socket for the knock. The README describes the usual setup as a default-drop firewall against SSH, with the daemon opening access temporarily for an authenticated client. The same README says a service concealed by SPA “naturally cannot be scanned for with Nmap.”
Knocking compared with the other controls
| Control | Hides the port from scans | Resists replay | Replaces login security |
|---|---|---|---|
| Moving SSH off port 22 | No | Not applicable | No |
| Classic port knocking | Yes | No | No |
| Single packet authorization | Yes | Yes, when configured with HMAC | No |
| VPN or gateway | Moves the exposure to the VPN | Depends on the product | No |
| No inbound listener | Yes | Not applicable | No |
Read the last column carefully. None of these replaces a good login. Whatever sits behind the knock should still use key-based authentication. The sshd_config manual lists defaults you can tighten: PasswordAuthentication defaults to yes, MaxAuthTries to 6 and LoginGraceTime to 120 seconds.
When it makes sense
Port knocking and SPA suit a small number of hosts managed by a few technical people: a home lab, a single bastion, a jump host you administer yourself. The cost shows up as you scale. Every client needs the knock tool and the secret. Every server runs a daemon and a firewall rule set that someone must keep correct. There is no central record of who knocked on what, and leaving a staff member means rotating a secret rather than revoking an identity.
CISA’s exposure guidance frames the better question: “Close or restrict access to ports that do not have a documented operational need.” Knocking is a way to restrict a port. It is not a reason to keep one open that you could close.
Where SSHepherd fits
If you want the port to stay closed without handing out knock secrets, SSHepherd® takes a different route. It closes the externally exposed listening port. The server and your administrators each connect outward to a broker, which joins them only for authorised identities, so there is no sequence to guess or replay. Sessions can be monitored, recorded and ended on demand, and a server can be protected in about ten minutes without re-architecting the network. See the Linux SSH use case and the SSHepherd page.
The bottom line
Port knocking hides a port from scanners, and that is real value against automated sweeps. It is obscurity, though: a sniffed sequence can be replayed, and an open port still needs strong authentication behind it. If you use the idea, use single packet authorization with an HMAC, and keep your normal login controls in place.