Conversation
Notices
-
Embed this notice
@CSB @waltercool
I think the likelihood of untargetted QC attacks on ssh keys is still very far off in the future. Even if the US (or other) government is secretly a decade more advanced than the state of the art in the private sector (which is doubtful), it's still almost certainly gonna be a very niche usage only viable for highly specific high value targets.
That said, if you want to mitigate the risks which realistically exist in the present day, I've found this to be a good help.
https://www.ssh-audit.com/hardening_guides.html
-
Embed this notice
@toiletpaper @CSB The best protection = Never expose SSH to internet :D
-
Embed this notice
@toiletpaper @CSB In the real world you can use VPN, so people can access your SSH servers :-)
Otherwise I get too many attempts of SSH attacks
-
Embed this notice
@waltercool @CSB
That reminds me of a poster the network tech at my first job had, "Ethernet security with scissors." It's about as useful as advising to avoid STI's by chopping off your benis. Meanwhile in the real world...
-
Embed this notice
@toiletpaper @CSB
> Either way you're exposing a port on your server and requiring (presumably) a cryptographic key based authentication scheme.
Yes, you always have to expose something, there are no free cookies.
SSH gives you tunneling or terminal. VPN gives you network access. They are different layers of whatever you want to achieve.
> If you think doing that is going to prevent the need for hardening the service, you're frankly fooling yourself
This is an stupid reasoning, because your proposal let your servers open for attacks, from random IPs or VPNs, not even sshguard may fully help here.
It's lot better to have a two authentication systems instead of just one, one to "allow access to servers", then another to "ssh the servers".
So, in case a coworker gets their SSH keys exposed at internet because he is rtarded, the hackers will also need VPN access, which is harder to get accepted.
-
Embed this notice
@waltercool @CSB
> the real world you can use VPN
A VPN is nice if you need to punch through a firewall by disguising traffic as HTTPS. Though with an httpd setup for reverse proxy tunnelling, you can do that with SSH too.
Either way you're exposing a port on your server and requiring (presumably) a cryptographic key based authentication scheme. Other than the ubiquity of attacks, the actual attack surface and logistics of exploitation are functionally almost identical. Besides which, SSH tunnelling can also be used as a VPN alternative in it's own right, as well as port forwarding, and a whole bunch of other goodness. The only other difference really is if you must use UDP instead of TCP for some reason (which defeats the point of using 443).
> I get too many attempts of SSH attacks
So install fail2ban and/or change the SSH port to something other than 22. If you're super paranoid, look into port knocking. fail2ban's default settings are fine (literally just `apt install fail2ban` and forget it), but if you want to weed out the majority of attacks quickly it's easy to just tweak the maxretry and bantime values in jail.conf. Otherwise if you configure your SSH server and client properly (such as per the hardening guide) you won't have an issue.
Presumably if you're suggesting a VPN tunnel in, you'll still need to access SSHd over the VPN anyway. If you think doing that is going to prevent the need for hardening the service, you're frankly fooling yourself. You'll only eliminate the threat of random low-skill script-kiddies, but not anyone who's genuinely serious about cracking your boxen. All you're really doing by adding a VPN is increasing the admin overhead involved in maintaining your systems.
⚡Lord of Misrule⚡
waltercool
All GNU social JP content and data are available under the