Access remote network services with SSH tools

You probably rely on the services on your own private network — wikis, mail servers, Web sites, and other applications you’ve installed. What happens when you have to leave the friendly confines of your network? With minimum exposure and few simple tools, you can get all of the comforts of home anywhere you can find an Internet connection.

To start, you need to be able to find your network when you’re out and about. If your network sits behind a static Internet Protocol (IP) address with a registered domain name, you’re all set. On the other hand, if your network accesses the Internet using an address assigned to it via Dynamic Host Control Protocol (DHCP), you have a little work ahead of you.

The simplest thing you can do is find your network’s IP address so you can access it directly using a service like Whatsmyip. Browse to that Web site from within your network and the resulting page will display the IP address that your network uses. This address is independent of any addresses you may have assigned to machines within your network — it’s the external network address of your gateway machine or router.

A problem with this approach is that your Internet service provider may periodically change you IP address. This probably doesn’t happen often, but it will almost certainly happen as soon as you’re counting on the ability to access your network.

To avoid this, you can use a dynamic Domain Name Service (DNS) client that detects when a new IP address has been assigned and notifies an external DNS service. The service updates the IP address assigned to a particular DNS name, which you then use to access your network. While the IP address may change, the DNS name will not.

Many routers support a variety of such services, as do open source router firmware replacements such as Tomato. DynDNS is one such service, and there are several others. Choose one supported by your router and sign up for an account. Often you can sign up for a free account where you are allowed to choose a hostname in one of a defined set of pre-existing domain names, or you can choose to pay for an account that allows for more flexibility in choosing a DNS name. Use the account information to configure your router, and from then on you can use your chosen host and domain name combination to access your network.

As long as you can find your network, you can access its services. The basis of this access will be the ssh command provided by the OpenSSH project. The ssh command provides secure access to systems running a Secure Shell server. The most typical usage is to remotely log into a command-line shell, but other features allow you to do a great deal more. Setting up SSH access to your systems from within your network is fairly easy with most Linux distributions.

To allow access to your network through your router, you will need to use port forwarding. With this technique, a router accepts a network connection on a particular port on the Internet side and relays all communication associated with that port to a machine on the local side of the network. The easiest thing to do is connect port 22 on the outside of the router to port 22 on one of the machines (the one running the SSH server) on your network.

Once you’ve set up the appropriate port forward and have configured a dynamic DNS service you should be able to go to your favorite coffee shop with Internet access and use ssh to connect to the host and domain that you’ve set up.

Log out, and this time use ssh -D 1080 to connect. This sets up a SOCKS proxy on port 1080 between your client and the machine that’s running your SSH server. A properly configured client can use this proxy to access other machines on your private network. Instead of connecting directly to, say, www.linux.com, the client will connect to the SOCKS proxy, the other end of which will connect to www.linux.com on its behalf. The traffic between the client and the remote server will be “tunneled” through the proxy connection. This means that any system that the remote server can “see” (including internal servers) can be seen by the client using the proxy. Additionally, the traffic between the machines travels through the encrypted SSH connection.

It’s possible to configure most network systems to use a SOCKS proxy for all clients, but you will run into problems if you try to connect to systems on the local network you are using — the remote system can’t “see” them. It’s easier to simply configure only the client and application you want to use to use the proxy.

Using Firefox 3 on Linux, select Edit -> Preferences -> Advanced -> Network -> Settings to bring up the dialog box pictured here:

Choose Manual Proxy Configuration. For SOCKS Host enter “localhost” and for port enter “1080.” That sets Firefox to use the SOCKS proxy you created with the ssh -D command.

There’s one more thing to do before you can use Firefox to browse your remote private network. In the Firefox location bar, type “about:config”. In the resulting window type “network.proxy.socks_remote_dns” in the Filter box to see the value of that configuration setting. If it’s presently false, double-click on it to turn it to true. This will force Firefox to use the remote server for its DNS requests. Since that server knows (through its own DNS settings) about the machines on the local network, so will Firefox.

Firefox should now be able to browse any of the sites on your remote network. But remember, if you’ve used the “socks_remote_dns” setting, you won’t be able to browse sites that are only available on your local network because your remote DNS server doesn’t know about them.

You can configure Thunderbird in a similar manner to allow it to see an internal IMAP server.

In addition to accessing network services from outside your network, you can also run non-network, GUI applications. For example, you could use the package manage Synaptic to review the packages installed on the remote system.

This is where the X Window System’s networking features come into play. When an application draws a window using the X Window System (or any of the GUI frameworks that use it, such as GTK for GNOME or Qt for KDE) it is actually making a request to draw that window to an X server. Typically that server is on the same machine as the application itself — but this is not a requirement. It is possible to make the drawing request to an X server that is running on some other machine on the network. This way, an application running on one machine can display its GUI on another machine. The application knows where to display its GUI by looking at the environment variable DISPLAY.

One drawback of this is that the X Display Protocol is not designed to be secure — a third party might be able to “watch” what you are doing with the application over the network. And of course the machine on which the application is running must be able to “see” the machine that is running the X server, which is not always possible with firewalls and other challenges in the way.

Here, SSH again provides a solution. If you use the -X option to ssh when you connect to a remote machine, it will create a proxy X server on the remote machine and set the DISPLAY correctly. Any X application that runs will send requests to that proxy. The proxy will forward those requests the “real” X server through the secure SSH connection.

You may need to adjust the configuration of SSH on the remote server to enable X11 forwarding. On most Linux distributions you do this by editing the file /etc/ssh/sshd_config and make sure that the variable X11Forwarding is set to “yes.” If you have to change it, be sure to restart sshd (on Ubuntu, /etc/init.d/sshd restart will do it). Also make sure that Xauth is installed in /usr/bin/xauth; it is used by SSH to authorize connections to its proxy server.

Now you should be able to access both network services and GUI applications on your remote network. You might also want to access files remotely. You can use the SSH-based scp command to copy files to and from the remote system, but that can become awkward and inconvenient if you are interested in more than one or two files.

You can, however, use the SSH Filesystem to mount files on the remote system. SSHFS is based on the Filesystem in Userspace (FUSE) project that allows the implementation of filesystems without requring modifictions to the kernel. SSHFS uses the secure SSH connection to provide convenient access to remote files. To use SSHFS you need to have it installed on your local (client) system. On Ubuntu, sudo apt-get install sshfs will take care of that. Then, you need a mount point — a directory on your local system in which you will see the remote files after you’ve mounted them. For example, you could create a directory called REMOTEMOUNT., then use it to mount your home directory on the remote system with the command sshfs dyndns.example.com: REMOTEMOUNT.

You do not have to use sudo to execute sshfs. When the command completes, if you run ls on the REMOTEMOUNT directory, you should see the contents of your remote home directory. You can work with these files as you would with any other files, bearing in mind that there may be delays as the file contents are transferred back and forth over the SSH connection.

If you run into permission problems, make sure that the account you’re using locally is a member of the “fuse” group. On many distributions, usermod -G fuse username will take care of this.

To disconnect, or unmount the system, use the command fusermount -u REMOTEMOUNT.

By using tools provided by the OpenSSH project, you can construct ad-hoc, high-level access to virtually all of the facilities of your own network when you are working remotely. By using these tools you can leave your network secure while reaping its advantages from anywhere on the Internet.