Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Telnet/FTP-like Shells Implemented over Email

IP.com Disclosure Number: IPCOM000014313D
Original Publication Date: 2003-Jun-19
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 42K

Publishing Venue

IBM

Abstract

The most widespread of all information seeking protocols is arguably HTTP, the protocol of the World Wide Web. Almost any computer with a connection to the Internet has some form of a web browser. Particularly in handheld devices or shared computing environments such as public kiosks, the Internet interfaces available to the user may be exclusively limited to web browsers. Additionally, access to email is often available through web interfaces. This article describes an implementation of a command shell implemented over email that allows Telnet and FTP-type operations. The existence of such a system can provide value where a web browser is the user's only interface to the Internet yet this user wishes to have Telnet or FTP access to a remote server.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Telnet/FTP-like Shells Implemented over Email

One of the most common ways users interact with computer servers is through command line interfaces known as "shells". Sometimes users actually sit at the console of the machine and interact with a shell directly on the computer. More often, however, users interact with the shell remotely, using telnet, ssh, ftp, rexec, rlogin, remsh, rsh, and other remote execution protocols. For this interaction to be possible, there needs to be a continuously running background process ("daemon") of some sort listening on the server that authenticates sessions, executes commands, and returns the results back to the user. Additionally, the user must have the requisite client software available for use (telnet, ssh, ftp etc.). Sometimes, this client software is not available to the user even though their client terminal might be attached to a network. What is needed, then, is an alternative remote execution mechanism that almost certainly guarantees the availability of the client. A proposed solution is described within this article.

At a minimum, a client computer on the Internet must have some form of a web browser that can communicate over HTTP and optionally HTTPS (secure HTTP). The user must have an email account that can be accessed over a web interface. These two simple requirements are all that is necessary from the client's side to utilize this mechanism. At this point, the user can send and receive email messages almost instantly to their account which they access through a web browser on any computer on the Internet.

On the server side, a daemon is needed that processes incoming email. Email of a specific type, containing certain formatted instructions is then forwarded to another daemon that authenticates the user, executes specified operations, and returns the results back to the requesting user in the form of another email. These are the central ideas of the invention described in this article.

Command shells typically have a simplistic interface. The user initiates a session by providing identification and perhaps a password. The system authenticates the user and displays a prompt. At that prompt, the user issues some command. The system processes each command, executes the necessary process(es), and returns some output, and then leaves the user with another prompt. The cycle repeats indefinitely until the user exits the shell.

This very same process can be easily implemented using email. The user initiates a session by sending an email containing a username and password to a particular user on a server. If the credentials are acceptable, the server generates a session key and returns that information back to the user as a reply to the previous email. When the user receives their session key, they are then read...