NEW: See the Follow Up.
I’m in a bit of a pickle.
Traditionally, we’ve always allowed wide-open SSH access from anywhere to our main terminal server for remote access. Since we use NX (neatx, FreeNX, NXclient, etc.), all we ever needed open was SSH to make it all work nicely. Sure, SSH is a big bruteforce target but with DenyHosts and low thresholds things are pretty well under control. I realize huge distributed bruteforce attacks are still possible against a DenyHosts protected SSH daemon but we have to factor in ease of use when thinking about security and the low risk of massively distributed bruteforce attacks.
With the deployment of a new terminal server we have the opportunity to use the Cisco-based campus VPN service delegated to us via a customized VPN group. This is all well and good except for one thing: There is no ability to set custom routes for the clients based on those VPN groups. When a remote user connects to the VPN, *all* their network traffic has to be routed via the VPN. This typically makes sense, it is a VPN after all. However, we have a strong use case for which this simply won’t work. We have remote collaborators from anywhere in the world and mandating that they route all their Internet traffic via us when they need to remote in to our systems is unacceptable. Not to mention we have local users working from home and the same applies. We cannot mandate that these users have to route all their non-work related private traffic via us whenever they also need to access our resources at the same time.
Alternatives
So what are we left with? What can we do to provide increased security while also maintaining the ease of use of direct SSH access? I’ve thought of a couple things, but they also have disadvantages:
1. Run our own VPN with OpenVPN on dd-wrt or a generic box.
This sounds great at first but this requires that we support another box and another service directly. The campus VPN service is managed by the central IT group, our own VPN would add support costs of our own and specifically with the client installation side of things. I’d have to come up with our own instructions for installing and configuring the clients on multiple operating systems and hope that our users don’t have serious problems getting it working.
2. Use SSH but mandate the use of SSH keys.
No doubt some of our users have bad passwords and using SSH keys would prevent password bruteforce attempts including massively distributed ones. But mandating the use of SSH keys seems like hell from a support perspective. Asking users to generate keys and have them available on any client they wish to use is really pushing the boundary of what they’ll be able to successfully do on their own. I just know I’d get the evil eye from everyone if I handed them the instructions for how to accomplish this.
Push Back Times Two
What makes this worse is no matter what I choose, I’ll get push back from one side or the other. Make things more secure but more complicated and my user base will be seriously unhappy. Continue allowing direct SSH access as the long term policy and the central IT group(s) will tar and feather me: “Bad practice! Bad practice!”. Damn this pickle!
So, again, what are we left with for secure remote access solutions that are both secure and simple enough for anyone to use? Any suggestions dear Internet?