6 ms·

I close SSH port 22 (and what I use instead)

64 points by speckx 3mo ago

mrktf 3mo ago
I would go with something like: seed=`date +%s%N`; ( echo "secretknock-20260811|$seed"|sha512sum ; echo $seed ) | xargs nc -u 192.168.1.1 It is not secure as hmac and it can be 'trivially' brute forced, but don't require extra tools (probably nc not always readily available). On other hand if threat vector includes network monitor with ability to replay i would use wireguard to wrap ssh traffic.
jauntywundrkind 2mo ago
Why not just use ssh as the knock protocol too? To a bespoke ssh server. Ssh to 7000, type "mellon", and ssh 22 opens up. No other software required, and you clearly already have ssh.
- cynicalkane 2mo ago
  That's a good idea, but on the other hand, it seems inappropriate to use such lore in the manner of a lore-master in these suspicious days; not a fitting reference for the happier times of Durin.
- nine_k 2mo ago
  It's easier as in using already known tools. It's potentially less secure because sshd is vastly more complex, and allows literal (authorized) remote code execution, unlike fwknop.
  - jauntywundrkind 2mo ago
    You would absolutely not use openssh server for this. That's a terrible idea. Pick a library. https://github.com/Eugeny/russh https://github.com/Eugeny/russh
- notpushkin 2mo ago
  Why even type anything? Just ssh to 7000, and use the same public key to authenticate. The server responds with “You’re in”, opens up 22 and closes the connection. You then ssh normally. This bespoke server should not advertise it in any special way though (generic OpenSSH banner), and can be used to also ban port scanners if they try to do something fishy. fwknop is impossible to even scan for, though, so it’s a bit more robust in that sense.
- jauntywundrkind 2mo ago
  I threw an example together with Sol: Knoxbox https://github.com/rektide/knoxbox https://github.com/rektide/knoxbox It assumes systemd, which it uses to start sshd. It also restarts a systemd timer to shut sshd down in 5m. Ssh is set up (by defualt on Debian) to have KillMode=process, leaving the client instances alive, just killing the listen server. I tend to agree with the top post. I've never felt that knock servers really deserve consideration. That said, the way that this knock server is so small, makes use of well known parts of the system as it is (systemd), is so low risk, and built around decent security building blocks (recursively) & not some ad-hoc protocol is kind of interesting and fun. This one is pretty easy to visualize.
fedpost 2mo ago
Is this actually practically reducing the attack surface? We're replacing a battle hardened service with a random one that has the ability to manipulate the firewall rules.
- simondotau 2mo ago
  A sensible observation. In theory, the entire codebase for a simple HMAC knock knock ought to be tiny and easy to harden with multiple rounds of human and LLM review. The goal should be to have your complex layers sitting in front of simpler, easier-to-review lines of defence. Once you get to something like an open connection to ssh, the potential attack surface would be orders of magnitude larger, even though it’s more mature and closely scrutinised.
- zsoltkacsandi 2mo ago
  If you mean fail2ban by “battle hardened service”, it manipulates the firewall rules as well. And OpenSSH has the same functionality built-in, without any additional service (PerSourcePenalties).
- mvkg 2mo ago
  I think the answer is yes. A response from a remote system (or lack of) is a signal. The conventional ssh protocol method when connecting to a server is to instantly send over the identification string. RFC 4253 requires "both sides MUST send an identification string". It doesn't necessarily decide an order, but most ssh implementations I've seen send their protocol string before any other data has been received. The broadcasting of the versioning information does constitute a potential leakage of information that could be useful to an attacker. Even if we contrast this to something like mTLS, the client certificate doesn't come until fairly late in the handshake, so there is still information that can be cleaned from the ServerHello from an unauthenticated inspector. This is also the case with QUIC since it piggybacks off the general TLS handshake. I think the issue is, for a known set of systems, can you create communications between them that are oblivious/non-discoverable to non-authorized systems. I think the answer is yes, but it requires an out-of-band key agreement protocol. Wireguard is an example. However, the problem of out-of-band key agreement can't really be ignored. I think the article's method is somewhat valid. I also think it is non-ideal for only doing source IP based rulesets, especially in the world of IPv4 and NAT being prevalent.
suprjami 2mo ago
> and why it is not enough on its own Nothing is good enough on its own. Geoblocking, fail2ban, port obscurity, SSH keys, limiting logins to specific usernames, not using your public internet nickname, putting things behind CloudFlare tunnels or WireGuard, wildcard DNS obscurity, 2FA... There are many options. Defense in depth is the only way to put services on the internet.
- topspin 2mo ago
  > Geoblocking, fail2ban I use both on one port 22 host. Not much actually touches the server: maybe 5 hosts a day get banned. Meanwhile, China and the Netherlands are forever getting blocked and logged by geoblocking. I check the 24h log window by country most business days. Some days China leads, other days the Netherlands pulls ahead. Almost never are any other countries close to those two.
- yjftsjthsd-h 2mo ago
  I certainly agree with your general point, but it is very much my experience that just forcing public key authentication on ssh is good enough on its own. (Yes, I understand that by writing this on the internet, I have doomed us all to dealing with a sev zero openssh sshd RCE on the weekend. Sorry in advance.)
SoftTalker 2mo ago
This is a lot of complexity compared to just not having ssh open to the world (on whatever port you choose to use). Restrict it to the networks where authorized users will be connecting.
- zsoltkacsandi 2mo ago
  Or just using a VPN, Wireguard, or Tailscale if you don’t want to configure Wireguard yourself.
IronWolve 2mo ago
Stacking is cool, but what happened to also having a firewall in front of it?!
- OutOfHere 2mo ago
  Exactly. I have an SSH port accessible only by my target IP, not by the whole internet.
