Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

michelebologna.net

Post reply on HN
Print view View original

11–20 of 106 posts

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

#11

Post by cynicalkane »

jauntywundrkind wrote: post #3

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.

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.

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

#12

Post by zsoltkacsandi »

fedpost wrote: post #4

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.

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

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

#13

Post by yjftsjthsd-h »

suprjami wrote: post #5

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

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

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

#14

Post by 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/

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

#15

Post by zsoltkacsandi »

SoftTalker wrote: post #6

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.

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

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

#19

Post by 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

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

#20

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

Post reply on HN