Hacker News Reader

Comment by kelnos | Hacker News Reader

This just feels like moving ssh auth to another port, using an obscure "authentication format" that nearly no one uses.

If you're using pubkey or certificate auth, have disabled password auth, and restrict what users are allowed to ssh in, this just feels like added complexity and points of failure (not to mention a possible source of crypto vulnerabilities) with not much added benefit.

Having said that, it's a cool project in general, and I feel like it could be useful to dynamically manage access to large groups of servers (perhaps not just ssh; you could use it to manage access to https interfaces or other things). Then again, if you have a large group of servers, you should have those ports blocked to the world and only allow access through a VPN and/or jump boxes.

View on HN

> Then again, if you have a large group of servers, you should have those ports blocked to the world and only allow access through a VPN and/or jump boxes.

Even with just one server it can make sense to use a VPN.

In my case I am running Wireguard on my server, and I use that VPN among other things for being able to remote in to my grandfather’s computer when he needs help. Since we are both behind NAT at our respective homes, a VPN was needed and I chose to use Wireguard. Wireguard is super easy to set up, and works on FreeBSD (my server and also my desktop run this), macOS (my laptop and my grandfather’s desktop run this), iOS (my phone) and Linux (currently I don’t run Linux but I have for many years and will certainly run it again on some machines again). I don’t use Windows, almost haven’t for a decade with a few small exceptions, but I think Wireguard is available for Windows also.

So anyway, I decided back when I set up Wireguard hey, now that all my machines and my phone is on this VPN, there’s really no reason to expose SSH to the internet anymore. So ever since then I have had sshd listen only on the VPN. It works great.

This. For any amateur server setup that is connected to Internet, wireguard is one-stop solution to cut down all exposure to Internet by running all services only on localhost or wireguard interface and keep only the wireguard port open to Internet.

Agreed - it looks like security through obscurity to me. It has value by shifting the goalposts away from common mass scanning, but to a motivated attacker the security is equivalent.

Relying on security through obscurity alone is a terrible idea, but there is absolutely a place for it. Most of us do not specifically get targeted, but will be affected by automated attacks that look at a large block of ips.

Yeah, just moving your SSH daemon from port 22 to some other port number alone can help with that.

We have continuous distributed dictionary attacks on our SSH servers, with attempts from literally thousands of IP addresses at a cadence designed not to trigger rate alerts.

We moved from port 22, and within days all ports were scanned and the attacks started again on the new port.

We are working on a different scheme to thwart the attackers.

Port knocking, huh?

I faced a similar issue with tens of thousands of login attempts from dozens of unique IP's daily on my server. Moving from 22 helped with some of the traffic but not all. Port knocking however did stop anyone from ever even reaching the right combination and had no login attempts since.

You could generate a random sequence to determine which port to open on any given day.

Is there a practical benefit to pubkey or certificate auth? I feel like using ufw with limit on port 22 and using fail2ban covers most cases, assuming good password decisions.

Never assume good password hygiene. Always use public key auth, turn off password auth ASAP. And run ssh-audit against yourself often.

Against a securely generated password in password manager? No. The only real advantage I can think of is ergonomics: you can safely reuse a public key/certificate across multiple hosts, and even if one of them becomes compromised, your key isn't.

This isn’t true: because the secret never leaves your client machine, mitm attacks can’t be trivially leveraged to access other systems you have access to.

Isn't that what I said? How are you going to get access to other machines if each machine has a unique password?

Sorry, missed that: the problem with a password is that, it the session is mitmed, your password is compromised and the person running the attack can login to the machine whenever they want. ssh keys prevent this attack: mitm only grants access for the duration of the session.

fail2ban has become a lot less useful in recent years, as brute-force password attacks have seemed to mostly move from "1000 attempts from one single IP" to "one single attempt from each of 1000 IPs".

Besides, set up your keypair, set "PasswordAuthentication no", and you don't have to worry about brute-force password attacks anymore (if the "log noise" bothers you, as some people claim, you can filter those out).

Yes, when you use key-based authentication to a server, you never actually give the server a secret, you just cryptographically prove you have the private key that goes to your public key. This is important because the sever can be entirely compromised and you can log into it without leaking any secrets.

Compare this to a secret password, if someone hijacks the SSH connection and you accept the host key (which everyone says yes to on the first connection), you give away your password which can then be used by an attacker to get access to the real server.

Well, I know to immediately block your ip if you try to use password authentication. Saves a bit of time dealing with the criminals. Plus, users sometimes use their work passwords at home for other services. Password managers aren't as much of a thing as I'd like.

Cert auth is the way to go. Here's a good blog post I found by searching: https://smallstep.com/blog/use-ssh-certificates/

Reply on news.ycombinator.com