Hacker News Reader

Comment by danwee | Hacker News Reader

So, you have the ssh port (22? custom one?) open to the public on the same machine in which you have your web server/nginx? May I ask why? I had one similar very simple service on Digitalocean once, and my setup was:

- bastion host: custom port for ssh open to the public

- virtual private cloud (vpc): inside I put my web-server and my db server. These servers are not accessible to the public, but the bastion host has access to the vpc

- another server for my nginx. This is public and it redirects requests to my web-server in the vpc

I know it sounds overkill! But somehow it gives me the (illusion?) of being more secure. Am I right with this setup or I'm just wasting my time (and money)? I know perhaps that a VPN could be better... but somehow I found the idea of bastion+vpc quite simple and effective.

View on HN

Enable certificate authentication only, and turn off password authentication. And you are safe. A million bots attacking a billion times won't break in.

You don't need to put anymore security over it, like changing ssh port or running fail2ban, unless you want to reduce CPU load spent behind handling automated port scanners and bots.

Certificate authentication is overkill and rolling it yourself is painful enough that huge companies have been built around it (Teleport). Unless you're an enterprise SSHer with tons of ephemeral hosts, use public keys instead.

I'd guess they just talk about pub key authentication?

I mean, it sounds like in OP's case it's 1 service instance to small N (maybe even 1) potential systems to deploy from. Manual SSH public key deployment doesn't scale to corporate scale, but it certainly scales that far

It does not look so painful. I have found this guide helpful [https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-cer...]

CA isn't terribly difficult. https://keybase.io/blog/keybase-ssh-ca

Or get a hardware token and add it to the authorized_keys. Depends on how many machines you have to setup.

I'm not sure if a bastion host for a single server is all that much better. If OpenSSH allows access to hackers, they'll break into your bastion host and move on from there. All you're really adding is on e more host to forget to patch.

You're only ever more secure if you reduce the attack surface. These days, with WireGuard's simple and secure tunnels, I'd say a VPN may be an improvement, but I'm not all that worried about SSH on my servers. Either disabling password logins or using secure passwords should be fine in most cases.

I personally change the SSH port as well, not really for security but mostly because it keeps the logs clean. Port scans will still happen but you won't get bombarded by thousands of pi@server.com sessions failing every day of the week.

Hetzner has a remote console tool for "local" terminal access.

I use it to enable/disable sshd during use.

SSH with only public key auth allowed is perfectly safe to have exposed to the internet.

it is still a single factor - and private-key compromises are not unheard of.

(but ssh itself has plenty of ways to harden, not to mention the sk stuff)

I have ssh enabled on all my servers, sometimes port 22 sometimes other ports. I have never had a break in. I use fail2ban but I don't know if that's really necessary. But I use it anyway to secure other services (e.g. wordpress instances) against brute-forcing. It goes without saying that password access and root login should be disabled.

If you want to go to crazy lengths to hide your ssh then do port knocking or something.

I only login with my SSH keys, so I don't see the problem — I'm protected with cryptography.

Reply on news.ycombinator.com