The SSH saga episode 1
0March 17, 2011 by Garrett Mitchener
So, it seems that I need to perhaps make clear some of the misery I go through trying to get to my office workstation from off campus here at C of C. It should be so simple: On my computer at home, I boot into Linux or Windows or whatever, start a terminal emulator program, and ssh to grograman (my workstation) or use scp to copy files back and forth. I even have pointy-clicky programs that can do all of that visually with no command line.
Except nothing is ever as simple as it should be.
It doesn’t work, because the college is behind a maximally paranoid firewall, which means that incoming ssh connections are refused. SSH by the way, stands for “secure shell,” a program that uses state-of-the-art encryption for authentication and secure transmission of data between computers. There’s not much need for additional security on top of ssh, except perhaps to thwart denial of service attacks, but C of C doesn’t see things that way.
So we do have a way through the firewall, a virtual private network or VPN. This is a program that authenticates a user with various passwords, then encrypts data being transmitted between computers outside the firewall and inside to make it appear that my home computer is inside the college’s campus firewall. In other words, it does pretty much what ssh could do if we were to configure the firewall to let it through.
We had one VPN program a while back that worked pretty well with Linux, but the college had some sort of licensing issue with it, and they phased it out. I think it was a Cisco product. I’ll spare you the story of what I had to do to dig the proper configuration information out of the files IT sent me.
Then we started in with Aventail.
Here’s briefly what I had to do to get the Aventail VPN to work from Linux.
I had to first download it from an obscure location that only someone a couple levels up in the helpdesk could tell me about. Uncompress it. Run an installation script. Kind of guess at a few things and go back and forth over several days with upper level helpdesk people, like which menu item would allow me to run ssh through this VPN, much trial and error. And of course it didn’t work. After googling for possible solutions, I found out that this particular bit of software didn’t work with recent versions of the OpenSSL library. I had to figure this out, download, unpack, compile, and install from source code an obsolete version of the OpenSSL library, put in various symbolic links from the command line, use environment variables to override shared library linkage, etc. and then finally it would work. And I had to do it all twice, once on my desktop machine and again on my laptop. And I had to do it all again after certain Linux operating system upgrades that I performed for security and feature updates.
Then once I got Aventail working, it routinely “timed out” and disconnected me every few minutes for no obvious reason, whether I was actively using the connection or not. Which meant that any programs I was running on my workstation through ssh through VPN were forced to quit, and any file transmissions in progress were interrupted. And IT was unable or unwilling to make the VPN stop doing that. Instead, I had to just assume that the VPN connection was going to be perpetually unreliable, and set up something additional called VNC.
VNC is a system of programs that allow you to have a sort of virtual desktop or workspace that isn’t tied to a particular physical monitor. I start it on my workstation, and use a viewer program that can only access the virtual desktop through the VPN. If my VPN connection times out and the viewer loses contact, the virtual desktop continues to run and just waits for the viewer to reconnect, so at least any work I might be doing on my workstation isn’t interrupted while I log in again.
Well, the VNC server is another program I had to install, more documentation to read to figure out how to get it to work, how to get an actual desktop running inside of it, then of course its dreadfully slow because the VNC connection is encrypted, and that is further encrypted by the VPN, two layers of slow encryption… So I had to figure out how to set up a minimal virtual desktop within VNC, which involved installing XFCE on my workstation and fighting to keep it from conflicting with the GNOME desktop running on my physical monitor (and I have ongoing problems with that)…
Then the college upgraded to a new version of Aventail, and my ssh and VNC connections no longer worked. No explanation, IT unable to figure it out, nothing on google.
So I tried a different part of the Aventail product which ran through Java. This required me to do more configuration guesswork, just to get back to the functionality I used to have.
Now if all of this sounds like Greek to you, it should. This is what I was able to come up with based on years of accumulated experience with computers, Unix, Linux, etc. It would take me pages and pages to explain all of this to someone who doesn’t know what command lines and such are. And no faculty member with any sort of typical computing expertise should be expected to figure all of this out.
It also took (and continues to take) a lot of time to deal with all of these problems. I mean hours spent googling for possible solutions, trial and error, reinstalling, recompiling, back and forth with IT over several days.
This is part of why my research is progressing so slowly and why I haven’t had time to do something productive, like tackle a problem with our high performance computing resources.
In contrast, when I was a postdoc at Duke, after some discussion with various IT staff, ssh was allowed through the firewall. No VPN, no VNC, no Aventail. It just worked.
Next episode: The new VPN.
Category Computer | Tags: gripe, how-to
Leave a Reply