I closed SSH port 22 entirely — here's what I use instead

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

I closed SSH port 22 entirely — here's what I use instead

Most SSH hardening guides stop at key-only auth and fail2ban, but port 22 remains exposed to scanners and zero-days. The author uses fwknop's Single Packet Authorization (SPA) to make the SSH daemon completely unreachable unless a valid encrypted UDP packet is received. This article explains how SPA works, how to generate keys, deploy the server with Ansible, configure clients, and integrate it with SSH and Ansible. It also covers Tailscale as a parallel access path, and what this setup actually changes in terms of attack surface and log noise.

This is not security through obscurity. The port is not hidden behind some clever port number. It is genuinely closed.
  1. kazinator

    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.

  2. teddyh

    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_pr...>

    (Adapted from this old post: <https://news.ycombinator.com/item?id=39898061>)

  3. fedpost

    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.

  4. ggm

    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/

  5. usernametaken29

    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

  6. happosai

    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...

  7. figmert

    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.

  8. akshayrajeshwar

    > 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.

More from this day

2026-08-15