C-Kermit Case Study #25

[ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]

Article: 14013 of comp.protocols.kermit.misc
From: [email protected] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Case Study #25: Remote Access
Date: Sat Jan 18 18:37:34 EST 2003
Organization: Columbia University

A question that comes in with increasing frequency is "How do I set Kermit up for incoming connections and offer the user a simple interface to choose among the services I want to provide?"

There are several aspects to this question. First is how to make Kermit accept incoming connections. This can be done with the ANSWER command if users are to dial in with modems, or with SET HOST * on the Internet. You can even run a Kermit script out of inetd. Of course remote access raises all sorts of other questions about authentication and security which are discussed elsewhere.

One form of remote access that also takes care of security is the Internet Kermit Service. This presents the user with either the Kermit program prompt and command interface or Kermit's server-mode packet interface. And for completeness, I should also mention Kermit 95's Host Mode.

But some people want to set up their own custom interface for incoming users. Kermit lets you do this too, on the following types of connections:

But no matter what way the user comes in, and leaving aside the question of authentication (for which there are many, many possibilities), we reach the point where the script needs to interact with the user, and quickly discover two problems:

  1. Commands such as ASK and ECHO do not communicate with the user. These commands are for use on Kermit's controlling terminal, not on its communications connection.

  2. In some cases (such as under inetd), Kermit doesn't even have a controlling terminal.

For these reasons, you must use the OUTPUT and INPUT commands to communicate with the user, and your script must perform all the functions of the terminal driver, which is not active in this case. This includes echoing of each character, echoing CR as CRLF, and processing of editing keystrokes such as Backspace and interrupts such as Ctrl-C. It's not as difficult as it sounds. To get you started, I've placed a new script in the script library, called remoteaccess. Here's the URL:

ftp://kermit.columbia.edu/kermit/scripts/ckermit/remoteaccess

This script should work in any relatively recent version of C-Kermit or Kermit 95. It gives the user just five commands: HELP, ECHO, LIST, SEND, and EXIT. You should be able to use it as a template in fill in any other commands you wish. For simplicity, it offers just a prompt-and-command interface. A formatted-screen BBS-style interface could be done too (as we have done, in fact, in Kermit 95 Host Mode). The script includes a "SET ROOT" command to prevent users from accessing any files outside the tree rooted (in this case) at its current directory; this is an essential command for anybody writing remote-access scripts.

A few other items in the script are worth mentioning:

[ Top ] [ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]


Kermit Case Study 25 / Columbia University / [email protected] / 18 Jan 2003