## `Windows Internet Kermit Service - Administrator Guide`

> Max Evarts, The Kermit Project
> Columbia University, New York City

[ Contents ] [ WIKSD User Guide ] [ Kermit 95 Home ] [ Kermit Home ]

ABSTRACT: How to install, configure, and manage the Windows Internet Kermit Service: a standards-compliant File Transfer and Management Shell for Windows NT, 2000, and XP from the Kermit Project at Columbia University, available in free and secure versions.

`` As of Kermit 95 version: 3.0.0 DEV
`` This file last updated: 4 June 2002 (New York City time), with minor updates on 27 January 2025

IF YOU ARE READING A PLAIN-TEXT version of this document, it is a plain-text dump of a Web page. You can visit the original (and possibly more up-to-date) Web page here:

      http://kermitproject.org/wiksdadmin.html

This document applies to Windows NT and its descendents, which at this writing include Windows 2000 and Windows XP. When the term "Windows", "Windows NT", or "Windows NT/2000" is used in this document it refers to Windows NT, 2000, and XP, but not to Windows 95, 98, or Millenium Edition (which are sometimes referred to collectively as Windows 9x or Win9x). The Internet Kermit Service should NOT be installed on Windows 9x because (a) Windows 9x is insecure, and (b) it does not support background processes or "services". Any references to Windows 9x in this document are for completeness only and should not be construed as encouragement for running an unattended Internet Kermit Service on those operating systems.

Comments, suggestions, questions welcome. Open a discussion on github: `https://github.com/davidrg/ckwin/discussions`.

###

CONTENTS

      1. WHAT IS IKSD?
      2. INSTALLATION
      3. IKSD USERS
      4. RUNTIME CONFIGURATION OPTIONS
      5. ACCESS TO SERVICES
      6. MONITORING AND CONTROL
      7. OPEN ISSUES
      8. TESTING

###

1. WHAT IS IKSD?

[ Top ] [ Contents ] [ Next ]

The Microsoft Windows operating system was not originally designed or intended to allow remote access by ordinary terminal programs (such as Telnet clients). Yet users understandably wanted this type of open access ever since Windows was first announced. As soon as Kermit 95 announced in October 1995 (just after Windows 95 itself), users began demanding support for incoming connections. The result was "Host Mode", which in effect built a user-ID based authentication and file system onto a Windows 95 foundation that didn't have such a thing.

Windows NT (which actually predates Windows 95 by a couple of years, but did not become popular until much later) solves many of the same problems addressed by K95 Host Mode: a file system supporting authenticated users with a full range of access controls. Of course Windows NT is only the first in a series of NT-based operating systems, now including Windows 2000 and Windows XP. Kermit 95 Host Mode can be used on Windows NT and its descendents, but:

- It bypasses NT's authentication and access mechanisms rather than using them.
- The authentication process usually transmits passwords over the network in clear text.
- Host Mode sessions themselves are usually conducted in clear text.
- Host Mode runs as the user who started it (if not run as an NT Service).
- It pops up all sorts of text screens (ditto).
- Its range of functions is limited by its small menu.
- You have to buy Kermit 95 before you can install it on your PC.

Enter Windows IKSD.

IKSD is the Internet Kermit Service Daemon, a software program that offers a secure and flexible file-transfer and management service on the Internet, based on Telnet and Kermit protocols, that can be accessed from anywhere on the Internet, using the procedures specified in Internet RFCs 2839 and 2840, and supporting various IETF-standard security methods that can be negotiated with the client.

WIKSD is a version of IKSD for Windows NT, 2000, or XP, based on Kermit 95. It is not a "PcAnywhere" substitute (graphical desktop replicator), nor does it give you remote access to the "DOS" shell (more about this in the WIKSD User Guide) -- it is more like a high-function FTP server that gives you the options of interacting with it directly and of scripting its operation. WIKSD comes in two forms:

`Kermit 95`
  This is the regular full-featured Kermit 95 program, which can be started in a special manner that instructs it to be an Internet Kermit Service.

