SSH has become our universal (Unix) external access protocol

July 17, 2024

When I noted that brute force attackers seem to go away rapidly if you block them, one reaction was to suggest that SSH shouldn't be exposed to the Internet. While this is viable in some places and arguably broadly sensible (since SSH has a large attack surface, as we've seen recently in CVE-2024-6387), it's not possible for us. Here at a university, SSH has become our universal external access protocol.

One of the peculiarities of universities is that people travel widely, and during that travel they need access to our systems so they can continue working. In general there are a lot of ways to give people external access to things; you can set up VPN servers, you can arrange WireGuard peer to peer connections, and so on. Unfortunately, often two issues surface; our people have widely assorted devices that they want to work from, with widely varying capabilities and ease of using VPN and VPN like things, and their (remote) network environments may or may not like any particular VPN protocol (and they probably don't want to route their entire Internet traffic the long way around through us).

The biggest advantage of SSH is that pretty much everything can do SSH, especially because it's already a requirement for working with our Unix systems when you're on campus and connecting from within the department's networks; this is not necessarily so true of the zoo of different VPN options out there. Because SSH is so pervasive, it's also become a lowest common denominator remote access protocol, one that almost everyone allows people to use to talk to other places. There are a few places where you can't use SSH, but most of them are going to block VPNs too.

In most organizations, even if you use SSH (and IMAP, our other universal external access protocol), you're probably operating with a lot less travel and external access in general, and hopefully a rather more controlled set of client setups. In such an environment you can centralize on a single VPN that works on all of your supported client setups (and meets your security requirements), and then tell everyone that if they need to SSH to something, first they bring up their VPN connection. There's no need to expose SSH to the world, or even let the world know about the existence of specific servers.

(And in a personal environment, the answer today is probably WireGuard, since there are WireGuard clients on most modern things and it's simple enough to only expose SSH on your machines over WireGuard. WireGuard has less exposed attack surface and doesn't suffer from the sort of brute force attacks that SSH does.)


Comments on this page:

By Theodore at 2024-07-18 11:42:38:

SSH can do network through port and socket forwarding, so probably there is way i don't know yet to solve the problem by using two layers of ssh (or mosh) connections...

By Ian Z aka nobrowser at 2024-07-18 12:58:02:

What about UDP? It doesn't make sense to run UDP apps over a TCP based channel. I don't think SSH even allows it. Of course you may not need UDP apps.

@Theodore & Ian: sshuttle can do that automagically for you, so it may be interesting for you to read how it works.

By A_University_Employee at 2024-07-21 09:57:01:

The university I work at has gone the corporate route and just says that you have to use a VPN client, at least partly because they have a way of enforcing two-factor authentication, and "posture checks" that clients are new enough and patched etc. Obviously this also reduces the options for anyone using BYOD, as it needs to be a supported platform for the closed-source (setuid root) VPN binary.

There is an SSH bastion still available, but the cybersecurity team clearly have it on their hit-list!

Seems that this is a remarkably common reaction to the current security landscape, even in universities...

Written on 17 July 2024.
« My self-inflicted UPS and computer conundrum
The Linux Out-Of-Memory killer process list can be misleading »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Wed Jul 17 22:59:18 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.