Rendered at 10:02:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
teddyh 4 hours 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.
And for logging in particular: Just switch the logging over to a temp file that lives in RAM (what disk thrash/write-amplification/SSD wear?), or even disable it altogether for failed login attempts.
We already know that there are great hordes of zombies outside of the castle, banging on the doors and the blocked-off spaces where the windows once were, picking away tirelessly. That's been a constant for many years. Documenting their continued persistence is pretty meaningless. None of it is actionable, or stoppable. It's just going to keep happening. Recording attempts from valid users is also largely without merit; it also just looks like noise, and we've got other ways to troubleshoot stuff that breaks without maintaining a long list of zombie attacks to peruse.
If a zombie actually manages to get in, then that's pretty important to keep track of; log that. But the attempts don't mean anything and have not meant anything for a very long time.
(When the word comes forth that the zombies are gone and the noise has ceased, it will be broadcast so far and wide that even the most noise-deafened sysadmins will find it impossible to ignore. In that seemingly-impossible unlikelihood, we can then resume recording attempts to log in with ssh.)
mvkg 4 hours 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
If you want that, I'd personally suggest wireguard. Bind sshd to the wg interface and it'll be invisible.
z3ratul163071 2 hours ago [-]
It is not stupid. Your stated principle assumes the exposed OpenSSH server does not have pre-auth 0-days. Having open 22 exposes a lot of information about the machine already, not to mention possible banners. The mentioned method is an elegant solution to both risks.
swinglock 2 hours ago [-]
No, it doesn't. You're arguing against a straw man. The primary motivation was in second paragraph.
userbinator 4 hours ago [-]
It violates Kerckhoffs’s principle¹
Appeal to authority?
In the real world, it doesn't matter. Anything that makes the attacker's life harder is fair game. Stupid dogmatic sheep-like mindlessness only leads to "herd exploitability".
also complicates access
That's the whole point.
kstrauser 2 hours ago [-]
That’s not what appeal to authority means.
thayne 4 hours 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.
adrian_b 2 hours ago [-]
If you enable IPsec, the IPsec protocol becomes open, but there is absolutely no difference in comparison with the configuration proposed in TFA, because any IPsec packet that will be received, but which will fail authentication, will be dropped without any other action, i.e. without any reply, so a remote system cannot determine whether IPsec is open or not.
Like for any other packets, you can choose to log such failures, or not. In the parent article the logs are simplified not by the decision of using special authentication packets for opening the SSH port, but by the decision to not log these packets, which is a completely independent decision.
What a remote system could try to determine is not whether IPsec is open, but whether it is possible to initiate a key exchange for IPsec keys. You can easily run IPsec without using a key exchange protocol, by using pre-shared keys. I am not sure whether the last official version of IKE (Internet Key Exchange protocol) provides any reply packet to an initial connection packet that was not authenticated, but in any case it would be easy to customize the key exchange protocol, to not provide any reply.
While TLS is the necessary solution for the communication between computers that have different owners, for the communication between computers that are owned by the same entity IPsec would have been the correct solution (e.g. for connecting your laptop with your home server when you are away), except that the original variant of IPsec had too many completely unnecessary complications, which deterred potential users. Later it was simplified, but it had already acquired a bad reputation of being too difficult to use.
Today the main problem with IPsec remains that there are many stupid firewalls that block without good reasons most protocols and ports. So one may have to run IPsec over some UDP port, instead of running it as an alternative protocol. If even UDP is blocked, one may have to run IPsec over some TCP port, or just over the http or https port (just masquerading it as TCP, not actually running it over TCP, which would mess with flow control).
tptacek 4 hours ago [-]
Just stop logging that stuff.
kazinator 5 hours 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 4 hours 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.
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.
emj 19 minutes ago [-]
Using A as root username with Kj as password is good enough to not be bruteforced generally. People think too much about this.
imoverclocked 4 hours ago [-]
> Whoever wrote that does not know WTF they are talking about
... or they know something you don't.
kazinator 3 hours ago [-]
Giving a the most flimsy reason for the policy doesn't give me confidence in that; I can think of much better reasons for disallowing uid aliases (root or otherwise).
It has the same optics as an unauthorized entry someone planted: a backdoor to retain root access. It will continuously have to be explained to new people who spot it.
If the intent is to keep the passwords identical (which it probably should be), the tooling doesn't support it. When someone changes the password for root using standard tools, the one for rotorooter doesn't sync. This is a problem if someone is changing the password in order to restrict access to just a specific set of people who know the new password. The unaltered entry turns into a de facto backdoor for everyone knowing the old password.
Pitafall: if you put an alias entry in the wrong spot in in the password file, so that it appears before the canonical entry, then UID 0 maps backward to the alias name (e.g. via the getpwuid() function). This breaks all logic that looks for the string "root" rather than UID 0. E.g. shell scripts looking for root in the output of some command.
therein 4 hours ago [-]
Quick, someone ask an LLM.
kstrauser 2 hours ago [-]
Ah, yes, those BSD idiots with their root and toor accounts, clearly clueless about security concerns.
I don’t recall ever seeing a security requirement not to have 2 root accounts. What you can’t have is multiple users sharing the same account. This is different.
yjftsjthsd-h 3 hours ago [-]
> And for good reason
Could I trouble you to specify? Your link only seems to mention password problems that are trivially avoidable (really, if doubling the guesses is a problem, you're already done).
4 hours ago [-]
fedpost 5 hours 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.
tptacek 4 hours ago [-]
No, it's not. The article itself is somewhat incoherent; for instance, if you're using key-only authentication (which: of course you are) fail2ban has literally no function (unless you think attackers are brute-forcing ECDH keys).
The reality is that there are basically two ways to operate SSH:
(1) You can, because OpenSSH is the significant remote service with the literal best track record of any remote service, just disable passwords and let SSH run in 22/tcp exposed to the Internet. Probably stop logging people scanning you; there's nothing you're going to do about it, so it's not real information.
(2) You can keep SSH behind WireGuard, an even simpler security protocol with an even better security story (though: OpenSSH is quite solid), which is designed to not to chat with counterparties that don't have keys, even to do negotiation.
Everything else is performative.
I'd incline towards option (2).
ozim 14 minutes ago [-]
Fail2ban, port knocking, magic packets, setting custom port are basically toys for wasting time. There are always people who have their website hosted on a VPS arguing back and forth about setting custom port ... yeah good luck setting those toys when you have dozens of servers and more than 4 administrators and actual work to be done.
SSH with key-key only or WireGuard/VPN on top are exactly what everyone uses for daily driving.
pak 2 hours ago [-]
OpenSSH has the best track record, but even it had a zero-day RCE (regreSSHion) in 2024.
There are bound to be many more discovered as LLMs capable of doing so proliferate among those who don't report such things responsibly.
Keeping port 22 open puts you first in line for such exploits, while keeping it behind another layer (whether it's WireGuard or firewall tricks) would buy time, if not keep attackers away entirely. That seems useful, no?
BoingBoomTschak 3 hours ago [-]
Note that fail2ban is built inside OpenSSH, these days.
justsomehnguy 2 hours ago [-]
> if you're using key-only authentication (which: of course you are) fail2ban has literally no function (unless you think attackers are brute-forcing ECDH keys).
Why, fail2ban here still serve a very useful function: it bans the offending IP from talking to the machine. It's a simple and a very effective heuristic to block both non-offending port-scans and offending too.
> basically two ways
It's always amusing what people like you almost demand what ssh should be run on the port 22 but are fine with a random port for WireGuard.
And for all of you to assume what both 22/tcp and WireGuard are always available and never blocked.
mvkg 4 hours 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.
simondotau 5 hours 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 5 hours 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).
ggm 5 hours 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.
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
cyh555 2 hours ago [-]
They could be hosting on their own homelab network (without tailscale etc magic)
thayne 4 hours 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.
tgv 4 hours 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 3 hours 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.
vekntksijdhric 4 hours ago [-]
this
happosai 5 hours 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 4 hours 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.
figmert 5 hours 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 31 minutes 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.
akshayrajeshwar 4 hours 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 4 hours ago [-]
Seriously. If a zero-day drops in OpenSSH, it's quite literally the end of the world.
notpushkin 4 hours 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.
Just wrap it in wireguard. WG won't respond to any incoming handshake without a valid and authorized client key, it's essentially invisible.
abc42 2 hours 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.
somat 5 hours ago [-]
The enlightened trick is to run ssh on port 443.
Dwedit 4 hours 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.
Change the sshd port to a random port of your choosing. Cuts down 99.9% of the attempts.
dostick 2 hours 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?
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.
suprjami 5 hours 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.
yjftsjthsd-h 5 hours 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.)
topspin 5 hours 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.
lormayna 2 hours 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.
s_ting765 4 hours 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?"
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.
SoftTalker 5 hours 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 5 hours ago [-]
Or just using a VPN, Wireguard, or Tailscale if you don’t want to configure Wireguard yourself.
pratyahava 3 hours 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.
5 hours ago [-]
vekntksijdhric 4 hours ago [-]
SSH available only via VPN is simpler and more extensible.
mmh0000 5 hours 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:
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.
cperciva 4 hours ago [-]
This is what spiped is for.
tuatoru 4 hours 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.
cyberax 4 hours ago [-]
I don't close SSH. I just use port knocking on my firewall to enable the SSH.
bakugo 5 hours 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 2 hours 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.
streetfighter64 5 hours ago [-]
AI writing, sigh...
> to be unreachable: no banner, no version string,
> It works, but it has a real weakness:
hackernud3s 4 hours ago [-]
I was expecting to hear tailscale TBH. You do you though.
jauntywundrkind 5 hours 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.
notpushkin 4 hours 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.
cynicalkane 5 hours 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 5 hours 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 4 hours ago [-]
You would absolutely not use openssh server for this. That's a terrible idea.
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.
abofh 5 hours ago [-]
You run ssh?
yjftsjthsd-h 2 hours 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.)
IronWolve 5 hours ago [-]
Stacking is cool, but what happened to also having a firewall in front of it?!
OutOfHere 4 hours ago [-]
Exactly. I have an SSH port accessible only by my target IP, not by the whole internet.
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_pr...>
(Adapted from this old post: <https://news.ycombinator.com/item?id=39898061>)
And for logging in particular: Just switch the logging over to a temp file that lives in RAM (what disk thrash/write-amplification/SSD wear?), or even disable it altogether for failed login attempts.
We already know that there are great hordes of zombies outside of the castle, banging on the doors and the blocked-off spaces where the windows once were, picking away tirelessly. That's been a constant for many years. Documenting their continued persistence is pretty meaningless. None of it is actionable, or stoppable. It's just going to keep happening. Recording attempts from valid users is also largely without merit; it also just looks like noise, and we've got other ways to troubleshoot stuff that breaks without maintaining a long list of zombie attacks to peruse.
If a zombie actually manages to get in, then that's pretty important to keep track of; log that. But the attempts don't mean anything and have not meant anything for a very long time.
(When the word comes forth that the zombies are gone and the noise has ceased, it will be broadcast so far and wide that even the most noise-deafened sysadmins will find it impossible to ignore. In that seemingly-impossible unlikelihood, we can then resume recording attempts to log in with ssh.)
[0]: https://news.ycombinator.com/item?id=49307986
Appeal to authority?
In the real world, it doesn't matter. Anything that makes the attacker's life harder is fair game. Stupid dogmatic sheep-like mindlessness only leads to "herd exploitability".
also complicates access
That's the whole point.
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.
Like for any other packets, you can choose to log such failures, or not. In the parent article the logs are simplified not by the decision of using special authentication packets for opening the SSH port, but by the decision to not log these packets, which is a completely independent decision.
What a remote system could try to determine is not whether IPsec is open, but whether it is possible to initiate a key exchange for IPsec keys. You can easily run IPsec without using a key exchange protocol, by using pre-shared keys. I am not sure whether the last official version of IKE (Internet Key Exchange protocol) provides any reply packet to an initial connection packet that was not authenticated, but in any case it would be easy to customize the key exchange protocol, to not provide any reply.
While TLS is the necessary solution for the communication between computers that have different owners, for the communication between computers that are owned by the same entity IPsec would have been the correct solution (e.g. for connecting your laptop with your home server when you are away), except that the original variant of IPsec had too many completely unnecessary complications, which deterred potential users. Later it was simplified, but it had already acquired a bad reputation of being too difficult to use.
Today the main problem with IPsec remains that there are many stupid firewalls that block without good reasons most protocols and ports. So one may have to run IPsec over some UDP port, instead of running it as an alternative protocol. If even UDP is blocked, one may have to run IPsec over some TCP port, or just over the http or https port (just masquerading it as TCP, not actually running it over TCP, which would mess with flow control).
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.
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/...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.
... or they know something you don't.
It has the same optics as an unauthorized entry someone planted: a backdoor to retain root access. It will continuously have to be explained to new people who spot it.
If the intent is to keep the passwords identical (which it probably should be), the tooling doesn't support it. When someone changes the password for root using standard tools, the one for rotorooter doesn't sync. This is a problem if someone is changing the password in order to restrict access to just a specific set of people who know the new password. The unaltered entry turns into a de facto backdoor for everyone knowing the old password.
Pitafall: if you put an alias entry in the wrong spot in in the password file, so that it appears before the canonical entry, then UID 0 maps backward to the alias name (e.g. via the getpwuid() function). This breaks all logic that looks for the string "root" rather than UID 0. E.g. shell scripts looking for root in the output of some command.
I don’t recall ever seeing a security requirement not to have 2 root accounts. What you can’t have is multiple users sharing the same account. This is different.
Could I trouble you to specify? Your link only seems to mention password problems that are trivially avoidable (really, if doubling the guesses is a problem, you're already done).
The reality is that there are basically two ways to operate SSH:
(1) You can, because OpenSSH is the significant remote service with the literal best track record of any remote service, just disable passwords and let SSH run in 22/tcp exposed to the Internet. Probably stop logging people scanning you; there's nothing you're going to do about it, so it's not real information.
(2) You can keep SSH behind WireGuard, an even simpler security protocol with an even better security story (though: OpenSSH is quite solid), which is designed to not to chat with counterparties that don't have keys, even to do negotiation.
Everything else is performative.
I'd incline towards option (2).
SSH with key-key only or WireGuard/VPN on top are exactly what everyone uses for daily driving.
There are bound to be many more discovered as LLMs capable of doing so proliferate among those who don't report such things responsibly.
Keeping port 22 open puts you first in line for such exploits, while keeping it behind another layer (whether it's WireGuard or firewall tricks) would buy time, if not keep attackers away entirely. That seems useful, no?
Why, fail2ban here still serve a very useful function: it bans the offending IP from talking to the machine. It's a simple and a very effective heuristic to block both non-offending port-scans and offending too.
> basically two ways
It's always amusing what people like you almost demand what ssh should be run on the port 22 but are fine with a random port for WireGuard.
And for all of you to assume what both 22/tcp and WireGuard are always available and never blocked.
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.
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.
https://datatracker.ietf.org/doc/draft-gutmann-ssh-preauth/
Password login is disabled. The only way to log in as root directly is via the terminal emulator on the coloc's admin page.
In reality you should use that and then use host based firewall anyway.
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...
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.
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.
UDP was designed as no-guarantee of delivery. Why would you rely on it for this important feature?
On other hand if threat vector includes network monitor with ability to replay i would use wireguard to wrap ssh traffic.
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.
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.
* 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.
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...
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.
Restrict it to the networks where authorized users will be connecting.
So, I have this nft script which works alongside Firewalld:
Then on the client side, I can use anything to send the knock, but usually I just script it out with `ssh` like this: 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.
Unless it's an April Fool joke, in June.
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.
I assume it's suggested precisely because people use passwords. Which, granted, they shouldn't.
> to be unreachable: no banner, no version string,
> It works, but it has a real weakness:
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.
Pick a library. https://github.com/Eugeny/russh
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.