`Internet Kermit Service for Windows NT/2000/XP`
  This is a special version of Kermit 95 that runs as a Windows Service in the background and can only act as an Internet Kermit Service (it doesn't include terminal emulation or the ability to make connections).

Windows Internet Kermit Service allows both anonymous and authenticated text-mode access. As the PC owner, you can allow or disable anonymous access, and you can also restrict which users may and may not log in to your PC with IKSD. Anonymous users have restricted access rights; for example, they are not allowed to delete, overwrite, or modify existing files. Authenticated users have whatever rights are associated with their Windows NT identities, but both classes of users can, optionally, be restricted to a particular directory or directory tree.

IKSD can be useful in a variety of scenarios, such as:

- You have a PC at work that you want to access from home or other remote locations (or vice versa).
- You have a PC that you want to let other people, who are known to you, access remote remotely.
- You have a PC to which you want to allow general, unauthenticated (but safe) public access.
- You have a Windows domain with a file server but don't want to allow Windows file sharing outside the firewall, but still want to let authorized users access the file server.
- You have a Windows-based Web server and want to give content providers and designers the ability to maintain the website from remote locations.

Once authenticated, IKSD users can manage and transfer files, as they might do with an FTP server:

- Like FTP, Kermit provides a service that can be accessed from many different platforms with a consistent set of commands, but unlike FTP, these commands include programming constructions such as variables, arrays, looping and selection mechanisms, and local and remote procedure calls, thus allowing file transfer and management operations of arbitrary complexity to be easily automated.

- Like FTP, Kermit provides both text- and binary-mode data transfer, as well as file management capabilities. But Kermit also offers numerous features lacking from FTP, such as character-set translation, flexible file selection mechanisms, preservation of timestamps, automatic per-file text/binary mode switching (important in cross-platform transfers), cross-platform directory-tree transfer, and a selection of file collision options including "make backup copy of existing file and accept incoming file", "reject incoming file", "accept incoming file only if newer than existing file", etc.

- Unlike FTP, Kermit supports atomic file movement, in which the source file can be deleted (or renamed, or moved) when and only when it has been transferred successfully, as part of the transfer operation itself.

- Unlike most FTP implementations, Kermit supports recovery of interrupted (binary-mode) transfers from the point of failure. You can even use it to recover interrupted FTP transfers when FTP itself does not offer this option.

- Unlike standard FTP, Kermit can transfer data through firewalls or proxies or NATs on a single well-known port (unless the TCP port for the connection has been explicitly filtered).

- Unlike FTP, Kermit can transfer data across a combination of transports (e.g. dial-up to a terminal server and thence to an Internet host).

- Unlike FTP, IKSD can restrict even authenticated users to a specific directory or directory-tree.

- Authentication and data transfer can take place over secure connections (mutually authenticated and encrypted) using IETF-standard Telnet security (authentication and/or encryption) options.

IKSD can be accessed by any Telnet client that allows specification of TCP socket 1649. If you also want to transfer files, the Telnet client must also support the Kermit file-transfer protocol (when IKSD is Kermit 95 rather than the free IKSDNT version, other protocols such as Zmodem are also supported). The clients that work best are:

- C-Kermit 7.0 or later for UNIX, VMS, etc.
- Kermit 95 1.1.20 or later for Windows 96/98/ME/NT/2000/XP
- MS-DOS Kermit 3.15 or later for DOS or Windows 3.x

Other clients might or might not support:

- Autodownload and autoupload
- Automatic text/binary-mode switching
- Client/server features
- Automatic client/server mode matching
- Fast file transfer
- Character-set translation
- etc etc.

A Unix-based IKSD was available for public access at:

      kermit.columbia.edu, port 1649

IKSD is a Kermit program configured to run only as an Internet service. It includes the full command and scripting language. If you are unfamiliar with the Kermit command language, it is documented in:

> Frank da Cruz and Christine M. Gianone, Using C-Kermit, Second Edition, Digital Press / Butterworth-Heinemann, Woburn, MA, 1997, 622 pages, ISBN 1-55558-164-1.

Potential WIKSD administrators might also find it helpful to consult the following pages at the Kermit website:

`http://kermitproject.org/k95tutor.html`
  Kermit 95 Tutorial
`wiksduse.html`
  Windows IKSD User Guide
`http://kermitproject.org/ckututor.html`
  Unix C-Kermit Tutorial
`http://kermitproject.org/iksd.html`
  Unix IKSD Administrator Guide
`security.html`
  Kermit Security Reference
`telnet.html`
  Kermit Telnet Client Reference

###

2. INSTALLATION

[ Top ] [ Contents ] [ Next ] [ Previous ]

      2.1. InstallShield Installation
      2.2. Manual Installation

> Any material in this section or following sections relating to configuration of Windows NT users and file system settings to accomodate IKSD should be viewed as suggestions only. You might already have a scheme of users, groups and file system permissions that can be used or adapted to accomodate IKSD. In any case, installation of IKSD as described here should have little impact on your overall NT configuration. In concept, it is about the same as installing an FTP server.

The Internet Kermit Service for Microsoft Windows operating systems is provided as a standalone program (`IKSDNT.EXE`) and as a part of the Kermit 95 product (in which case `K95.EXE` acts as IKSD). The IKSDNT package contains the following files:

`IKSD.EXE`
  A program used to start Internet Kermit Service as a user process (Win9x only).
`IKSDSVC.EXE`
  A program used to start the Internet Kermit Service as a Windows NT service.
`IKSDNT.EXE`
  The Internet-Kermit-Service-only version of Kermit 95.

Kermit 95 1.1.21 and later include Internet Kermit Server capability and do not require the use of `IKSDNT.EXE`. `IKSDSVC.EXE` executes `K95.EXE` when `IKSDNT.EXE` is unavailable. Thus `IKSDNT.EXE` need be installed or used only on PCs where Kermit 95 is not installed.

WIKSD is normally installed as a Windows NT Service (background process), meaning it is started automatically every time Windows itself starts, and therefore is available to clients whenever Windows is running on your PC and your PC is on the Internet. Thus, conceptually, it is like an FTP server. Users can access it from outside, but you can't see it on your screen, unless you make a localhost connection to it (e.g. "iksd localhost" at the `K-95>` prompt).

It is strongly recommended that IKSD be installed only on Windows NT, 2000, or XP systems with all-NTFS file systems. FAT file systems do not support any of the file access controls you need when your PC disk is accessed by multiple remote users. To convert a FAT file system to NFTS, use the CONVERT command in the Command Window (type "help convert" in the Command Window for instructions).

You can install WIKSD in the normal, easy Windows way (from the Kermit 95 installer package) or for greater control over the configuration, you can install it manually.

###

2.1. Installation

[ Top ] [ Contents ] [ Section Contents ] [ Next ]

Installation Packages have not been prepared for this version of Kermit 95 yet. See the next section for manual installation instructions

###

2.2. Manual Installation

[ Top ] [ Contents ] [ Section Contents ] [ Previous ]

      2.2.1. Installing IKSD as a Service
      2.2.2. Installing IKSD as a User Process
      2.2.3. Windows NT/2000/XP Folder Permissions
      2.2.4. SRP and Windows NT/2000/XP
      2.2.5. SRP and Windows 95/98/ME

Manual installation of WIKSD is possible only if you installed Kermit 95 without choosing to install WIKSD, or if you uninstalled WIKSD after first installing it.

To install the Internet Kermit Service on any Microsoft Windows Operating System:

1. Copy the IKSD files to your K95 directory (or a directory of your choice if Kermit 95 is not installed.)

2. (optional) Edit the `SERVICES` file to include a "kermit" service entry:

         kermit   1649/tcp

   On Windows NT/2000/XP, edit the file:

         %SystemRoot%\SYSTEM32\DRIVERS\ETC\SERVICES

   (On Windows 95/98/ME, the file is `C:\WINDOWS\SERVICES`.)

3. If desired, create an IKSD configuration file: `IKSD.KSC`. This file can be located either in the K95 directory, or in the SCRIPTS subdirectory of the K95 directory (see Section 4.4).

4. Go to Section 2.2.1 if you are installing on Windows NT/2000 and wish to install IKSD as a Service; Otherwise, go to Section 2.2.2.

###

2.2.1. Installing IKSD as a Service

[ Top ] [ Contents ] [ Section Contents ] [ Subsection Contents ] [ Next ]

Also see the following Microsoft Knowledge Base articles:

- How to Restore the Default NTFS Permissions for Windows 2000 (Q266118)
- Default NTFS Permissions in Windows NT (Q148437)
- Default NTFS Permissions in Windows 2000 (Q244600)

Installation as an NT Service enables users to access the Internet Kermit Service at any time and independent of the user logged into the system. To install WIKSD as a service you must be logged in with an account that is a member of the "Administrators" group.

1. Install the WIKSD service by executing the command:

         iksdsvc.exe -i

   This installs WIKSD as a Service which starts automatically every time Windows starts. WIKSD is started using the "LocalSystem" account. The service name is "IKSD".

   Use Control Panel --> Administrative Tools --> Services to change these settings. If an account other than the "LocalSystem" account is to be used for starting WIKSD, the account must have the "Act as part of the Operating System" privilege. Use of the LocalSystem account restricts the access of WIKSD to the local machine. All attempts at network access are denied.

2. You can stop, start, pause, and restart the WIKSD service from Control Panel --> Administrative Tools --> Services, or with the NET command: NET START IKSD, NET STOP IKSD.

###

2.2.2. Installing IKSD as a User Process

[ Top ] [ Contents ] [ Section Contents ] [ Subsection Contents ] [ Next ] [ Previous ]

(This section applies only to Windows 9x/ME.)

Start IKSD "by hand" in the Command Window simply by typing "iksd" at the prompt in the K95 directory.

If you wish to have WIKSD autostart each time you login to Windows:

1. Choose Start Menu-->Settings->Task Bar and Start Menu ...
2. Select the Advanced Page
3. Choose Add...
4. Specify the file `k95path\iksd.exe`
5. Place the Shortcut in Start Menu-->Programs-->Startup
6. Specify the name as "Internet Kermit Service"
7. Press Finish

Now the Internet Kermit Service will start automatically each time you login to Windows.

###

2.2.3. Configuring Windows NT/2000/XP Folder Permissions

[ Top ] [ Contents ] [ Section Contents ] [ Subsection Contents ] [ Next ] [ Previous ]

By default, Windows NT leaves the file system wide open. These operating systems rely on applications like drive and folder sharing or IIS (Internet Information Server) to handle keeping users restricted to certain directories and directory trees. To some extent you can also use IKSD to limit access in the same way using the IKSD configuration file (see the SET ROOT command in Section 4.1 below). But to fully secure your system and to implement special permissions schemes, like the incoming folder for the anonymous account, you will need to make some adjustments to the default folder permissions. (This assumes that you are using NTFS drives; if you are not, or you are running 95/98/ME, then you can use only IKSD mechanisms for restricting users -- see SET ROOT and the discussion of the ON_LOGIN macro in Section 4.)

The Everyone Group
  This is a special group to which everyone must belong. You cannot remove this group and membership is not optional; therefore the Anonymous ID account (e.g. Guest) is a member of this group. By default, the Everyone group has full control over all drives, and therefore by inheritance, over all folders. An IKSD-enabled system should remove the Everyone group from the permissions for each drive:

  1. In My Computer, right-click on the drive and select Properties.
  2. Clicking on the Security tab.
  3. Remove the Everyone group.
  4. You should now add in at least the Administrators group with Full Control and possibly the Users group with either Full or some custom set of permissions; otherwise you won't have permissions to make changes to the drive at all!

Inherited Permissions
  To isolate certain folders with special permissions it is necessary to tell Windows not to inherit permissions from the parent folder. We want anonymous users to be able to deposit files here, but not be able to download anything or even view a directory listing of files in this folder (to keep your PC from becoming a "warez" repository for software pirates).

  > The following procedure applies to Window 2000 (and most likely XP); in Windows NT 3 and 4 the concepts and permissions are the same, but the tools are not as well-developed.

  After creating a folder for incoming files in the anonymous user's directory tree, bring up the Security page under the Properties for the new folder. Then:

  1. Uncheck the box next to "Allow inheritable permissions..."
  2. Click "Remove" to reset the permissions for this folder.
  3. You should now see that the "Name" box is empty.
  4. Now click "Add" and add in the "Administrator" account with Full Control.
  5. Next "Add" the "Guest" account (or whatever user you have designated as the anonymous access account).

  Now set the exact permissions required for the incoming directory:

  1. With Guest highlighted in the Name box, click "Advanced".
  2. This brings up the "Access Control Settings" dialog.
  3. Make sure Guest is highlighted and then click "View/Edit".

  Check the boxes as follows:

  Permission | Allow | Deny
  --- | --- | ---
  Traverse Folder / Execute File | `[x]` | `[ ]`
  List Folder / Read Data | `[ ]` | `[x]`
  Read Attributes | `[ ]` | `[x]`
  Read Extended Attributes | `[ ]` | `[x]`
  Create Files / Write Data | `[x]` | `[ ]`
  Create Folders / Append Data | `[ ]` | `[x]`
  Write Attributes | `[ ]` | `[x]`
  Write Extended Attributes | `[ ]` | `[x]`
  Delete Subfolders and Files | `[ ]` | `[x]`
  Delete | `[ ]` | `[x]`
  Read Permissions | `[ ]` | `[x]`
  Change Permissions | `[ ]` | `[x]`
  Take Ownership | `[ ]` | `[x]`

This gives anonymous users the ability to upload files, but not to see them, read them, copy them, send them, delete them, rename them, or overwrite them, but leaves you full rights over the uploaded files.

NOTE: Since anonymous users can't delete or overwrite files in the Incoming directory, it won't be possible for them to upload a file when a file of the same name is already there. In this case they can use an as-name, or else tell IKSD to "set file collision rename", meaning to give a new name to the incoming file.

###

2.2.4. Secure Remote Password and Windows NT/2000/XP

[ Top ] [ Contents ] [ Section Contents ] [ Subsection Contents ] [ Next ] [ Previous ]

Note: SRP is no longer a standard feature as of Kermit 95 v3.0 - you must build it from source using old and insecure libraries if you need it.

On Windows NT/2000/SP, Secure Remote Password (SRP) can be used in with the local user accounts by installing a DLL (`SRPFILTR.DLL`) into the Windows System directory and inserting a record into the Registry:

      HKEY_LOCAL_MACHINE\
       SYSTEM\
       CurrentControlSet\
       Control\
       Lsa\
       Notification Packages (value of type REG_MULTI_SZ)

A value of type REG_MULTI_SZ allows multiple strings to be inserted at the same time. Do not delete any existing strings; just add the string "srpfiltr" to the list. Once this is done:

- Run `SRP-TCONF.EXE` to create the machine specific configuration info.
- Reboot the computer.

Now whenever a password is changed on the local machine an SRP password hash is also created, allowing SRP to be used as an authentication method with IKSD.

###

2.2.5. Secure Remote Password and Windows 95/98/ME

[ Top ] [ Contents ] [ Section Contents ] [ Subsection Contents ] [ Previous ]

Note: SRP is no longer a standard feature as of Kermit 95 v3.0 - you must build it from source using old and insecure libraries if you need it.

> (This section is informational only. WIKSD is not supported on Windows 95, 98, or ME.)

On Windows ME or 98 (and 95 with Internet Explorer 4.0 or higher installed) SRP can be used in conjunction with the local user accounts by installing a DLL (`SRPW95PP.DLL`) into the Windows System directory and inserting a new key block into the Registry:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\PwdProvider\SRP

In this key, the following values must be set:

      ProviderPath=srpw95pp.dll
      Description=Secure Remote Password
      ChangePassword=PPChangePassword
      GetPasswordStatus=PPGetPasswordStatus

Once this is done:

- Run `SRP-TCONF.EXE` to create the machine specific configuration info.

- Reboot the computer.

To change the SRP password to be the same as the Windows logon password:

- In Control Panel, double-click Passwords, and then click Change Windows Password.

- In the Change Windows Password dialog box, select the Secure Remote Password to use the same password as the Windows password, and then click OK.

- In the second Change Windows Password dialog box, type the current (old) Windows password, type a new password, and then in the Confirm new password box, type the new password again. Click OK.

To change the SRP password without changing the Windows logon password:

- In Control Panel, double-click Passwords, and then click Change Other Passwords.

- In the Select Password dialog box, select Secure Remote Password, and then click Change.

- In the Change Password dialog box, type the current (old) SRP password, type a new password, and then, in the Confirm new password box, type the new password again. Click OK.

###

3. IKSD USERS

[ Top ] [ Contents ] [ Next ] [ Previous ]

      3.1. The Anonymous User
      3.2. The "Regular" User

Users of IKSD map to Windows users. As we know, Windows 95/98/ME does not offer much control over users and how they can interact with the system. Fortunately, many of these shortcomings can be overcome with the configuration features of IKSD (see Section 4). Windows NT/2000/XP, however, allows detailed control over users' permissions, home directories, and so on.

Typically, one might have at least three classes of users:

1. Anonymous users, whose access is restricted to a specific part of the file system.

2. Regular users, who operate out of a home directory where they can read and write files. These users could also have access to other shared file areas where they can only read.

3. Administrator-level users who have full control over the entire file system.

###

3.1. The Anonymous User

[ Top ] [ Contents ] [ Section Contents ] [ Next ]

Although the default GUEST user on NT/2000/XP systems is a possible candidate for mapping to the IKSD ANONYMOUS user, it might be better to create a new user for this purpose. Since the IKSD ANONYMOUS user must be so carefully restricted to a specific part of the file system, making the necessary modifications to the GUEST user's permissions might have side effects you don't want. If this a concern to you, create a new user, make sure that it is not a member of the EVERYONE group, and use the SET IKS ANONYMOUS ACCOUNT command to tell IKSD to use this account. Give this user file permissions only on a folder that you designate for anonymous users. You can then "jail" the user to this folder with SET IKS ANONYMOUS ROOT command, which takes the place of operating-system-level file security for Windows 9x.

###

3.2. The "Regular" User

[ Top ] [ Contents ] [ Section Contents ] [ Previous ]

In NT/2000/XP, IKSD users map to existing Windows users in a Domain that the IKSD server is a part of. IKSD prompts for the user's ID (or Domain\ID) and the user's password for that domain. (See the `SET` `IKS` `DEFAULT-DOMAIN` command.) Once the user is logged in, they have the same privileges and permissions they have if they had logged in to the machine locally. If the NT user had a home directory defined, this is where they start. (See How the user's home directory is determined below.) One would use NT's control over file permissions to determine where the user would have rights to read, list, write, etc...

If user-level access is activated in Windows 95/98/ME, then the defined user names can be used to log in, every user has full read/write access to all the files on the PC.

###

4. RUNTIME CONFIGURATION OPTIONS

[ Top ] [ Contents ] [ Next ] [ Previous ]

      4.1. The IKSD Configuration File
      4.2. The K95 Initialization File
      4.3. System Logging
      4.4. The Transfer Log File

The IKSD can be configured at runtime by a configuration file and an initialization file.

And in Windows 9x/ME only, when using `IKSD.EXE` to start IKSD as a user process, you can include the following command-line parameter:

`--port:number` (or service name)
  By default, `IKSD.EXE` offers the Internet Kermit Service on the port specified in the `SERVICES` file as "kermit". If no "kermit" TCP service is specified in the `SERVICES` file, then the official port, 1649, is used. This option allows you to specify an alternative port IKSD number without modifying the `SERVICES` file.

When Kermit 95 is started as IKSD (or IKSDNT is started), it obtains its configuration in the following sequence:

1. It executes the IKSD Configuration File, `IKSD.KSC`, from the same directory where K95 (or IKSDNT) executable is kept (or the SCRIPTS subdirectory of that directory). The IKSD configuration file is executed before the TCP/IP connection is opened, before the Kermit 95 initialization file is read, and before the user logs in. The commands in this file specify how incoming TCP/IP connections are handled (Telnet negotiations, authentication and encryption requirements, login processing, anonymous and user initialization files, ...). Note: IKSD's current directory at this point is `WINNT\System32`. If you include a CD command in `IKSD.KSC`, e.g. to `C:\PUBLIC`, this changes the default directory (used in case the user does not have a "Home Folder") to something less scary.

2. IKSD waits for the user to login or authenticate.

3. As soon as the user is authenticated, IKSD executes the ON_LOGIN macro, if one is defined. Thus the place to define an ON_LOGIN macro would be the `IKSD.KSC` file. The current directory is changed to the user's Home Folder, if one is defined.

4. The Kermit 95 Initialization File, `K95.INI`, if any, is executed from the user's home directory. Note that `K95.INI` is the only initialization file that is executed automatically. By convention this file itself executes a second, "customization" file called `K95CUSTOM.INI`, but that is only a convention -- it is not built into Kermit 95. Thus if `K95.INI` does not exist no initialization file is executed automatically.

5. At this point IKSD is ready to execute commands from the user, either directly or from the client.

6. When the user logs out, the ON_LOGOUT macro is executed, if one is defined.

7. When Kermit (IKSD) exits, the ON_EXIT macro is executed, if one is defined.

The ON_LOGIN macro lets you enforce your per-user policies, limited only by your imagination. Here's a suggestion:

      define ON_LOGIN {
        switch \v(user) {
          :olga
    	echo Hi Olga
    	set root c:/olga
    	break
          :olaf
    	echo Hello Olaf
    	break
          :default
    	echo Welcome \fcapitalize(\v(user))
      }

This gives a custom greeting to Olga and Olaf and a standard greeting to everyone else. It also uses the SET ROOT command to restrict Olga to her own directory tree:

`SET ROOT directoryname`
  Similar to the Unix "chroot" command. It changes Kermit's root directory to the one given, confining IKSD users to a particular directory tree. Once a SET ROOT command has been executed, it can't be undone; thus users can't give another SET ROOT command unless it gives them even narrower access than the previous one.

Another command of particular interest in this regard is DISABLE, with which you can prevent certain users from doing certain kinds of things, like uploading files, deleting files, creating directories, etc.

###

4.1. The IKSD Configuration File

[ Top ] [ Contents ] [ Section Contents ] [ Next ]

The IKSD configuration file can contain any Kermit commands, functions or built-in variables but:

- Since the connection has not been established variables such as `\v(user)`, `\v(ipaddr)`, `\v(line)` are not yet defined. However, they can be referenced in the ON_LOGIN macro, which is executed when the user logs in. Thus `IKSD.KSC` can define an ON_LOGIN macro that does whatever you (the PC owner) want it to do, for example deny or restrict various kinds of access for certain users, print a greeting message customized for the particular user, etc.

- Macros defined in the initialization files have not been loaded yet.

- All SET commands may be overriden by subsequent initialization file processing.

- Since there is no connection all output from commands including error messages is lost.

The following commands can be executed only in the IKSD Configuration file or in the ON_LOGIN macro. These commands are ignored if they are executed after the user is logged in.

`SET IKS ANONYMOUS ACCOUNT username`
  On Windows NT/2000 this is the account that will be used to allow anonymous access to the system. This account MUST have no password and its privileges should be restricted to only allow those operations which should be permitted to unknown users. In practice this means List Directories and Read-Execute privileges only. If a directory is configured for Write privileges then Read privileges should be denied for that directory. Otherwise, your system will become used by software piraters. If this command is not specified in the `IKSD.KSC` file the username "GUEST" is used by default. This command has no effect on Windows 95/98/ME.

`SET IKS ANONYMOUS INITFILE filename`
  The initialization file to be executed for anonymous logins. By default, it is K95.INI in the home directory associated with the ANNONYMOUS ACCOUNT. Any filename that you specify here must be readable by the ANONYMOUS ACCOUNT and if a SET IKS ANONYMOUS ROOT command is issue, exist within restricted directory tree. This option is independent of the SET IKS INITFILE command which applies only to real users.

`SET IKS ANONYMOUS LOGIN { ON, OFF }`
  Whether anonymous logins are allowed. By default, they are NOT allowed, so this option need be included only to allow them (or for clarity, to emphasize that they are not allowed). Anonymous login occurs when the username "anonymous" is specified with any password (as with ftpd). In order for anonymous logins to succeed on Windows NT/2000, the ANONYMOUS ACCOUNT must be enabled.

  On Windows NT, 2000, and XP, anonymous users have the same access rights as the ANONYMOUS account. In Windows 95/98/ME, anonymous users, just like any other users, have full access rights to your entire PC, since Windows 9x has no file-system security. For this reason, if you are allowing anonymous logins, be sure to also specify a SET IKS ANONYMOUS ROOT directory to restrict anonymous users to.

  ANONYMOUS user permissions may be restricted via the specification of DISABLE commands in the ANONYMOUS INITFILE. ANONYMOUS users are not permitted to execute an ENABLE command. ANONYMOUS users are also prevented from SHOWing sensitive data about the operating system or the IKS configuration.

`SET IKS ANONYMOUS ROOT directory`
  Specifies a directory tree to which anonymous users are restricted after login.

`SET IKS BANNERFILE filename`
  The name of a file containing a message to be printed after the user logs in, in place of the normal message (Copyright notice, "Type HELP or ? for help", "Default transfer mode is...", etc).

`SET IKS CDFILE filelist`
  When cdmessage is on, this is the name of the "read me" file to be sent. Normally you would specify a relative (not absolute) name, since the file is opened using the literal name you specified, after changing to the new directory. Example:

        SET IKS CDFILE READ.ME

  You can also give a list of up to 8 filenames by (a) enclosing each filename in braces, and (b) enclosing the entire list in braces. Example:

        set iks cdfile {{./.readme}{READ.ME}{aaareadme.txt}{README}{read-this-first}}

  When a list is given, it is searched from left to right and the first file found is displayed. The default list for UNIX is:

        SET IKS CDFILE {{./.readme}{README.TXT}{READ.ME}}

`SET IKS CDMESSAGE { ON,OFF,0,1,2 }`
  For use in the Server-Side Server configuration; whenever the client tells the server to change directory, the server sends the contents of a "read me" file to the client's screen. This feature is On by default, and operates only in client/server mode when ON or 1. If set to 2 or higher, it also operates when the CD command is given at the IKSD> prompt. Synonym: SET IKS CDMSG.

`SET IKS DATABASE { ON, OFF }`
  This command determines whether entries are inserted into the SET IKS DBFILE which can be viewed with the `IKSDPY.KSC` script (Section 6.4).

`SET IKS DBFILE filename`
  Specifies the file which should be used for storing run time status information about active connections. You should use something like:

        \v(exedir)iksd.db

`SET IKS DEFAULT-DOMAIN domain-name`
  A userid on Windows is of the form Domain\Userid. This command determines which domain is searched for the Userid if a Domain is not specified by the user. On Windows 95/98/ME when user-level access is activated in the Network Control Panel, the default domain is automatically set. If the default domain is not specified, accounts on the local machine take precedence over accounts in Domains to which the local machine belongs.

`SET IKS HELPFILE filename`
  Specifies the name of a file to be displayed if the user types HELP (not followed by a specific command or topic), in place of the built-in top-level help text. The file need not fit on one screen; more-prompting is used if the file is more than one screen long if COMMAND MORE-PROMPTING is ON, as it is by default.

`SET IKS INITFILE filename`
  Execute "filename" rather than the normal initialization file for real users; this option does not apply to anonymous users.

`SET IKS NO-INITFILE { ON, OFF }`
  Do not execute an initialization file, even if a real user is logging in.

`SET IKS SERVER-ONLY { ON, OFF }`
  If this option is included on the IKSD command line, the Client Side Server configuration is disabled, and the user will not get a Username: or Password: prompt, and will not be able to access the IKSD command prompt. A FINISH command sent to the IKSD will log it out and close the connection, rather than returning it to its prompt.

`SET SYSLOG { LOGIN, FILE-CREATE, FILE-ACCESS, COMMANDS, NONE }`
  Windows NT/2000/XP only: Level of event logging. The term SYSLOG is used for compatibility with the Unix version of IKSD, and in NT refers to the Event Log. LOGIN logs only session begin and end. FILE-CREATE also logs file creation; FILE-ACCESS also logs all forms of file access; COMMANDS logs every command each user issues. NONE disables IKSD event logging.

`SET IKS TIMEOUT number`
  This sets a limit (in seconds) on the amount of time the client has to log in once the connection is made. If successful login does not occur within the given number of seconds, the connection is closed. The default timeout is 300 seconds (5 minutes). A value of 0 or less indicates there is to be no limit.

`SET IKS XFERLOG { ON, OFF }`
  Whether a wu-ftpd-like log should be kept. Off by default. This log is explained in Section 5.3.

`SET IKS XFERFILE filename`
  Use this option to specify an IKSD log file name. If you include this option, it implies SET IKS XFERFILE ON.

The IKSD configuration file can define three special macros which cannot altered or SHOWed by logged-in users: ON_LOGIN, ON_LOGOUT, ON_EXIT. These macros are used to define operations the Administrator wants to have executed at special moments during the session lifetime:

`ON_LOGIN`
  The ON_LOGIN macro is an extension of the IKSD configuration file which is executed after the user has been authenticated and logged into their account but before the user's or anonymous initialization file is processed. This is a final opportunity for the IKSD Configuration file to implement restrictions on the user's behavior based upon the authenticated identity of the user. The ON_LOGIN macro can define ON_LOGOUT and ON_EXIT macros.

`ON_LOGOUT`
  The ON_LOGOUT macro is executed after the user has closed the connection or issued the EXIT, LOGOUT, or REMOTE LOGOUT commands but before the user is logged out of the system. This is an opportunity for the administrator to implement cleanup procedures that must be executed with the privileges of the user.

`ON_EXIT`
  The ON_EXIT macro is executed after the user has been logged out of the system and the privileges of the WIKSD process have been restored to the those of the LocalSystem account when run as a Service on Windows NT/2000. This is an opportunity for the Administrator to implement cleanup procedures that must be executed with the maximum privileges allowed.

How the user's home directory is determined
  The Home directory is retrieved from the user's profile. If not, the current directory at the time login occurs is used. This directory will be the startup directory unless it is altered via a CD command in the IKSD Configuration file. The startup directory is the directory `IKSD.EXE` is executed in or the Windows System directory when IKS is run as a Windows NT service.

  For anonymous users, the home directory is as specified in the ANONYMOUS ACCOUNT's profile; or the directory specified by the SET IKS ANONYMOUS ROOT command.

Specifying Telnet Option Policies and Configuration Information
  The IKSD Configuration File is the one place where SET TELOPT and SET AUTH commands can be specified to alter the behavior of the TCP/IP connection processes. See

        security.html
        telnet.html

  for details on how Telnet and Authentication policies can be set.

Examples:

No `IKSD.KSC` file:
  Starts the Internet Kermit Server with all defaults in effect:

  - No anonymous logins
  - CD Message Files are typed to the user
  - K95.INI file in the home directory of the logged-in user is executed
  - All other Kermit defaults are in effect.

`IKSD.KSC` file contains:

        SET SYSLOG COMMANDS

  As above, but with all user commands going to the Event Log (Section 4.3).

`IKSD.KSC` file contains:

        SET IKS ANONYMOUS LOGINS ON
        SET IKS CDFILE READ.ME

  Starts the IKSD with anonymous access enabled and changes the name of CD message file from the default list to READ.ME.

`IKSD.KSC` file contains:

        SET IKS ANONYMOUS LOGINS ON
        SET IKS ANONYMOUS ACCOUNT KERMIT\\GUEST
        SET IKS CDFILE README.TXT
        SET IKS SERVER-ONLY ON

  Starts the IKSD with anonymous access enabled; sets the account to use for anonymous logins; and changes the name of CD message file from the default list to `README.TXT`. Note that the backslash separating the Domain (Kermit) from the Username (Guest) must be doubled, since this is a Kermit command.

`IKSD.KSC` file contains:

        SET IKS ANONYMOUS LOGINS OFF
        SET SYSLOG COMMANDS
        SET AUTH TLS RSA-CERT-FIL D:/OPENSSL/CERTS/TELNETD-RSA.PEM
        SET AUTH TLS RSA-KEY-FIL  D:/OPENSSL/CERTS/TELNETD-RSA.PEM
        SET AUTH TLS DSA-CERT-FIL D:/OPENSSL/CERTS/TELNETD-DSA.PEM
        SET AUTH TLS DSA-KEY-FIL  D:/OPENSSL/CERTS/TELNETD-DSA.PEM
        SET AUTH TLS CIPHER ALL:+DSS:+RSA:ADH
        SET AUTH TLS VERIFY PEER
        SET TELOPT START-TLS REQUIRED
        SET TELOPT AUTH REQUIRED
        SET TELOPT KERMIT REQUIRED REQUIRED

  Starts the IKSD with anonymous access forbidden; logs all commands; configures the server's X.509 certificates for TLS; requires the use of TELNET START-TLS for privacy and integrity protections; requires the use of an authentication method such as NTLM, SRP, ... for end user identification; and requires the use of TELNET KERMIT negotiations.

###

4.2. The K95 Initialization File

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

When a real user logs in to the IKSD, the Kermit-95 initialization file, `K95.INI`, is executed from the user's Home Directory as specified in the user's profile. The initialization file in turn executes the user's customization file, `K95CUSTOM.INI`. If the global (or user's) environment contains a `K95.INI` entry the specified initialization file is executed instead; this may, in turn, execute a customization file out of the user's home directory. You may override Kermit-95's automatic selection of initialization with the SET IKS NO-INIT and SET IKS INITFILE commands.

The initialization and customization files can contain any Kermit commands at all. Of particular interest in this context:

`IF [ NOT ] IKSD command(s) ...`
  This is a regular IF command. It can have an ELSE part (or not) and multiple commands can be bracketed in the normal way. The IKSD condition is true if Kermit is acting as an Internet Kermit Server.

> `IKSDNT.EXE` is missing numerous commands that are found in the regular `K95.EXE` program. Any such commands found in the initialization or customization files will cause error messages. To avoid the messages, either remove commands, specify a different initialization file with the appropriate SET IKS command, or prefix each such command with IF NOT IKSD.

For anonymous users, the default initialization file, if any, is `K95.INI` in the home directory for the ANONYMOUS ACCOUNT or as specified with the SET IKS ANONYMOUS INITFILE command. It is extremely important that the ANONYMOUS INITFILE file exist and not provide write permission to the ANONYMOUS ACCOUNT. Otherwise, guests could alter the contents of the file.

The system administrator may include commands in this file to disable selected services for anonymous users, e.g.:

      disable delete  ; Don't let anonymous users delete files  (***)
      disable send    ; Don't let anonymous users send files

Of course, any Kermit commands at all may be included: settings, macro definitions, etc (also see Section 7.5).

When the sysadmin specifies the initialization file, this allows a high degree of fine-grained control over who is allowed access to what commands and resources, using standard Kermit-95 commands, functions, and variables. The following are particularly useful:

`\v(date)`, `\v(ndate)`
  The current date, in case you want to restrict access by date. (Also read about the new date-related functions in the C-Kermit 7.0 and 8.0 update notes.

`\v(day)`, `\v(nday)`
  The day of the week, in case you want to restrict access to certain days of the week.

`\v(home)`
  The user's home directory.

`\v(host)`
  The hostname of the IKS.

`\v(ipaddress)`
  The IP address of the IKS. This and/or `\v(host)` may be used when you are running an IKS on multiple hosts and want to have different setups on each, but still have a common initialization file.

`\v(line)`
  The IP host name or address of the client's host.

`\v(time)`, `\v(ntime)`
  The current time of day, in case you wish to restrict access to certain times of day.

`\v(userid)`
  The ID with which the user logged in to the IKS. For anonymous logins, this is "anonymous".

`\v(authname)`
  Only valid when Kermit is accepting a connection. This variable contains the name of the user that has been authenticated as opposed to `\v(userid)` which contains the name the user chose to login as. This distinction is important for `\v(authstate)` = "user" since this means that although we were able to authenticate the user as `\v(authname)` we could not verify that she has authorization to access the account of `\v(userid)`.

`\v(authstate)`
  String indicating current state of authentication:

        "rejected" - Rejected or otherwise not authenticated
        "unknown"  - Anonymous connection
        "other"    - We know him, but not his name
        "user"     - We know his name
        "valid"    - We know him, and he needs no password

`\v(authtype)`
  String indicating which telnet (or other) authentication method is in use.

        "NULL"              - No authentication
        "KERBEROS_V4"       - Kerberos 4
        "KERBEROS_V5"       - Kerberos 5
        "SRP"               - Secure Remote Password
        "NTLM"              - NT Lan Manager
        "X_509_CERTIFICATE" - X.509 certificate

`\v(x509_issuer)`
  The issuer string from the peer's X.509 certificate

`\v(x509_subject)`
  The subject string from the peer's X.509 certificate

So, for example, if the sysadmin wishes to prevent user "olga" from using the IKS on Mondays, the initialization file could contain a command like:

      if equal \v(user) olga -
        if equal \v(nday) 1 -
           exit 1 Sorry Olga - please come back another day

Or suppose it is desirable to block access from all xyzcorp.com hosts between 9:00am and noon:

      if match \v(line) *.xyzcorp.com -
        if lgt \v(time) 09:00:00 -
          if llt \v(time) 12:00:00 -
             exit 1 Sorry - Please come back after noon

Or suppose a certain user is to be allowed to GET files from the server, but not SEND, PRINT, or MAIL them:

      xif equal \v(user) ivan {
          disable send
          disable print
          disable mail
          disable enable
      }

###

4.3. System Logging

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

System logging in Windows NT is performed via the Administrative Tools Event Log. Use the Event Viewer to examine IKSD events.

All IKSD entries (except debugging, see below) appear in the event log, with a tag of "IKSD" and the process ID (pid) of the IKSD process. The system logging levels are:

      0 = no logging
      1 = Login/out, failed login attempts, failed Kerberos (etc) authentication
      2 = Dialing out (does not apply to IKSD)
      3 = Making any kinds of connections (does not apply to IKSD)
      4 = Protocol Operations
      5 = Creating / receiving / deleting / renaming / copying files
      6 = Sending / typing / reading / transmitting files
      7 = All top-level commands and all server commands sent to iksd
      8 = Commands executed from macros and command files
      9 = Debug

Each level includes all the levels beneath it (except 0 is not included if the logging level is greater than 0). The default logging level is 6. If you specify a number higher than the maximum, it is the same as specifying the maximum.

WARNING: Debug level produces VOLUMINOUS amounts of information -- it is equivalent to (in fact, it is) Kermit 95's debug log. Furthermore, there is a good possibility it will contain sensitive information such as clear-text passwords.

###

4.4. The Transfer Log File

[ Top ] [ Contents ] [ Section Contents ] [ Previous ]

The transfer log is disabled by default; it must be enabled on the command line (Section 5.1).

The transfer log has the same format as the Unix wu-ftpd log, and so all the same scripts can be used to process it, collect statistics, etc.

The Transfer log can also be used in regular user-mode Kermit 95 sessions.

The first field is fixed-length and contains spaces; subsequent fields are variable length, contain no spaces, and are separated by one or more spaces. The fields are:

Timestamp
  This is an asctime-style timestamp, example: "Sun Jan 20 11:42:52 2002". It is always exactly 24 characters long, and the subfields are always in fixed positions.

Elapsed time
  The whole number of seconds required to transfer the file, as a string of decimal digits, e.g. "24".

Connection
  In IKSD, the IP hostname or address of the client. For user-mode C-Kermit transfers, The name of the network host to which C-Kermit is connected, or the name of the serial device through which it has dialed (or has a direct connection), or "/dev/tty" for transfers in remote mode.

Bytes transferred
  The number of bytes transferred, decimal digits, e.g. "1537904".

Filename
  The full pathname of the file that was transferred, e.g. "/pub/ftp/kermit/a/README.TXT". If the filename contains any spaces or control characters, each such character is replaced by an underscore ('_') character.

Mode
  The letter 'b' if the file was transferred in binary mode, or 'a' if it was transferred in text (ASCII) mode.

Options
  For compatibility with the wuftpd log. This field always contains an underscore ('_') character.

Direction
  The letter 'o' if the file was transferred Out, and 'i' if the file was transferred In.

User class
  The letter 'r' for real users, or 'a' for anonymous users.

User identification
  The user ID of a real user, or the password given by an anonymous user.

Server identification
  The string "iks" (Internet Kermit Server), or if C-Kermit is running in user mode, "kermit". This distinguishes a Kermit transfer log record from a WU-FTPD record, which contains "ftp" in this field.

Authentication class
  The digit '1' if we know the user's ID on the client system, otherwise '0'. Currently, always '0'.

Authenticated user
  If the authentication class is '1', this is the user's ID on the client system. Otherwise, it is an asterisk ('*'). Currently, it is always an asterisk.

###

5. ACCESS TO SERVICES

[ Top ] [ Contents ] [ Next ] [ Previous ]

      5.1. Automatic Settings
      5.2. Authentication and Authorization
      5.3. The DISABLE Command
      5.4. Shell Access
      5.5. Anonymous Users
      5.6. Management Information

The IKSD behaves at runtime just like the regular Kermit-95 program with the differences noted in this section and in Section 7.

###

5.1. Automatic Settings

[ Top ] [ Contents ] [ Section Contents ] [ Next ]

When Kermit-95 is started as an Internet Kermit Service, the following settings occur automatically:

1. Login (authorization) is required.
2. Shell access is disabled.
3. Server-side Telnet negotiation is enabled.
4. SET RELIABLE ON (see the C-Kermit 7.0 Update Notes).
5. FAST file-transfer settings, including "cautious" unprefixing.
6. No flow control, no parity.

Items d-f can be overridden in the IKSD configuration file.

###

5.2. Authentication and Authorization

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

> TO DO: Describe details of authentication via X.509 certificates, Kerberos, SRP, and NTLM and how that differs from authorization via the issuance of a userid and password.

The IKSD command prompt will not appear, and no commands may be given, before the user is authorized (and perhaps, authenticated).

When the IKSD has been started without the SET IKS SERVER-ONLY ON command in the IKSD Configuration file, it issues a Username: prompt. The user may type a username at the prompt, in which case a Password: is issued, and the user must enter a password. Three login attempts are allowed, with a pause enforced between each one. If all three fail, the connection is closed.

The user may also authorize from the client by sending a REMOTE LOGIN command (again, only 3 tries are allowed), or by Telnet Authentication negotiations. Prior to authorization, the IKSD will respond to only the following client commands:

      REMOTE LOGIN
      REMOTE LOGOUT
      REMOTE HELP
      REMOTE EXIT
      BYE

Once authorized, the user may not re-authorize or change identities.

The connection persists until it is broken in any of the following ways:

1. Client sends BYE or REMOTE EXIT or REMOTE LOGOUT to IKSD.
2. Client sends FINISH to IKSD that has been started with `-x`.
3. User gives a HANGUP or CLOSE command to the client.
4. User gives an EXIT or LOGOUT command at IKSD prompt.

The connection is also closed if the user exits from the client, but only if it was an end-to-end Telnet connection. There can be no guarantee that exiting from a serial communication program will close and hang up the serial connection.

###

5.3. The DISABLE Command

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

In the IKSD, the DISABLE command applies not only to client/server functions, but also to the corresponding commands when given at the prompt. For example, DISABLE DELETE disables not only REMOTE DELETE commands given from the client, but also DELETE commands given at the IKSD's command prompt, as well as implicit forms of file deletion, such as when the target of a COPY command is an existing file.

The DISABLE ENABLE command is irreversible; once this command is given, the ENABLE command can not be re-enabled, and therefore no other disabled commands can be enabled either. ENABLE is DISABLEd automatically for anonymous users, so any DISABLE commands in the anonymous-user initialization file (Section 5.4) are also irreversible.

###

5.4. Shell Access

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

All forms of system and shell access are disabled in WIKSD. Thus, the user can not execute REMOTE HOST commands from the client, nor access the shell from the IKSD command prompt via shell escapes (!), the RUN or PUSH command, or by specifying pipes or filters in file-transfer commands, or by pipe specifications in REMOTE commands, or in any other way.

###

5.5. Anonymous Users

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

Anonymous logins are disabled by default, but can be enabled with the SET IKS ANONYMOUS LOGIN ON command in the IKSD Configuration file.

The account specified by SET IKS ANONYMOUS ACCOUNT is used on Windows NT/2000/XP to provide anonymous access. There is no ANONYMOUS ACCOUNT in Windows 95/98/ME. For safety in Windows 9x, an anonymous root directory should always be specified with SET IKS ANONYMOUS ROOT. Otherwise, anonymous users will have (at least) read access to your entire file system.

In addition to the FTP-like restrictions, certain Kermit services are always denied to anonymous users. These include:

- PRINT (at IKSD prompt) and REMOTE PRINT (from client)
- MAIL (or SEND /MAIL) at IKSD prompt and from client.
- Creation of any logs (transaction, debug, packet, etc).
- No file may be deleted, including implicitly, e.g. by the COPY command.
- FILE COLLISION is set to RENAME and may not be changed.

The latter three provisions mean that anonymous users can not delete, overwrite, rename, or alter any existing files in any way, whether by file transfer or with the DELETE or RENAME command.

Note that IKSD, like FTPD, does not allow directory creation by anonymous users, even when file/directory permissions would otherwise allow it. To change this, add:

      enable mkdir    ; Enable directory creation

to the IKSD Configuration file or the ON_LOGIN macro. Similarly, for directory removal:

      enable rmdir    ; Enable directory removal

Of course directories can be removed only if (a) they are empty, and (b) their permissions allow it.

###

5.6. Management Information

[ Top ] [ Contents ] [ Section Contents ] [ Previous ]

The command-line argument vector, normally accessible in the `\&@[]` array, the top-level `\%0..9` variables, or by other means, is inaccessible to IKSD users. Thus, IKSD clients can not discover the IKSD startup path or options, the logfile pathnames or directories, logging level, etc.

###

6. MONITORING AND CONTROL

[ Top ] [ Contents ] [ Next ] [ Previous ]

      6.1. The Control Panel
      6.2. The Event Log
      6.3. The Task Manager
      6.4. IKSDPY

As with any Internet service (e.g. FTP, Telnet), every IKSD session has its own IKSD server instance. Thus at any time 0, 1, 2, or more copies of IKSD may be running on your PC. You can monitor and control them in various ways, described in this section.

###

6.1. The Control Panel

[ Top ] [ Contents ] [ Section Contents ] [ Next ]

Control Panel --> Administrative Tools --> Services. This lets you stop, pause, resume, or start Internet Kermit Service (IKSD). Note: stopping the service does not stop open sessions; it merely blocks creation of new sessions.

###

6.2. The Event Log

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

You can monitor IKSD sessions with the Event Log:

`` Control Panel --> Administrative Tools --> Event Viewer --> Applications

IKSD entries have IKSD in the Source column. The types of entries that appear in the log depend on your SET SYSLOG selection. To see the detail for an entry, double-click on it. The text entered into the log by IKSD is at the end of the Description box (despite the fact the that description begins with "The description for Event ID (0) uin Source (IKSD) cannot be found").

The Event Viewer does not update the screen as new events occur; you have to hit the Refresh button.

###

6.3. The Task Manager

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

You can watch IKSD (as either IKSDNT or K95) in the task manager's Processes tab, and system performance in the Performance tab. Unfortunately, however, there is no way to kill an IKSD instance because it is owned by System, and not even the Administrator has the authority to kill System-owned processes.

###

6.4. IKSDPY

[ Top ] [ Contents ] [ Section Contents ] [ Previous ]

A realtime text-mode display of IKSD activity is available as a Kermit script called `IKSDPY.KSC`, to be executed by Kermit 95. You can find a copy of it in Kermit 95's SCRIPTS subdirectory. To use it, start a copy of `K95.EXE` and tell it to "take scripts/iksdpy.ksc". Or (if in your Kermit 95 installation, you chose to associate "`.KSC`" files with Kermit 95) you can simply click on the `IKSDPY.KSC` file or any shortcut to it.

The main IKSDPY display shows the active sessions. If you press a digit, you can view the details for a particular session -- user, pid, current directory, state, last command, etc.

In any screen, you can press "h" to get help for that screen, which tells you which keys you can press to move to other screens.

###

7. OPEN ISSUES

[ Top ] [ Contents ] [ Next ] [ Previous ]

      7.1. Connection Establishment
      7.2. Shell Access
      7.3. Non-Kermit Protocols
      7.4. Additional Administrative Controls
      7.5. Known Bugs

Several services that are normally provided by Kermit-95 are not available when it is an Internet Kermit Service Daemon.

###

7.1. Connection Establishment

[ Top ] [ Contents ] [ Section Contents ] [ Next ]

If a real user has access to the IKSD command prompt, why not allow her to "set host" or "set line" from there to another place? Obviously this would be a security risk if allowed for anonymous users. For authenticated users, it should be OK, but is not currently possible for Telnet connections since the IKSD is already a Telnet server on the incoming connection, and is not designed to conduct two separate Telnet sessions simultaneously. It might be possible to allow the user to make a dialout connection, but some coding and testing would be needed should this prove desirable, and even then it is not clear that the PC owner would be willing to pay the telephone charges.

###

7.2. Shell Access

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

Shell access is forbidden to anonymous users for obvious reasons. From a security standpoint, it could be allowed for authenticated users.

###

7.3. Non-Kermit Protocols

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

Since Xmodem, Ymodem, and Zmodem are built into Kermit 95, when it is used as an IKSD these protocols are available for use, e.g. with "set protocol zmodem". Non-Kermit protocols are not available with the standalone `IKSDNT.EXE` program.

###

7.4. Additional Administrative Controls

[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]

Certain options available in wu-ftpd are not implemented in iksd:

- Ability to select IKSD logging for real vs anonymous users.
- Ability to select IKSD logging for inbound vs outbound files.
  - Currently, all transfers are logged.

- Ability to allow/restrict chmod/delete/overwrite for anonymous users.
  - Currently, there is no command for changing file permissions.
  - Guests may not delete files, period.
  - FILE COLLISION is set to RENAME for guests and may not be changed since all the other options allow existing files to be altered.
  - There is no way to grant these capabilities to guests.

- Ability to allow directory creation by anonymous users.
  - Anonymous users may not create or remove directories.

- Ability to allow/specify CD messages on a per-directory basis.
- RFC931 authentication of remote (client) user (but wu-ftpd doesn't either).

These or other controls can be added if there is sufficient reason or demand.

###

7.5. Known Bugs

[ Top ] [ Contents ] [ Section Contents ] [ Previous ]

- Ctrl-C at the `IKSD>` prompt has no effect.
- When commands are logged in Event Log, the EXIT command appears twice.
- User profiles are not imported into the environment

###

8. TESTING

[ Top ] [ Contents ] [ Previous ]

In case you want to test IKSD on a port other than 1649, be aware that IKS-aware Kermit clients (such as Kermit-95 and C-Kermit) will not automatically initiate Telnet negotiations with it, since it is not on a Telnet port (i.e. 23 or 1649). To get correct operation you'll need to force the client to negotiate, e.g.:

      telnet hostname 3000
      set host hostname 3000 /telnet

[ Top ] [ Contents ] [ Kermit 95 Home ] [ Kermit Home ]