Accessing your home system from work or from around the world, using fetchmail, procmail and a few scripts.
![]()
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.
My Disconnected System
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.
Getting Connected
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 "e;NT"e; friends would be so jealous!
Locking It Down
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.
The Project
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:
- fetchmail - to get the mail
- procmail - to parse and execute the e-mail console script
- GnuPG - to decrypt the e-mail and verify the authenticity of the sender
The Disclaimer
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.
Understanding E-mail
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.
