[ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]
Article: 14013 of comp.protocols.kermit.misc
From: email@example.com (Frank da Cruz)
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:
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
set host * 3000 /raw if fail exit 1 Incoming connection failed take scriptfilename
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:
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:
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:
From: firstname.lastname@example.org (Jeffrey Altman)
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 ]
Kermit Case Study 25 / Columbia University / email@example.com / 22 Jan 2003