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:

• Dialed, using the ANSWER command; for example:

  set modem type usrobotics
  set port /dev/ttyS0
  if fail exit 1 Port not available
  set speed 5700
  set flow rts/cts
  answer
  if success take scriptfilename
  

• Internet, using the SET HOST * command; for example:

  set host * 3000 /raw
  if fail exit 1 Incoming connection failed
  take scriptfilename
  

• Internet via inetd. In this case you would have Kermit execute your script as soon as a connection came in. In Unix, this requires an entry in /etc/inetd.conf to set up a service name and parameters, and one in /etc/services to associate the service name with a TCP port number. This one is a bit tricky and might also require a few of the recent fixes found in the C-Kermit daily builds (if anybody is interested in this option, speak up).

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:

• Command parsing is done by Kermit's \ftablelook() function, which allows for abbreviations, synonyms, etc.
• Alphabetic case is ignored via a simple setting (SET CASE OFF).
• The DOLIST macro shows how to construct and transmit a directory listing.
• All sorts of other features are illustrated: compact substring notation, array manipulation, extraction of array segments, splitting lines into words, etc etc.

From: [email protected] (Jeffrey Altman)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Case Study #25: Remote Access
Date: 22 Jan 2003 22:11:18 GMT
Organization: Columbia University

I want to point out that the Internet Kermit Service can be configured to execute any script the administrator wishes to have run when an end user connects. The options are not SERVER or command prompt; but SERVER or command processor.

The process for doing this is quite simple. Within the /etc/iksd.conf script the administrator defines an ON_LOGIN macro that is executed upon successful login. This macro can test for the type of login by examining the authtype, authname, and authstate variables. Based upon whether the login is an authenticated user or a guest, different access configurations can be applied and scripts can be selected.

The only reason for not using IKSD to provide a script to the end user is if the script requires access to external commands which are disallowed in IKSD configurations.

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