Server clinic: Connect securely with ssh

Neither distance nor firewalls need keep you from your servers

You'll undoubtedly want to use ssh to work on your servers from remote sites, but it takes an assortment of tricks to keep progress rolling smoothly. Share your thoughts on this article with the author and other readers in the accompanying discussion forum. (You can also click Discuss at the top or bottom of the article to access the forum.)


Cameron Laird (, Vice president, Phaseit, Inc.

Cameron is a full-time consultant for Phaseit, Inc. He writes and speaks frequently on open source and other technical topics.

10 July 2003

Also available in Japanese

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.

ssh meets needs

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.

Use standard parts

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.


A "proxy" in this context is a small "translator" that just passes network traffic through. If I have an sshd server set up on port 22, and want another on port 110, one way to achieve this is to install a network proxy. Such a proxy acts as a server on port 110, receiving traffic from the outside. It handles those packets by acting as a client on port 22. The base sshd server does all the real work; the proxy just translates from one port to another (potentially on another host).

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.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Linux on developerWorks

ArticleTitle=Server clinic: Connect securely with ssh