Windows Internet Kermit Service - Administrator Guide

Max Evarts, The Kermit Project
Columbia University, New York City
January 2003

[ 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.

As of Kermit 95 version: 2.1
This file last updated: Fri Jan 5 11:51:04 2007 EST   (New York City time)
What's new:   A small section on firewalls.

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:

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. Send them by email to:




[ 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 appeared 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 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:

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, the IKSD implementation for Windows NT, 2000, or XP, is Kermit 95 2.0 or later, installed as a Windows Service. 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.

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:

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

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 or Zmodem file-transfer protocols. The clients that work best are:

Other clients might or might not support:

A Unix-based IKSD is available for public access at:, 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:
Kermit 95 Tutorial
Windows IKSD User Guide
Unix C-Kermit Tutorial
Unix IKSD Administrator Guide
Kermit Security Reference
Kermit Telnet Client Reference


[ 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 accommodate 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 accommodate 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 Kermit 95 itself, augmented by the following utilities:

A program used to start Internet Kermit Service as a user process (Win9x only, not recommended or supported).
A program used to start the Internet Kermit Service as a Windows NT service.

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, even when you are not logged in to your PC. 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 InstallShield package) or for greater control over the configuration, you can install it manually.


But however you install it, it will not be accessible to the outside world if you have a firewall in your PC or your network that blocks TCP port 1649. In Windows XP, for example:
  1. Control Panel → Windows Firewall
  2. On the General tab, uncheck "Don't allow exceptions"
  3. On the Exceptions page, "Add Port", Name: kermit, TCP port number 1649.
  4. On the Advanced tab, Network Connection Settings section:
  5. Click OK on all the open boxes.

2.1. InstallShield Installation

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

Normally you would install Internet Kermit Service on your Windows system the same way you install any other program, using the normal Windows installation procedure. WIKSD comes in an InstallShield (IS) package, a single .EXE file that you run to install the application. The IS procedure asks a few simple questions and then installs WIKSD as a Windows NT service and starts it. So as soon as you complete the installation, you can make connections to WIKSD.

You must be a member of the Administrator group to install WIKSD. If you are not, installation of the WIKSD service fails.

The IS procedure for WIKSD (or the WIKSD component of the IS procedure for Kermit 95) follows these steps:

  1. If you downloaded the IS package from the Kermit site, you must run it, e.g. with Start-->Run. (If you are installing from CDROM, this should happen automatically.)

  2. It begins by unpacking itself into its constituent files (into the directory indicated by your TEMP environment variable), then you get a screen explaining what happens next, with Next and Cancel buttons. At each step, if you push Cancel, the installation is canceled.

  3. Push Next to get the license, read it, and then push Next if you agree to the terms, No if you don't.

  4. If you agree to the license, you get the Choose Destination Location screen. The default location is shown in the Destination Folder box. Click Next to accept it, or Browse to choose a different location.

  5. The Selected Components screen appears, in which you choose which components to install. If you click once on a component name to highlight it, an explanation of the component's role and function appears in the Description box on the right. You can check or uncheck any component box unless it is grayed out (as is the case for mandatory components).

  6. If you are installing Kermit 95, some screens might appear that are not related to WIKSD.

  7. The Start Copying Files screen appears, listing what is to be installed. Push Next to proceed, Back to change selections, or Cancel to quit.

  8. Assuming you have selected the IKSD component, and have copied the files, a series of questions appears in which you choose the basic operating parameters for WIKSD:

    Please choose the directory that remote users will start in:
    This will be the user's initial current directory after they log in. By default is the user's home folder, so if users on your PC each have their own folder, you would accept the default.

    Choose logging level
    This determines which kinds of records WIKSD writes into the NT System Event Log. LOGIN would log only logins and logouts. FILE CREATE logs changes to the file system (including file deletion). FILE ACCESS logs all file access (including reads). COMMANDS would log every command that every user gave.

    Do you want to log all file transfers?
    If you answer Yes, a separate file transfer log is kept, similar to the logs kept by FTP servers. By default, it is IKSD.LOG in the same directory from which the IKSD (or K95) executable is started.

    Do you want to enable anonymous access?
    The default is No. You should not choose Yes without reading Section 3.1 of this document first. But if you do choose Yes, you'll have a chance to identify anonymous with a particular NT account (default is GUEST).

    The WIKSD-related questions are used to create the IKSD.KSC file in the top-level Kermit 95 directory, which every instance of WIKSD reads and executes upon startup and before accepting a login. You can change your IKSD preferences or configuration at any time by editing this file. See Section 4.1 for details.

You can shut down, pause, or restart the WIKSD service at any time from the Control Panel: Administrative Tools --> Services. Highlight IKSD, then choose the desired action from the Action menu.

You can monitor WIKSD activity in the Event Viewer Application Log (Control Panel --> Administrative Tools --> Event Viewer --> Application Log).

To uninstall WIKSD, use Add/Remove Programs in the Control Panel. But note that when uninstalling WIKSD (or Kermit 95 itself) certain files might not be removed:

(Full Kermit 95 installations only, not IKSD-only ones) This program remains in memory to keep the Kerberos credentials cache available. Uninstall schedules it for removal upon the next reboot.

(In your top-level Kermit 95 directory) This is your IKSD configuration file, in case you want to use it again. If you install WIKSD or K95 again, the IKSD configuration questions are skipped and this file is used. If you don't want that to happen, simply delete this file.

(In your top-level Kermit 95 directory, but not related to IKSD). This is your Kermit 95 Dialer database, containing all the entries you made or modified. If you install K95 again, this file is used instead of the distributed one. If you don't want that to happen, simply delete this file.

(In your top-level Kermit 95 directory, not necessarily related to IKSD). Your Kermit 95 initialization and customization files.

Plus any Kerberos configuration files that might have been created.

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 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:


    (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:

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 ]

Also see:

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 ]

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:

   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:

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 ]

