Editors' Note: The following is a chapter from the book Multitool Linux, written by Michael Schwarz, Jeremy Anderson, Peter Curtis and Steven Murphy. Consult the book's web site for links, updates and errata.

Question: How can I get access to my home Linux system when I'm 1)at work behind a firewall that only allows me to send e-mail from my workstation or 2)away on a business trip and the hotel firewall only allows me to surf the Web?

Answer: Create an e-mail-based console application that let's you execute commands and return results via e-mail. If you're stuck with only web access, get a web e-mail account somewhere and use it to send commands over e-mail to your system at home. The e-mail console is a nice way to communicate with your system when normal communications (Telnet, ssh, FTP, what-have-you) are not available.

Have you ever been sitting around at work and wished you could execute a command on your home Linux system to find some information? I have and I bet you could find lots of reasons why you would want to do this as well. E-mail is simple, yet powerful. But can it be used as a console to your home Linux system? You bet! I use it all the time.

But why not just log in and execute commands in the traditional manner? Sure, I could do that, but that would be no fun. In addition, there are times when direct access to a system is not available. But if e-mail is available, then this e-mail console application will work for you. First, I'll tell you about how I arrived at developing the e-mail console, then I'll share how I did it.

If you're like me, at one time you probably connected to the Internet using a standard phone line and a local ISP. I like my ISP, but they limit the number of hours I can be on-line each month and charge me big bucks when I go over that limit. I won't switch ISP's because they are, without a doubt, the best in my area. Because of this restriction to my on-line adventures, I pick and choose the times when my Linux system will be on-line fetching e-mail, downloading files and so forth. The problem I have with this situation is I want access to my home system when I am at work. And when I'm at work, I often find myself needing to access my home system to get a file. With my monthly limit, I can't simply leave my computer continuously connected to the Internet during the day. What I need is a way to keep my home system off-line until I need it and then have it go on-line and stay that way until I tell it to disconnect.

Some time ago I decided to make it so my system would periodically connect to the Internet and download e-mail from my ISP using a nifty program called fetchmail. I wrote a few Perl scripts to automate and synchronize the connection requests from various applications, including SETI@HOME and fetchmail, which both need to connect to the Internet at various times. Plus, I needed to go on-line to surf around but not get disconnected when the fetchmail utility completed its work. Getting e-mail with fetchmail allows me to spend as little connection time as possible getting and responding to e-mail—why waste connection time typing replies?

The main goal of these scripts is to coordinate the connection and disconnection requests and keep my system on-line when needed. It then occurred to me that if I could somehow send an e-mail to my system (which picked up e-mail once an hour) and somehow have that e-mail parsed, so a command could be executed, I could tell my system to stay on-line or disconnect. Bingo! Now all I had to do was find that e-mail parsing, command-executing, dream utility. The solution was right under my keyboard.

On a piece of paper beneath my keyboard was a list of utilities I thought might be useful for dealing with my e-mail; procmail was one of them. Procmail, as it turns out, is an incredibly useful utility for performing searches on incoming e-mail and then performing some kind of action. Currently, I use procmail to parse my incoming e-mail every 15 minutes (I changed it from an hour down to 15 minutes so I wouldn't have to wait so long to access my system). It executes the command that tells my system to stay on-line after it is done fetching e-mail. Now, I can send e-mail to my home system with a special subject like “CONNECT REMOTE”, and my system will simply stay on-line after fetching and processing all the e-mail from my ISP. In my procmail configuration file, a recipe file, I searched for this string and then executed the Perl script I had written to make it so my system stayed on-line. I could also tell it to disconnect. Once I had this set up, it occurred to me that with a little more work, I could write a procmail recipe and Perl script that would execute any arbitrary command I gave it. This was the coolest thing I had ever heard of, and my &quote;NT&quote; friends would be so jealous!

Because anyone can send me an e-mail, I had to work out a protocol that would allow me and trusted friends but no one else to execute commands. I also needed to ensure that the results were returned securely, safe from snooping eyes. The solution to all of this lies with encryption and digital signatures found in another great utility, GnuPG.

Now that you know the story of how the e-mail console came to be, it's time to put together all the pieces and make a working system. The following utilities are necessary for this project:

Doing this project could seriously damage your system. If you implement this project, anyone—and I mean anyone—on the planet with Internet access and an e-mail account has the potential to be able to execute any command—even as root—on your system. Please, do not attempt this project if you are not 100% sure you can secure your system from unauthorized use. In plain English, don't do this project unless you know what you are doing, and don't blame me if you screw it up and get your system hacked. I warned you. You know what? Just don't do it. Just read the [article] and learn. But don't do it. Imagine logging in one day to discover your hard disk has been wiped clean by some hacker who discovered he could send a simple e-mail containing a few simple commands to your system. You have been warned: do this project at your own risk.

E-mail comes in; e-mail goes out. Simple, right? Ah, not so my friend. Your e-mail requirements and my e-mail requirements are probably different. With this in mind, I'm going to take the easy way out and describe my e-mail setup. You cane work out for yourself how to adapt the e-mail console for your e-mail setup.

I use Exim as my mail delivery agent (MDA). This delivers incoming mail to my personal mail folder/file. On a side note, a mail transport agent (MTA) delivers mail between connected mail hosts. On yet another side note, a mail user agent (MUA) is the e-mail client program you use to read and send e-mail with. A lot of Linux distributions use sendmail as their MDA.

Whatever works for you should be fine. The key thing to remember is when using a MDA, local e-mail is delivered to your e-mail file, which is usually /var/ mail/your_account. Some Linux distributions might differ on this configuration. I'm going to assume you don't receive e-mail directly from the Internet but instead use an ISP to store e-mail for you. If you are set up with a DNS, a static IP and have direct Internet e-mail capabilities, stop reading because you probably know more about e-mail systems than I do.

When e-mail is waiting at your ISP, you have basically two ways to retrieve it. The first is to use a client e-mail program like KMail or Netscape Mail and retrieve your e-mail via POP or IMAP. The second option is to use fetchmail, which also uses POP or IMAP. It delivers your e-mail to your MDA, which then delivers the e-mail to your local account's mailbox (/var/mail/you_account). There are other ways to get your e-mail, but they are not relevant to this discussion.

Once the e-mail is in /var/local/your_account, you can use almost any e-mail client to retrieve it. This usually means transferring the e-mail to another folder in your home folder, .mail or Mail, or some other location.

In Part II we'll talk about fetchmail, procmail and how to make them work together.

Copyright 2002 by Addison-Wesley. All rights reserved. Reproduced by permission of Pearson Education, Inc.