MindTerm and socat and VNC, oh my! While the ability to work remotely has always been one of the Linux advantages that system programmers and administrators have most enjoyed, setting up for remote access takes more than one simple recipe.
Choose the right remote service
Each month, Server clinic describes how to get the most out of the hardware in your server room. The column often touches on ways to use Linux that aren't as well known as they should be: Linux for Fortran programs, Linux for applications designed for legacy operating systems, and so on.
A second continuing theme is security, the subject of this installment.
Your servers should be physically isolated, all non-essential networking access should be disabled, and your only access should be through ssh or better. Live telnet, ftp, rlogin, rsh, and related services, in particular, can be excused only very, very rarely; they're simply too hazardous.
Suppose you've done all these things. Now you're offsite -- maybe demonstrating a product or thrashing out requirements with a new client or finishing up a conference that made it into your training budget. You need to tweak something back at the shop. How do you do it?
First, be sure you should even try. Programmers and administrators are notorious for allowing themselves to be coerced into rushing work that would be better left for normal business hours and the relative calm of your own workplace. Don't victimize yourself this way. Be sure the connection you're after serves a legitimate business purpose and isn't an overreaction.
If you're past those organizational issues, though, the answer to the connection question is "use ssh." Even if you rely, in principle, on a virtual private network (VPN) superior to ssh, I consider it prudent to set up ssh access for emergencies when you can't use your regular methods. VPNs remain a bit touchy and depend on specific hardware configurations. If the way you're "calling home" is through a client's network, perhaps using a generic desktop, your choices are severely limited.
The good news is that ssh usually fits within those limits. Even if you're working out of a public access point such as an "Internet cafe," you probably have enough resources to make ssh work.
You probably can't rely on your own equipment. Hauling around anything larger than a handheld is another security risk I generally judge excessive; worse, plenty of sites don't permit foreign hardware to plug in. You'll often have to use what you're given.
It's generally quick to download the puTTY, ssh, or MindTerm clients, though. I like to do that. Any host with enough of a network stack to be connected to your server room is likely to have a Web browser that permits downloading. Be skeptical of clients that are already installed; it would be too easy for someone to have substituted a modified one that captures your keystrokes, or worse.
One variation that is superficially attractive is to construct a Web page that embeds the MindTerm client as an applet. My experience is that this route rarely helps. Too many sites disable Java, or offer browsers with old Java runtime engines (JRE), or otherwise impair the convenience of the applet. If I'm using MindTerm, I simply expect to download and install both it and a compatible JRE. Applets are often a good technology for construction of applications destined for end-users. They're also apt for read-only configurations. I've found very few of those, though. To enable my own productivity, therefore, working through possible challenges in the applet environment simply isn't worth the time it takes. I've consistently found it easier to locate a megabyte of free mass storage and install an ssh client there.
A few minutes after you sit down, you should have a fresh ssh client installed and launched. That might not be enough, though. Some sites firewall off most ports, or at least enough to include ssh's standard port 22.
Here's another way preparation helps. On at least one of my hosts, I like to leave sshd (ssh daemon) running on a port generally assigned to a common Internet service such as ftp, http, smtp, or pop3. Even the crankiest firewalls keep at least one of ports 21, 8080, 25, and 110 open. Set up one of your machines to "catch" such traffic, and you can make it out past most firewalls.
Does that sound like "cracker" talk? I do not advocate network abuse. I've often had employees of other companies ask me to use their network, though, with the recognition that changing their firewalls in what might seem a sensible way, such as temporarily opening port 22, is organizationally infeasible. I've come to accept that it's simply part of current professional practice to be ready to tunnel out and that I need to ensure that I'm doing so only in a responsible way.
With an ssh channel open, of course, I have almost all the power I'd have sitting at a console in the server room. I can tunnel X or VNC through, if there's a need for a graphics display, and all my other common activities are accessible from a command line.
That's how many of my work sessions start, then: I download reference ssh clients, quickly install and launch them, then authenticate with an SSL-protected password back to one or another sshd I've left running in the server room.
Notice I'm still vulnerable to tampered hosts. A sufficiently modified desktop or alert voyeur could log keystrokes before they reach the SSL library. One solution for that is to use a one-time password (OTP) system. Up to this point, OTP has seemed to me to add more trouble than security. Your own costs and benefits are sure to be at least slightly different. In any case, your return to your regular workplace is likely to be a favorable time to update your passwords.
I like Server clinic to show working code each month. It's hard to add any in this case. The configurations I recommend are straightforward and documented adequately in standard references. To add the ssh service on a second port, for example, you simply add a line such as:
Port 8080
to your existing /etc/ssh/sshd_config, and restart sshd. An alternative approach, useful in running experiments and for tuning logging or extra security, is to use a "network proxy" or "port forwarder" such as netcat or socat, which you point back to localhost's standard ssh port.
The real value of this particular column isn't in esoteric code, but simply in communicating a clear notion of the target you should have for enabling your own remote service. I've tried a lot of approaches. Take advantage of that experience, and especially learn what not to do, at least not when you're first setting up your server room: don't allow telnet, don't leave unused services turned on, don't worry about applets (and especially not applet signing), and don't login remotely if it feels wrong to you.
On the other hand, do use standard parts. I've tried a range of clever ideas for tweaking the ssh protocol or my own firewalls to keep out "black hats." They're generally harder to maintain than the small enhancement in security they afford. Unless I can budget a definite security project with explicit long-term goals, my time is better spent using ssh than trying to improve on it.
Take the steps above, and you'll have a server room that's far more secure than it would be if you just used standard Linux server installations. You'll also be able to manage it remotely, from almost any synchronous connection you're likely to find throughout the world. That's the right starting point for your own security plan.
- Participate in the discussion forum.
- Check out the other installments of Server clinic.
- "Sharing computers on a Linux (or heterogeneous) network, Part 1" (developerWorks, December 2001) compares ssh to VNC. "Sharing computers on a Linux (or heterogeneous) network, Part 2" (developerWorks, March 2002) covers VNC in more detail and also discusses remote X and security.
- "PuTTY: a free Win32 telnet/ssh client" is the home page of the ssh client that Cameron favors using from standard PC desktops.
- The MindTerm product page describes the MindTerm Java-coded ssh client and provides a quick download of the latest no-charge version.
- If you do decide to build a Web page that relies on a signed version of the MindTerm applet, be certain to read up on applet signing.
- "One-Time Password" is, among other things, an IETF standard. While it can be combined with ssh, Cameron believes in focusing his security efforts on other technologies that pay off bigger, including intrusion detection.
- socat does more than previous generations of network proxies or port forwarders, enough so that author Gerhard Rieger justly terms it "multipurpose relay."
- netcat is a port forwarder that's been in use for years.
- sockspy is a scriptable network proxy that's useful for debugging network connections or adding programmability to them.
- Find more resources for Linux developers and administrators in the developerWorks Linux zone.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
