Moving your SSH port isn’t security by obscurity

Re:Moving your SSH port isn’t security by obscurity by ses1984 on Monday September 21, 2020 @04:43PM (#24548228)

>If someone using SSH ignores the fact that the host key has changed

Here's the real problem.

Also if you're worried you could use SELinux, AppArmor, or things like docker to limit the capabilities of a compromised PHP application.

[ Parent | on HN ]

Re:Moving your SSH port isn’t security by obscurity by cthalupa on Tuesday September 22, 2020 @12:35AM (#24550876)

It is a major issue. Things like autoscaling have got a lot of bad habits ingrained in people though.

You should definitely use SELinux or AppArmor. For any production workload I do.

But for any production workload I don't allow SSH over the public internet. I require a VPN connection to a subnet that only has jumphost(s), the jumphost access logs are shipped to an ELK stack, SSH requires both a key + MFA to login to the jumphost, and SSH between production servers is blocked and alarmed on.

[ Parent | on HN ]

Re:Moving your SSH port isn’t security by obscurity by tekknik on Tuesday September 22, 2020 @08:20AM (#24553614)

SSH onto the prod servers should also be denied. You say autoscaling so do you have an image? If yes then why do you need prod SSH access anyway? If a box is acting up kill it and let the ASG create a new one.

[ Parent | on HN ]

Re:Moving your SSH port isn’t security by obscurity by cthalupa on Monday September 28, 2020 @02:28PM (#24619803)

Sometimes you have trouble reproducing an issue outside of prod, even with things like tcpreplay or blkreplay. You could just kill off a problematic instance, but then you have trouble knowing why there was a problem to begin with. Grey failures might not be obvious in logs or metrics.

The idea that you never ever have to SSH into a production server is a nice ideal, but I've never seen it survive reality unless you just shrug about issues occurring and don't mind not being able to root cause them.

[ Parent | on HN ]