Live data from Hacker News

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

michelebologna.net

101–106 of 106 posts

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

#101

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.

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.

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.

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

#102

Earlier quoted context omitted.

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.

None of them apply to the situation of an individual operating an accessible system for their own use, or very small business with a handful of employees.

The kind of organization where it would make sense to forbid tricks like multiple password entries pointing to the same user (such as UID 0) is going ot be the kind of organization where the whole thing is moot anyway in connection with SSH, because in those kinds of organizations, you don't want ad hoc machines to be accessible via SSH publicly. You don't want employees to be solving the problem of SSH ports being probed: do we use fail2ban, port knocking, kazinator's user name tricks posted on HN? ... just no! You have some kind of perimeter VPN. Authorized users connected to the VPN can then use SSH to machines inside the secured zone.

It makes no sense to bring up corporate rules against my solution which for a problem that corporations should not have in the first place: SSH-accessible machines on the open internet being probed.

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

#103
post #27

Earlier quoted context omitted.

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

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.

It is different when it is a well-known thing. If you see "toor" in a BSD password file, you know that's a BSD thing and not someone making a backdoor.

I'm wildly guessing that the BSD flavors that have toor have patched their password DB manipulation utilities and APIs such that when you change the root password, the toor one changes with it and vice versa.

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

#104
post #84

Earlier quoted context omitted.

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 app…

Using A as root username with Kj as password is good enough to not be bruteforced generally. People think too much about this.

Using A as a root username would have to become massively popular before the cracking "community" began including it in their probing. After that, the Kj password might not hold up.

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

#105
post #97

Earlier 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…

> 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 po…

Sure thing. I really meant that my Oracle Cloud account is protected by my YubiKey, and when I provision an instance I set a strong, pre-hashed password for the local account in the CloudInit configuration. If I ever need emergency maintenance access, I can use the OCI instance console from the dashboard rather than SSH. SSH itself is configured to accept publickey authentication only, disallow root login, and only listen on the Tailnet IP range. So the password isn’t part of the normal SSH access path.

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

#106
post #28

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 a…

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.

> Anything that makes the attacker's life harder is fair game.

No, security mechanisms also should be convenient to use. Otherwise, people will avoid them and work around them using more insecure methods. Anything that can be configured to be transparent, like IPsec, is therefore inherently better than something like this (fwknop), where you have to run special commands from your .ssh/config, and which also only works for SSH.

Post reply on HN