(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:


In this key, the following values must be set:

  Description=Secure Remote Password

Once this is done:

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

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


[ 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.


[ 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, it obtains its configuration in the following sequence:

  1. It executes the IKSD Configuration File, IKSD.KSC, from the same directory where K95 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) {
	echo Hi Olga
	set root c:/olga
	echo Hello Olaf
	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, \v(exedir)IKSD.KSC, can contain any Kermit commands, functions or built-in variables but:

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.

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.

The initialization file to be executed for anonymous logins. By default it is K95.INI in the home directory associated with the ANONYMOUS 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.

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.

Specifies a directory tree to which anonymous users are restricted after login.

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).

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:


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:


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.

This command determines whether entries are inserted into the SET IKS DBFILE which can be viewed with the IKSDPY.KSC script (Section 6.4).

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


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.

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.

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

Do not execute an initialization file, even if a real user is logging in.

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.

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.

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.

Whether a wu-ftpd-like log should be kept. Off by default. This log is explained in Section 5.3.

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:

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.

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.

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

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


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

IKSD.KSC file contains:
As above, but with all user commands going to the Event Log (Section 4.3).

IKSD.KSC file contains:
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:
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:
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.

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.

The user's home directory.

The hostname of the IKS.

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.

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.

The ID with which the user logged in to the IKS. For anonymous logins, this is "anonymous".

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).

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

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

The issuer string from the peer's X.509 certificate

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 hosts between 9:00am and noon:

  if match \v(line) * -
    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:

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".

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".

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.

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

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

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.

4.5. Security

4.5.1. Introduction

The Internet Kermit Service when built with support for Kerberos 4, Kerberos 5, Secure Remote Password, or OpenSSL's SSL/TLS can be configured to accept, request, or require secure (authenticated, encrypted, integrity protected) connections utilizing Telnet Security options.

Kermit 95 2.1 is shipped with support for all of the security options. The availability of various options is determined by the options selected at install time.

Instructions for building C-Kermit 8.0 with arbitrary combinations of security options are available in the C-Kermit Security documentation.

Most installations of IKSD utilize the TELNET START_TLS option to provide encrypted and integrity protected connections in conjunction with X.509 certificate based server-side authentication. START_TLS is often combined with Kerberos, Secure Remote Password, or X.509 client certificates to provide secure client side authentication. Username and Password prompts are issued over the TLS connection when secure authentication of the client is unavailable.

4.5.2. Configuring IKSD for use with TELNET START-TLS

  1. Retrieve or generate Server Side Certificate and Private Key

  2. In your IKSD configuration file, \v(common)IKSD.KSC (on Windows) or /etc/iksd.conf (on Unix), specify these options:

  3. To request or require the use of TLS, add:


4.5.3. Configuring IKSD TELNET START-TLS utilizing X.509 Certificates

  1. Kermit supports the installation of both RSA and DSS certificates. If you have an RSA-based server certificate then you must specify the file containing the certificate as well as the file containing the private key. The private key file must not be encrypted; otherwise, it will not be able to be loaded by IKSD.


  2. If your certificate is not directly signed by the Root CA, you will need to include the intermediary CA certificates in a Certificate Chain file:


  3. If you have an DSS-based server certificate then you must specify the file containing the certificate as well as the file containing the private key. The private key file must not be encrypted; otherwise, it will not be able to be loaded by IKSD.


  4. If your certificate is not directly signed by the Root CA, you will need to include the intermediary CA certificates in a Certificate Chain file:


  5. If you wish to restrict the ciphers used to secure the connection you may do so with the SET AUTH TLS CIPHERS command. If you do not have any certificates at all to use, specify the use of Anonymous-Diffie-Hellman ciphers:


4.5.4. Configuring IKSD to accept Client Side Certificates

  1. If you wish to accept client certificates you must specify:


  2. If you wish to require the use of client certificates specify:


    In addition, you must configure where the validation information for the client side certificates is located. First, the location of the CA certificates for the validation chain must be specified. This is done with:


    The location of Certificate Revocation Files must also be specified:

Read about these commands in for information on the details of how Certificates and CRLs are stored in files and directories for use with OpenSSL.

Also, read the section on how to build C-Kermit for different methods of extracting the userid from the client certificate.

4.5.5. Configuring IKSD TELNET START-TLS Utilizing Kerberos 5 Tickets

When utilizing Kerberos 5 to authenticate the IKSD to the client you must specify the location of the Kerberos Keytab File:


and specify the use of KRB5 ciphers:


NOTE: OpenSSL must have been built with support for MIT Kerberos 5.

Configuring IKSD to utilize TELNET AUTHENTICATION options:

  1. The TELNET AUTH options (KRB4, KRB5, SRP, NTLM) may be used either with or without the START-TLS option. If you wish to request or require the use of the AUTH option:


  2. To specify an authentication type(s) use:


    where type(s) is one or more of KRB4, KRB5, SRP, NTLM.


[ 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:


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:

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.


[ 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 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.


[ 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.


[ 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".

7.4. Additional Administrative Controls

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

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

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

7.5. Known Bugs

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


[ 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 ]

Windows Internet Kermit Service - User Guide / The Kermit Project / Columbia University / 7 Dec 2002