Securing Access to a Hosted Server

Posted March 22nd, 2005 by kyle


We use shared hosting services to provide our company’s web presence. Even though the software we produce is Windows-specific, we have been using a Unix-based hosting service for nearly six years. The service is very reliable and affordable, and we have no reason to switch to something else.

We regularly access the server over the internet for updating the web site with FTP, using Telnet sessions for configuring and monitoring the server, and checking mail via POP3. Until recently, we never bothered with securing these network connections, so all login information for the various protocols and the data itself was sent unencrypted over the wire. With all the emphasis these days on security and rising concerns about compromising the integrity of our site, we decided to take a first step by securing all username and password information transmitted to the server.


It was quite a learning process. There isn’t a single standard way of dealing with these issues for all protocols. SSH and SSL/TLS are the two dominant encryption mechanisms that are commonly available. Both provide strong encryption, integrity, and authentication.

Most Unix-based servers come with SSH support, but SSL is less commonly available. Another big advantage for SSH is that it supports easy setup of secure channels over which other standard protocols can be transparently tunnelled. SSL typically requires specific software for each protocol on both the server and client. This was a big factor for us, since we can’t easily get custom server-side services installed on our hosted server, and we wanted to continue to use our existing FTP and Telnet clients used for automated deployment.

Secure Telnet

For Telnet, SSH can tunnel standard Telnet client connections over a secure channel (all transferred information is encrypted), while SSL requires an SSL-enabled Telnet server and client, neither of which are very commonly available.

Secure FTP

For FTP, the options are FTPS (FTP over SSL), SCP (secure copy over SSH), SFTP, and FTP over SSH. One drawback of FTPS, SFTP, and SCP is that they are not fully FTP-compatible, requiring a custom client program in order to access (SCP also does not support text/ASCII transfer mode, which is useful for transferring between Windows clients and Unix hosts). Any standard FTP client that supports passive mode can be used for FTP over SSH. One disadvantage of FTP over SSH is that only the connection (authentication) channel is encrypted — the actual data transfer is not encrypted without a lot of extra work. This is good enough for us, since practically all of the information we put on the server is intended for public consumption anyway.

Secure POP3

POP3 authentication can also be tunneled over SSH. Many mail readers support POP3/SSL, and server support for POP3 over SSL seems to be fairly common as well (our hosting service now supports it), so either method is easily configured. There isn’t much gained by secure transfer of the POP3 data itself, since the data will be transferred unencrypted from the server to its destination (encrypting and signing the payload via PGP or other encryption methods is advisable if the content needs to be protected).

Setting up SSH

Provided that SSH is available on the server (SSHWindows may be an option if your server is running Windows), setting up the client for SSH is very simple. We chose a free client application called PuTTy, which provides a client program for interactive Telnet sessions, as well as an SCP client and a command-line client (Plink) for automating setup of secure tunnels for other protocols. We run PuTTy once to connect to the server, accepting the dialog for storing the RSA key on the local computer (in the registry) so that it doesn’t prompt for it again. Then, to setup secure tunnels for FTP, Telnet, and POP3, we run Plink on a computer on our LAN with a command-line like:

plink -v -C -N -2 -l  -pw  -L

Now we can use our regular Telnet and FTP clients from anywhere on the LAN (configuring them to connect to the local server running Plink instead of the hosted server, and configuring FTP for passive mode), and all authentication information is encrypted over the SSH tunnels. We also use Plink in our automated build procedure to ensure that FTP and Telnet sessions are encrypted.

It’s also possible to avoid putting a username and password in the shortcut by utilizing public key authentication. As described in the PuTTy user manual, this “is more secure and flexible, but more difficult to set up.” This is left as an exercise for the reader (or perhaps a future article).

Share and Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • BlinkList
  • blogmarks
  • digg
  • feedmelinks
  • Furl
  • LinkaGoGo
  • NewsVine
  • Reddit
  • Simpy
  • Spurl
  • YahooMyWeb

3 Comments on “Securing Access to a Hosted Server”

  1. Mark Blacke Says:


    In addition to what you described above, you may be interested in checking out the following products all available in trial editions for no-cost evaluation.

    Webdrive maps a FTP, SFTP, FTPS, etc account to a Windows drive letter so you can transparently read and write to these services via Windows Explorer, scripts, and application programs. Highly recommended.

    SFTPdrive is similar to webdrive but is newer (a little more raw), cheaper, and works only with SFTP services. I have no experience with this product but I’ve seen enthusiastic posts about it in various forums.

    Strongspace is a hosted online storage service that is only accessible via SFTP. Both Webdrive and SFTPdrive work great with this service. (This service is like Xdrive, only, IMO, more reliable and secure).


  2. Jeff Mancuso Says:

    Your post says that SFTP is “FTP over SSH.” I’d like to clear that up. SFTP is actually an entirely different protocol, and has almost nothing to do with FTP other than sharing 3/4 of its name. Sftp does authenticate and do the data transfer securely, everything is done securely within the SSH connection.

  3. kyle Says:

    Thanks — I’ve corrected the article to distinguish between SFTP and FTP over SSH.