orev 2mo ago
Glad to see fwknop mentioned. Back when the idea of port knocking emerged, there was a lot of criticism about it. Then this came out, and not many seemed to notice. This was before WireGuard and Tailscale, so the main option for remote access was IPsec or OpenVPN, which are both more complicated than most people want to deal with.
ggm 2mo ago
A scheme like this is in the process of being standardised by Peter Gutmann who knows what he is doing. To give that statement more context he's an NZ cryptographer and has also worked in standardisation before. So, he is promoting this model with knowledge of cryptography, risks and the standards process. https://datatracker.ietf.org/doc/draft-gutmann-ssh-preauth/ https://datatracker.ietf.org/doc/draft-gutmann-ssh-preauth/
somat 2mo ago
The enlightened trick is to run ssh on port 443.
- hackernud3s 2mo ago
  And https on 22? Why didn't I think of that?
  - notpushkin 2mo ago
    You could run both on 443: https://github.com/yrutschle/sslh https://github.com/yrutschle/sslh
- Dwedit 2mo ago
  I had to do this once. SSH server needed to run on port 443 because the clients had a locked down network firewall and could only make connections to particular port numbers.
- exdeejay_ 2mo ago
  Jokes aside, this would be trivial to detect with nmap, right? The SSH banner prints anyways.
streetfighter64 2mo ago
AI writing, sigh... > to be unreachable: no banner, no version string, > It works, but it has a real weakness:
deleted 2mo ago
[deleted]
usernametaken29 2mo ago
I don’t know why this wasn’t mentioned before but why not use a Firewall. If you’re using a virtual box like Hetzner or Scaleway you can specify an ip or range at the router level. For all intents and purposes this removes public exposure. Scaleway also has a cheap VPN bridge. So you never need to connect via the public internet if you don’t want to… hardly gets more secure than that
- thayne 2mo ago
  If you are connecting from a residence or a mobile device (like a laptop), your ip address isn't fixed, so a firewall won't help.
  - vekntksijdhric 2mo ago
    this
  - tgv 2mo ago
    I use that strategy, as it's really simple, and I rarely have to change IP addresses. Many providers just hand out the same address every time, others as long as you keep your modem running. A colleague who regularly uses a mobile connection from abroad has a VPN with a fixed IP. Password login is disabled. The only way to log in as root directly is via the terminal emulator on the coloc's admin page.
  - ozim 2mo ago
    How this works in Hetzner web panel where you login you configure that firewall that is in front of your box. In reality you should use that and then use host based firewall anyway.
  - usernametaken29 2mo ago
    And? Adding a new IP takes roughly 15 seconds in the admin panel. Can be automated away via an API… not sure I’d let the “my IP changes” argument slide in 2026
- cyh555 2mo ago
  They could be hosting on their own homelab network (without tailscale etc magic)
kazinator 2mo ago
What I do is laughably simple. 1. Disable all logging about break-in attempts. 2. Do not have any common user names like "root". Say you want to be able to log in as root from anywhere, just with a password. This is a wise idea; what if you need access, but are in a situation where you are not able to use a certificate? Make up an alternative name like roto-rooter or whatever pops into your head. Install it into the password file as an alternative name for UID 0. (Make sure it appears later than the "root" entry!). Also edit the shadow file, making sure that the entry is duplicated for the alternative name. Then in the sshd config file, use AllowUsers to allow only a whitelisted set of users. Here if you say "AllowUsers rotorooter", then the only user id that can authenticate is exactly that one, and it's mapped to UID 0 via passwd/shadow. Add any other accounts you would like to remotely access, giving them similar aliases if they happen to land into a commonly probed space, or are something that a targeted attacker could infer from knowing something about you. Attackers do not probe the user ID space at all. They concentrate exclusively on probing the password spaces of common user IDs like root, admin, database, www-data, etc. If your system does not support any of those IDs, they are not on a trajectory to crack anything. Your rotorooter password could be "g0d" and they will not get in, if all they ever try is root.
- mmh0000 2mo ago
  This is a bad idea™. You should never have more than one UID 0 on a Unix system. This will violate most corporate security guidelines (STIG and CIS) *. And for good reason. A much better idea is to set up a non-root user and configure sudo correctly. * https://www.stigviewer.com/stigs/red_hat_enterprise_linux_9/2023-12-01/finding/V-258059 https://www.stigviewer.com/stigs/red_hat_enterprise_linux_9/...
  - kazinator 2mo ago
    I am not a corporation, so I don't need corporate guidelines. There isn't more than one UID 0. Only more than one password/shadow database entry pointing to it. (It might not be necessary; perhaps there is a way for OpenSSH to remap names, so that our example rotorooter is mapped to root by sshd itself.) > A much better idea is to set up a non-root user and configure sudo correctly. Even if so, the same principle applies: do not call that user admin, for instance. Don't use your first name or anything that a targeted, non-random attacker could guess about you. If that user's name is, oh, 7yMfAxB6, it will never be probed. Though no need to be that paranoid. From the document: > Multiple accounts with a UID of "0" afford more opportunity for potential intruders to guess a password for a privileged account. Whoever wrote that does not know WTF they are talking about. Two identical entries in passwd/shadow do not comprise different "accounts". The UID is the account; the password DB is more or less just window dressing. If the two shadow entries have exactly the same password hash, then no, there aren't more opportunities to guess a password. The only problem with the scheme in a multi-user institutional context is that when an additional UID 0 entry appears that is not "root", it looks like a backdoor someone planted to give themselves continued root access. I don't think it's applicable to what I'm talking about because an institution probably shouldn't be setting up password-based SSH access to a renamed root account over the public internet. This is something that's a good solution for individuals or very small operators. > Change the UID of any account on the system, other than root, that has a UID of "0". Change it to what, with what desired effect? Might as well say 'oh, screw with the password file randomly for shits and giggles'. Better idea: investigate why there is another 0. Maybe there is a good reason.
