The enlightened trick is to run ssh on port 443.
Jokes aside, this would be trivial to detect with nmap, right? The SSH banner prints anyways.
I close SSH port 22 (and what I use instead)
91–100 of 106 posts
Re: I close SSH port 22 (and what I use instead)
#92Just 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.
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.
Re: I close SSH port 22 (and what I use instead)
#93I 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...
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.
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.
Re: I close SSH port 22 (and what I use instead)
#94Earlier quoted context omitted.
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 b…
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 wi…
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.
Re: I close SSH port 22 (and what I use instead)
#95Earlier quoted context omitted.
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…
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 fai…
My understanding is even with a PSK you need port 500 open for the initial handshake.
Re: I close SSH port 22 (and what I use instead)
#96Port 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 a…
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.yco…
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.
Re: I close SSH port 22 (and what I use instead)
#97The 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.
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 b…
> 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.
Re: I close SSH port 22 (and what I use instead)
#98AI 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…
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.
Re: I close SSH port 22 (and what I use instead)
#99Earlier quoted context omitted.
> Whoever wrote that does not know WTF they are talking about ... or they know something you don't.
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 t…
I’m confused; Your entire response seems like reasons to not do this.
Re: I close SSH port 22 (and what I use instead)
#100I 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
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.
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