happosai 2mo ago
I made my ssh server to listen ipv6-only, and it has been super silent in the logs ever since. In the first iteration the IPv6 got polled by a handful of attackers as soon as the letsencrypt certificate was published. In the second iteration I just picked another IPv6 address from the /64 and made ssh.example.com to point to it. This should work until the attackers start guessing subdomain s...
- imoverclocked 2mo ago
  This is an interesting piece that is often overlooked by folks in the "but NAT is security" camp; Having a sparse address space that is 64-bits makes it impossible to iteratively scan over a range. If you don't reverse resolve or you disallow zone transfers then you also have no real discoverability for that /64.
  - happosai 2mo ago
    Nobody allows zone transfers these days. But there is still the option for doing a dictionary attack on subdomains admin/ssh/console.example.com But yeah scanning IPv6 address space directly without DNS dictionary in hand is tough.
abofh 2mo ago
You run ssh?
- yjftsjthsd-h 2mo ago
  I manage machines remotely, yes. Find something better and we can talk. (Note: better includes completing with openssh's near-zero CVE/year count.)
mmh0000 2mo ago
I've been using nftables for port knocking for a while now. I run an SSH tunnel server that needs to be globally accessible. But I don't want it getting hammered by bots nonstop. So, I have this nft script which works alongside Firewalld: $ systemctl enable --now nftables $ cat /etc/nftables/portknock.nft table ip portknock {} delete table ip portknock table ip portknock { set knocked { type ipv4_addr flags timeout timeout 6s gc-interval 2s } # Before conntrack: record the knock, then drop the packet. chain prerouting_knock { type filter hook prerouting priority raw; policy accept; tcp dport 12334 fib daddr type local tcp flags syn counter add @knocked { ip saddr } drop } # Decision chain for port 41444. Every branch is counted so that # `nft -a list table ip portknock` shows which path traffic took. chain gate_41444 { # Established/related sessions pass unconditionally. ct state established,related accept # Host-local. Rarely matches: host-originated traffic is DNATed in # the output hook before it reaches prerouting. Kept as a safeguard. iifname "lo" counter accept # Podman containers reaching the published port (hairpin). ip saddr 10.88.0.0/16 counter accept # Trusted subnets. ip saddr { 10.0.0.0/24, 10.1.0.0/24 } counter accept # Knocked within the last 6 seconds. ip saddr @knocked counter accept # Default deny. If THIS counter is 0 and the accept counters are # also 0, the chain is not being reached at all -- investigate. # Do not assume the gate is working just because nothing got in. counter drop } chain prerouting_gate { type filter hook prerouting priority mangle; policy accept; tcp dport 41444 fib daddr type local jump gate_41444 } } Then on the client side, I can use anything to send the knock, but usually I just script it out with `ssh` like this: $ ssh -p 12334 -o ConnectTimeout=1 "${sServer}" &> /dev/null $ sleep .5 $ ssh -o 'ExitOnForwardFailure=yes' -o 'StrictHostKeyChecking=no' -o 'LogLevel=ERROR' -fp 41444 -R "${iPort}:localhost:22" -T "${sServer}" "sleep 14d" The biggest benefit is that it doesn't require any non-standard tooling. If you have an SSH client and know the rules, you can connect. Yeah, it doesn't have all the "cryptographic signatures" of the article; at the same time, it doesn't have some "random" 3rd-party application that faces the internet and directly controls firewall rules that way. It's still an OpenSSH server with key-auth only. I'm not worried about someone carefully watching my traffic and finding it. I just need Internet bots not connecting to it a million times a second.
figmert 2mo ago
The real solution is using something like Pangolin or Tailscale (or Headscale) for this. You can control access way better and you never have to expose ssh ever. Not even temporarily.
- hn_throw2025 2mo ago
  I agree with you. I’m reading this thread and wondering if I’m missing something, why people are still talking about port knocking, port obfuscation, and fail2ban. I use a cloud VPS. I ssh in via Tailscale. The cloud provider firewall blocks all incoming connections except traffic originating from Cloudflare IP ranges on port 443. My host plays dead to portscans. I check with nmap periodically. I have a break-glass backup terminal login option via my cloud provider dashboard (secured with MFA) in case Tailscale failed and needed investigation and repair. This has worked well for me on AWS and Oracle Cloud. It’s quick and easy to set up. You need a timed service to refresh the ingress IP ranges, but any LLM could spit that out in a second.
  - fragmede 2mo ago
    For those machines, yeah, but I have this fear, of being somewhere and my digital connection is broken. My phone/laptop/everything is stolen/lost/destroyed, and I have to break back in to my digital life. 2 factor authentication screws you if you don't have the second factor because you got mugged. So there might be a server out there that I can ssh into using a username, password, and a memorized IP address, that will get me recovery codes and into my password manager.
    - hn_throw2025 2mo ago
      By MFA I meant the Yubikey plugged in to my home office Mac; I don’t do sysadmin on the bus. But I take your point… I try to make sure I print out recovery codes when offered, and keep them hidden in a safe place at home.
  - figmert 2mo ago
    > I check with nmap periodically. I have a break-glass backup terminal login option via my cloud provider dashboard (secured with MFA) in case Tailscale failed and needed investigation and repair. Cool! Are you able to provide more information on this? My break glass is to temporarily allow public access to my IP, but it's manual and takes time for the firewall rules to apply. I'd love to have a better solution if possible.
bakugo 2mo ago
AI slop article based on a flawed premise. It's 2026, the process of correctly securing an SSH server has exactly two steps: 1. Disable password auth, only public key auth should be enabled 2. Block public access to SSH entirely, use a VPN instead (Tailscale & co. make this trivial) And 2 is entirely optional for most people reading SSH guides who just want a server to host their hobby project. Let's be real, you're probably not reading the auth logs anyway so they don't need to be clean, and if someone discovered an OpenSSH public key auth bypass vulnerability, they absolutely wouldn't waste it on you. Just let those dumb scanners go at it all day, they're not getting in. And a little tangent: fail2ban is 100% placebo and does nothing except clean up the logs a bit. I don't understand why it's still a common recommendation for beginners, it's a relic from the past when bruteforcing was still a concern because people used password auth.
- yjftsjthsd-h 2mo ago
  > And a little tangent: fail2ban is 100% placebo and does nothing except clean up the logs a bit. I don't understand why it's still a common recommendation for beginners, it's a relic from the past when bruteforcing was still a concern because people used password auth. I assume it's suggested precisely because people use passwords. Which, granted, they shouldn't.
- bigstrat2003 2mo ago
  Yep, the only thing you need to do is to disable password auth. They aren't going to be able to crack your SSH key no matter how many times they try.
teddyh 2mo ago
Port knocking, and other bespoke middle layers in front of internet services, is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes (or “noise”) manageable, adjust your logging levels. Anything added in front of your normal service also complicates access, since it’s non-standard. If you want a standard solution to solve all your needs for secure access of IP-based services, use IPsec and be done with it once and for all. 1. <https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_principle&oldid=1361573367 https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_pr...> (Adapted from this old post: <https://news.ycombinator.com/item?id=39898061 https://news.ycombinator.com/item?id=39898061>)
- mvkg 2mo ago
  I agree port knocking is a direct violation of Kerckhoff's principle. However, the proposed solution has non-discoverability from unauthorized sources which isn't necessarily in the threat model of OpenSSH or general cryptography. I do feel like this is potentially a desirable trait. I elaborated a bit more here[0], but I'm curious if you have any grander thoughts on how this could be approached [0]: https://news.ycombinator.com/item?id=49307986 https://news.ycombinator.com/item?id=49307986
  - yjftsjthsd-h 2mo ago
    If you want that, I'd personally suggest wireguard. Bind sshd to the wg interface and it'll be invisible.
  - teddyh 2mo ago
    Non-discoverability is useless. If you want remote logins with encryption and don’t trust OpenSSH, just use telnet and restrict its access to only IPsec-encrypted packets.
- thayne 2mo ago
  I think you are missing the point. It isn't about increasing the bits of security, it's about avoiding the flood of port scanners and the logs that produces. IPsec is way more complicated to set up than this (or other VPN solutions like Wireguard or OpenVPN for that matter), and doesn't even completely solve that problem, because your ipsec port is open. Although, admittedly, there are probably less bots looking for ipsec than ssh.
akshayrajeshwar 2mo ago
> If a zero-day drops in OpenSSH... Realistically, fwknop is more likely to have a vuln than OpenSHH. Last release was two years ago and the readme dates back twelve :/ Time will tell.
- mmh0000 2mo ago
  Seriously. If a zero-day drops in OpenSSH, it's quite literally the end of the world.
- notpushkin 2mo ago
  fwknop is a bit lower risk though. If all an attacker can do is open a port, they’ll still have to exploit OpenSSH.
  - akshayrajeshwar 2mo ago
    fwknop's default is to run as root, so there's that. Support for separation of privileges is still pending since 2013 (https://github.com/mrash/fwknop/issues/32 https://github.com/mrash/fwknop/issues/32)
    - notpushkin 2mo ago
      Good point, thanks.
hackernud3s 2mo ago
I was expecting to hear tailscale TBH. You do you though.
cyberax 2mo ago
I don't close SSH. I just use port knocking on my firewall to enable the SSH.
tuatoru 2mo ago
With all the world's knowledge freely available on the web, people still do this. Unless it's an April Fool joke, in June.
cperciva 2mo ago
This is what spiped is for.
Kiboneu 2mo ago
Just wrap it in wireguard. WG won't respond to any incoming handshake without a valid and authorized client key, it's essentially invisible.
s_ting765 2mo ago
If one is so worried about zero days in openssh, the more practical solution would be centered around these 2 questions: 1. "would you know if you got breached?" 2. "would you have any reaction time?" A simple solution that answers this: https://github.com/64mb/ssh-login-alert-telegram/blob/master/main.sh https://github.com/64mb/ssh-login-alert-telegram/blob/master...
vekntksijdhric 2mo ago
SSH available only via VPN is simpler and more extensible.
pratyahava 2mo ago
i cannot trust tech advices from a guy who puts three ad banners (left, right and bottom, taking approx quarter of my screen space) on his personal blog.
abc42 2mo ago
Seems like a wireguard port in would be a simpler solution, at least superficially. If somebody manages to break both wireguard and ssh security, they probably had access to my laptop anyway so I've lost already.
dostick 2mo ago
So the best solution according to the article is to use UDP’s feature of not being sent to any port in particular. In ideal hypothetical it should work, but on any public WIFI, and remote networks would not deliver UDP. UDP was designed as no-guarantee of delivery. Why would you rely on it for this important feature?
lormayna 2mo ago
My checklist to secure a VPS, enforced by an Ansible playbook. * Disable SSH root login * Disable password login and use only certificates * Enable fail2ban This have been worked for more than ten years and never been hacked. I never understand the need for port knocking.
hebelehubele 2mo ago
Change the sshd port to a random port of your choosing. Cuts down 99.9% of the attempts.
mugiseyebrows 2mo ago
Looks like a good way to accidentally lock yourself out
0x000xca0xfe 2mo ago
Just changing the SSH port is probably enough for small VPS. Port 22 is getting perma-DDOSed on public IPv4 addresses so use it at your own peril but at least for now most bots don't bother port scanning everyone.
- IronBacon 2mo ago
  Yup, in my experience moving the SSH server to any port other that 22 drops to zero the number of failed login attempts to VPSs last time I've checked.
  - gnabgib 2mo ago
    Definitely not zero.. your server gets IPv4 port scanned 2-10 times a day. CriminialIP, PaloAlto, Shodan, Stretchoid, Techties, Censy, Onyphe, VisionHeight, Internet-measurement, Infrawatch, BinaryEdge, and a bunch of Alibaba Cloud/Digital Ocean/VPN/Tor exit IPs all know which port your SSH server is on.

64 points by speckx 3mo ago

mrktf 3mo ago

I would go with something like: seed=`date +%s%N`; ( echo "secretknock-20260811|$seed"|sha512sum ; echo $seed ) | xargs nc -u 192.168.1.1 It is not secure as hmac and it can be 'trivially' brute forced, but don't require extra tools (probably nc not always readily available). On other hand if threat vector includes network monitor with ability to replay i would use wireguard to wrap ssh traffic.

jauntywundrkind 2mo ago

Why not just use ssh as the knock protocol too? To a bespoke ssh server. Ssh to 7000, type "mellon", and ssh 22 opens up. No other software required, and you clearly already have ssh.

cynicalkane 2mo ago
That's a good idea, but on the other hand, it seems inappropriate to use such lore in the manner of a lore-master in these suspicious days; not a fitting reference for the happier times of Durin.
nine_k 2mo ago
It's easier as in using already known tools. It's potentially less secure because sshd is vastly more complex, and allows literal (authorized) remote code execution, unlike fwknop.
- jauntywundrkind 2mo ago
  You would absolutely not use openssh server for this. That's a terrible idea. Pick a library. https://github.com/Eugeny/russh https://github.com/Eugeny/russh
notpushkin 2mo ago
Why even type anything? Just ssh to 7000, and use the same public key to authenticate. The server responds with “You’re in”, opens up 22 and closes the connection. You then ssh normally. This bespoke server should not advertise it in any special way though (generic OpenSSH banner), and can be used to also ban port scanners if they try to do something fishy. fwknop is impossible to even scan for, though, so it’s a bit more robust in that sense.
jauntywundrkind 2mo ago
I threw an example together with Sol: Knoxbox https://github.com/rektide/knoxbox https://github.com/rektide/knoxbox It assumes systemd, which it uses to start sshd. It also restarts a systemd timer to shut sshd down in 5m. Ssh is set up (by defualt on Debian) to have KillMode=process, leaving the client instances alive, just killing the listen server. I tend to agree with the top post. I've never felt that knock servers really deserve consideration. That said, the way that this knock server is so small, makes use of well known parts of the system as it is (systemd), is so low risk, and built around decent security building blocks (recursively) & not some ad-hoc protocol is kind of interesting and fun. This one is pretty easy to visualize.

fedpost 2mo ago

Is this actually practically reducing the attack surface? We're replacing a battle hardened service with a random one that has the ability to manipulate the firewall rules.

simondotau 2mo ago
A sensible observation. In theory, the entire codebase for a simple HMAC knock knock ought to be tiny and easy to harden with multiple rounds of human and LLM review. The goal should be to have your complex layers sitting in front of simpler, easier-to-review lines of defence. Once you get to something like an open connection to ssh, the potential attack surface would be orders of magnitude larger, even though it’s more mature and closely scrutinised.
zsoltkacsandi 2mo ago
If you mean fail2ban by “battle hardened service”, it manipulates the firewall rules as well. And OpenSSH has the same functionality built-in, without any additional service (PerSourcePenalties).
mvkg 2mo ago
I think the answer is yes. A response from a remote system (or lack of) is a signal. The conventional ssh protocol method when connecting to a server is to instantly send over the identification string. RFC 4253 requires "both sides MUST send an identification string". It doesn't necessarily decide an order, but most ssh implementations I've seen send their protocol string before any other data has been received. The broadcasting of the versioning information does constitute a potential leakage of information that could be useful to an attacker. Even if we contrast this to something like mTLS, the client certificate doesn't come until fairly late in the handshake, so there is still information that can be cleaned from the ServerHello from an unauthenticated inspector. This is also the case with QUIC since it piggybacks off the general TLS handshake. I think the issue is, for a known set of systems, can you create communications between them that are oblivious/non-discoverable to non-authorized systems. I think the answer is yes, but it requires an out-of-band key agreement protocol. Wireguard is an example. However, the problem of out-of-band key agreement can't really be ignored. I think the article's method is somewhat valid. I also think it is non-ideal for only doing source IP based rulesets, especially in the world of IPv4 and NAT being prevalent.

suprjami 2mo ago

> and why it is not enough on its own Nothing is good enough on its own. Geoblocking, fail2ban, port obscurity, SSH keys, limiting logins to specific usernames, not using your public internet nickname, putting things behind CloudFlare tunnels or WireGuard, wildcard DNS obscurity, 2FA... There are many options. Defense in depth is the only way to put services on the internet.

topspin 2mo ago
> Geoblocking, fail2ban I use both on one port 22 host. Not much actually touches the server: maybe 5 hosts a day get banned. Meanwhile, China and the Netherlands are forever getting blocked and logged by geoblocking. I check the 24h log window by country most business days. Some days China leads, other days the Netherlands pulls ahead. Almost never are any other countries close to those two.
yjftsjthsd-h 2mo ago
I certainly agree with your general point, but it is very much my experience that just forcing public key authentication on ssh is good enough on its own. (Yes, I understand that by writing this on the internet, I have doomed us all to dealing with a sev zero openssh sshd RCE on the weekend. Sorry in advance.)

SoftTalker 2mo ago

This is a lot of complexity compared to just not having ssh open to the world (on whatever port you choose to use). Restrict it to the networks where authorized users will be connecting.

zsoltkacsandi 2mo ago
Or just using a VPN, Wireguard, or Tailscale if you don’t want to configure Wireguard yourself.

IronWolve 2mo ago

Stacking is cool, but what happened to also having a firewall in front of it?!

OutOfHere 2mo ago
Exactly. I have an SSH port accessible only by my target IP, not by the whole internet.

orev 2mo ago

Glad to see fwknop mentioned. Back when the idea of port knocking emerged, there was a lot of criticism about it. Then this came out, and not many seemed to notice. This was before WireGuard and Tailscale, so the main option for remote access was IPsec or OpenVPN, which are both more complicated than most people want to deal with.

ggm 2mo ago

A scheme like this is in the process of being standardised by Peter Gutmann who knows what he is doing. To give that statement more context he's an NZ cryptographer and has also worked in standardisation before. So, he is promoting this model with knowledge of cryptography, risks and the standards process. https://datatracker.ietf.org/doc/draft-gutmann-ssh-preauth/ https://datatracker.ietf.org/doc/draft-gutmann-ssh-preauth/

somat 2mo ago

The enlightened trick is to run ssh on port 443.

hackernud3s 2mo ago
And https on 22? Why didn't I think of that?
- notpushkin 2mo ago
  You could run both on 443: https://github.com/yrutschle/sslh https://github.com/yrutschle/sslh
Dwedit 2mo ago
I had to do this once. SSH server needed to run on port 443 because the clients had a locked down network firewall and could only make connections to particular port numbers.
exdeejay_ 2mo ago
Jokes aside, this would be trivial to detect with nmap, right? The SSH banner prints anyways.

streetfighter64 2mo ago

AI writing, sigh... > to be unreachable: no banner, no version string, > It works, but it has a real weakness:

deleted 2mo ago

[deleted]

usernametaken29 2mo ago

I don’t know why this wasn’t mentioned before but why not use a Firewall. If you’re using a virtual box like Hetzner or Scaleway you can specify an ip or range at the router level. For all intents and purposes this removes public exposure. Scaleway also has a cheap VPN bridge. So you never need to connect via the public internet if you don’t want to… hardly gets more secure than that

thayne 2mo ago
If you are connecting from a residence or a mobile device (like a laptop), your ip address isn't fixed, so a firewall won't help.
- vekntksijdhric 2mo ago
  this
- tgv 2mo ago
  I use that strategy, as it's really simple, and I rarely have to change IP addresses. Many providers just hand out the same address every time, others as long as you keep your modem running. A colleague who regularly uses a mobile connection from abroad has a VPN with a fixed IP. Password login is disabled. The only way to log in as root directly is via the terminal emulator on the coloc's admin page.
- ozim 2mo ago
  How this works in Hetzner web panel where you login you configure that firewall that is in front of your box. In reality you should use that and then use host based firewall anyway.
- usernametaken29 2mo ago
  And? Adding a new IP takes roughly 15 seconds in the admin panel. Can be automated away via an API… not sure I’d let the “my IP changes” argument slide in 2026
cyh555 2mo ago
They could be hosting on their own homelab network (without tailscale etc magic)

kazinator 2mo ago

What I do is laughably simple. 1. Disable all logging about break-in attempts. 2. Do not have any common user names like "root". Say you want to be able to log in as root from anywhere, just with a password. This is a wise idea; what if you need access, but are in a situation where you are not able to use a certificate? Make up an alternative name like roto-rooter or whatever pops into your head. Install it into the password file as an alternative name for UID 0. (Make sure it appears later than the "root" entry!). Also edit the shadow file, making sure that the entry is duplicated for the alternative name. Then in the sshd config file, use AllowUsers to allow only a whitelisted set of users. Here if you say "AllowUsers rotorooter", then the only user id that can authenticate is exactly that one, and it's mapped to UID 0 via passwd/shadow. Add any other accounts you would like to remotely access, giving them similar aliases if they happen to land into a commonly probed space, or are something that a targeted attacker could infer from knowing something about you. Attackers do not probe the user ID space at all. They concentrate exclusively on probing the password spaces of common user IDs like root, admin, database, www-data, etc. If your system does not support any of those IDs, they are not on a trajectory to crack anything. Your rotorooter password could be "g0d" and they will not get in, if all they ever try is root.

mmh0000 2mo ago
This is a bad idea™. You should never have more than one UID 0 on a Unix system. This will violate most corporate security guidelines (STIG and CIS) *. And for good reason. A much better idea is to set up a non-root user and configure sudo correctly. * https://www.stigviewer.com/stigs/red_hat_enterprise_linux_9/2023-12-01/finding/V-258059 https://www.stigviewer.com/stigs/red_hat_enterprise_linux_9/...
- kazinator 2mo ago
  I am not a corporation, so I don't need corporate guidelines. There isn't more than one UID 0. Only more than one password/shadow database entry pointing to it. (It might not be necessary; perhaps there is a way for OpenSSH to remap names, so that our example rotorooter is mapped to root by sshd itself.) > A much better idea is to set up a non-root user and configure sudo correctly. Even if so, the same principle applies: do not call that user admin, for instance. Don't use your first name or anything that a targeted, non-random attacker could guess about you. If that user's name is, oh, 7yMfAxB6, it will never be probed. Though no need to be that paranoid. From the document: > Multiple accounts with a UID of "0" afford more opportunity for potential intruders to guess a password for a privileged account. Whoever wrote that does not know WTF they are talking about. Two identical entries in passwd/shadow do not comprise different "accounts". The UID is the account; the password DB is more or less just window dressing. If the two shadow entries have exactly the same password hash, then no, there aren't more opportunities to guess a password. The only problem with the scheme in a multi-user institutional context is that when an additional UID 0 entry appears that is not "root", it looks like a backdoor someone planted to give themselves continued root access. I don't think it's applicable to what I'm talking about because an institution probably shouldn't be setting up password-based SSH access to a renamed root account over the public internet. This is something that's a good solution for individuals or very small operators. > Change the UID of any account on the system, other than root, that has a UID of "0". Change it to what, with what desired effect? Might as well say 'oh, screw with the password file randomly for shits and giggles'. Better idea: investigate why there is another 0. Maybe there is a good reason.

happosai 2mo ago

I made my ssh server to listen ipv6-only, and it has been super silent in the logs ever since. In the first iteration the IPv6 got polled by a handful of attackers as soon as the letsencrypt certificate was published. In the second iteration I just picked another IPv6 address from the /64 and made ssh.example.com to point to it. This should work until the attackers start guessing subdomain s...

imoverclocked 2mo ago
This is an interesting piece that is often overlooked by folks in the "but NAT is security" camp; Having a sparse address space that is 64-bits makes it impossible to iteratively scan over a range. If you don't reverse resolve or you disallow zone transfers then you also have no real discoverability for that /64.
- happosai 2mo ago
  Nobody allows zone transfers these days. But there is still the option for doing a dictionary attack on subdomains admin/ssh/console.example.com But yeah scanning IPv6 address space directly without DNS dictionary in hand is tough.

abofh 2mo ago

You run ssh?

yjftsjthsd-h 2mo ago
I manage machines remotely, yes. Find something better and we can talk. (Note: better includes completing with openssh's near-zero CVE/year count.)

mmh0000 2mo ago

I've been using nftables for port knocking for a while now. I run an SSH tunnel server that needs to be globally accessible. But I don't want it getting hammered by bots nonstop. So, I have this nft script which works alongside Firewalld: $ systemctl enable --now nftables $ cat /etc/nftables/portknock.nft table ip portknock {} delete table ip portknock table ip portknock { set knocked { type ipv4_addr flags timeout timeout 6s gc-interval 2s } # Before conntrack: record the knock, then drop the packet. chain prerouting_knock { type filter hook prerouting priority raw; policy accept; tcp dport 12334 fib daddr type local tcp flags syn counter add @knocked { ip saddr } drop } # Decision chain for port 41444. Every branch is counted so that # `nft -a list table ip portknock` shows which path traffic took. chain gate_41444 { # Established/related sessions pass unconditionally. ct state established,related accept # Host-local. Rarely matches: host-originated traffic is DNATed in # the output hook before it reaches prerouting. Kept as a safeguard. iifname "lo" counter accept # Podman containers reaching the published port (hairpin). ip saddr 10.88.0.0/16 counter accept # Trusted subnets. ip saddr { 10.0.0.0/24, 10.1.0.0/24 } counter accept # Knocked within the last 6 seconds. ip saddr @knocked counter accept # Default deny. If THIS counter is 0 and the accept counters are # also 0, the chain is not being reached at all -- investigate. # Do not assume the gate is working just because nothing got in. counter drop } chain prerouting_gate { type filter hook prerouting priority mangle; policy accept; tcp dport 41444 fib daddr type local jump gate_41444 } } Then on the client side, I can use anything to send the knock, but usually I just script it out with `ssh` like this: $ ssh -p 12334 -o ConnectTimeout=1 "${sServer}" &> /dev/null $ sleep .5 $ ssh -o 'ExitOnForwardFailure=yes' -o 'StrictHostKeyChecking=no' -o 'LogLevel=ERROR' -fp 41444 -R "${iPort}:localhost:22" -T "${sServer}" "sleep 14d" The biggest benefit is that it doesn't require any non-standard tooling. If you have an SSH client and know the rules, you can connect. Yeah, it doesn't have all the "cryptographic signatures" of the article; at the same time, it doesn't have some "random" 3rd-party application that faces the internet and directly controls firewall rules that way. It's still an OpenSSH server with key-auth only. I'm not worried about someone carefully watching my traffic and finding it. I just need Internet bots not connecting to it a million times a second.

figmert 2mo ago

The real solution is using something like Pangolin or Tailscale (or Headscale) for this. You can control access way better and you never have to expose ssh ever. Not even temporarily.

hn_throw2025 2mo ago
I agree with you. I’m reading this thread and wondering if I’m missing something, why people are still talking about port knocking, port obfuscation, and fail2ban. I use a cloud VPS. I ssh in via Tailscale. The cloud provider firewall blocks all incoming connections except traffic originating from Cloudflare IP ranges on port 443. My host plays dead to portscans. I check with nmap periodically. I have a break-glass backup terminal login option via my cloud provider dashboard (secured with MFA) in case Tailscale failed and needed investigation and repair. This has worked well for me on AWS and Oracle Cloud. It’s quick and easy to set up. You need a timed service to refresh the ingress IP ranges, but any LLM could spit that out in a second.
- fragmede 2mo ago
  For those machines, yeah, but I have this fear, of being somewhere and my digital connection is broken. My phone/laptop/everything is stolen/lost/destroyed, and I have to break back in to my digital life. 2 factor authentication screws you if you don't have the second factor because you got mugged. So there might be a server out there that I can ssh into using a username, password, and a memorized IP address, that will get me recovery codes and into my password manager.
  - hn_throw2025 2mo ago
    By MFA I meant the Yubikey plugged in to my home office Mac; I don’t do sysadmin on the bus. But I take your point… I try to make sure I print out recovery codes when offered, and keep them hidden in a safe place at home.
- figmert 2mo ago
  > I check with nmap periodically. I have a break-glass backup terminal login option via my cloud provider dashboard (secured with MFA) in case Tailscale failed and needed investigation and repair. Cool! Are you able to provide more information on this? My break glass is to temporarily allow public access to my IP, but it's manual and takes time for the firewall rules to apply. I'd love to have a better solution if possible.

bakugo 2mo ago

AI slop article based on a flawed premise. It's 2026, the process of correctly securing an SSH server has exactly two steps: 1. Disable password auth, only public key auth should be enabled 2. Block public access to SSH entirely, use a VPN instead (Tailscale & co. make this trivial) And 2 is entirely optional for most people reading SSH guides who just want a server to host their hobby project. Let's be real, you're probably not reading the auth logs anyway so they don't need to be clean, and if someone discovered an OpenSSH public key auth bypass vulnerability, they absolutely wouldn't waste it on you. Just let those dumb scanners go at it all day, they're not getting in. And a little tangent: fail2ban is 100% placebo and does nothing except clean up the logs a bit. I don't understand why it's still a common recommendation for beginners, it's a relic from the past when bruteforcing was still a concern because people used password auth.

yjftsjthsd-h 2mo ago
> And a little tangent: fail2ban is 100% placebo and does nothing except clean up the logs a bit. I don't understand why it's still a common recommendation for beginners, it's a relic from the past when bruteforcing was still a concern because people used password auth. I assume it's suggested precisely because people use passwords. Which, granted, they shouldn't.
bigstrat2003 2mo ago
Yep, the only thing you need to do is to disable password auth. They aren't going to be able to crack your SSH key no matter how many times they try.

teddyh 2mo ago

Port knocking, and other bespoke middle layers in front of internet services, is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes (or “noise”) manageable, adjust your logging levels. Anything added in front of your normal service also complicates access, since it’s non-standard. If you want a standard solution to solve all your needs for secure access of IP-based services, use IPsec and be done with it once and for all. 1. <https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_principle&oldid=1361573367 https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_pr...> (Adapted from this old post: <https://news.ycombinator.com/item?id=39898061 https://news.ycombinator.com/item?id=39898061>)

mvkg 2mo ago
I agree port knocking is a direct violation of Kerckhoff's principle. However, the proposed solution has non-discoverability from unauthorized sources which isn't necessarily in the threat model of OpenSSH or general cryptography. I do feel like this is potentially a desirable trait. I elaborated a bit more here[0], but I'm curious if you have any grander thoughts on how this could be approached [0]: https://news.ycombinator.com/item?id=49307986 https://news.ycombinator.com/item?id=49307986
- yjftsjthsd-h 2mo ago
  If you want that, I'd personally suggest wireguard. Bind sshd to the wg interface and it'll be invisible.
- teddyh 2mo ago
  Non-discoverability is useless. If you want remote logins with encryption and don’t trust OpenSSH, just use telnet and restrict its access to only IPsec-encrypted packets.
thayne 2mo ago
I think you are missing the point. It isn't about increasing the bits of security, it's about avoiding the flood of port scanners and the logs that produces. IPsec is way more complicated to set up than this (or other VPN solutions like Wireguard or OpenVPN for that matter), and doesn't even completely solve that problem, because your ipsec port is open. Although, admittedly, there are probably less bots looking for ipsec than ssh.

akshayrajeshwar 2mo ago

> If a zero-day drops in OpenSSH... Realistically, fwknop is more likely to have a vuln than OpenSHH. Last release was two years ago and the readme dates back twelve :/ Time will tell.

mmh0000 2mo ago
Seriously. If a zero-day drops in OpenSSH, it's quite literally the end of the world.
notpushkin 2mo ago
fwknop is a bit lower risk though. If all an attacker can do is open a port, they’ll still have to exploit OpenSSH.
- akshayrajeshwar 2mo ago
  fwknop's default is to run as root, so there's that. Support for separation of privileges is still pending since 2013 (https://github.com/mrash/fwknop/issues/32 https://github.com/mrash/fwknop/issues/32)
  - notpushkin 2mo ago
    Good point, thanks.

hackernud3s 2mo ago

I was expecting to hear tailscale TBH. You do you though.

cyberax 2mo ago

I don't close SSH. I just use port knocking on my firewall to enable the SSH.

tuatoru 2mo ago

With all the world's knowledge freely available on the web, people still do this. Unless it's an April Fool joke, in June.

cperciva 2mo ago

This is what spiped is for.

Kiboneu 2mo ago

Just wrap it in wireguard. WG won't respond to any incoming handshake without a valid and authorized client key, it's essentially invisible.

s_ting765 2mo ago

If one is so worried about zero days in openssh, the more practical solution would be centered around these 2 questions: 1. "would you know if you got breached?" 2. "would you have any reaction time?" A simple solution that answers this: https://github.com/64mb/ssh-login-alert-telegram/blob/master/main.sh https://github.com/64mb/ssh-login-alert-telegram/blob/master...

vekntksijdhric 2mo ago

SSH available only via VPN is simpler and more extensible.

pratyahava 2mo ago

i cannot trust tech advices from a guy who puts three ad banners (left, right and bottom, taking approx quarter of my screen space) on his personal blog.

abc42 2mo ago

Seems like a wireguard port in would be a simpler solution, at least superficially. If somebody manages to break both wireguard and ssh security, they probably had access to my laptop anyway so I've lost already.

dostick 2mo ago

So the best solution according to the article is to use UDP’s feature of not being sent to any port in particular. In ideal hypothetical it should work, but on any public WIFI, and remote networks would not deliver UDP. UDP was designed as no-guarantee of delivery. Why would you rely on it for this important feature?

lormayna 2mo ago

My checklist to secure a VPS, enforced by an Ansible playbook. * Disable SSH root login * Disable password login and use only certificates * Enable fail2ban This have been worked for more than ten years and never been hacked. I never understand the need for port knocking.

hebelehubele 2mo ago

Change the sshd port to a random port of your choosing. Cuts down 99.9% of the attempts.

mugiseyebrows 2mo ago

Looks like a good way to accidentally lock yourself out

0x000xca0xfe 2mo ago

Just changing the SSH port is probably enough for small VPS. Port 22 is getting perma-DDOSed on public IPv4 addresses so use it at your own peril but at least for now most bots don't bother port scanning everyone.

IronBacon 2mo ago
Yup, in my experience moving the SSH server to any port other that 22 drops to zero the number of failed login attempts to VPSs last time I've checked.
- gnabgib 2mo ago
  Definitely not zero.. your server gets IPv4 port scanned 2-10 times a day. CriminialIP, PaloAlto, Shodan, Stretchoid, Techties, Censy, Onyphe, VisionHeight, Internet-measurement, Infrawatch, BinaryEdge, and a bunch of Alibaba Cloud/Digital Ocean/VPN/Tor exit IPs all know which port your SSH server is on.