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:
http://www.columbia.edu/kermit/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. Send them by email to: support@kermitproject.org.
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
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:
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:
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:
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.
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:
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 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:
Plus any Kerberos configuration files that might have been created.
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:
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.)
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.
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.
(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:
Now the Internet Kermit Service will start automatically each time you login to Windows.
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 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:
Now set the exact permissions required for the incoming directory:
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.
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:
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.
(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:
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:
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:
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.
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.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:
When Kermit 95 is started as IKSD, it obtains its configuration in the following sequence:
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:
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.
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, 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 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}}
\v(exedir)iksd.db
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:
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.
http://www.kermit-project.org/security.html http://www.kermit-project.org/telnet.html
for details on how Telnet and Authentication policies can be set.
Examples:
SET SYSLOG COMMANDSAs above, but with all user commands going to the Event Log (Section 4.3).
SET IKS ANONYMOUS LOGINS ON SET IKS CDFILE READ.MEStarts the IKSD with anonymous access enabled and changes the name of CD message file from the default list to READ.ME.
SET IKS ANONYMOUS LOGINS ON SET IKS ANONYMOUS ACCOUNT KERMIT\\GUEST SET IKS CDFILE README.TXT SET IKS SERVER-ONLY ONStarts 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.
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 REQUIREDStarts 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.
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:
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:
"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
"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
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
}
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.
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:
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.
http://www.columbia.edu/kermit/security.htmlMost 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
- Retrieve or generate Server Side Certificate and Private Key
- In your IKSD configuration file, \v(common)IKSD.KSC (on Windows) or /etc/iksd.conf (on Unix), specify these options:
- To request or require the use of TLS, add:
SET TELOPT START-TLS {REQUESTED, REQUIRED}4.5.3. Configuring IKSD TELNET START-TLS utilizing X.509 Certificates
- 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.
SET AUTH TLS RSA-CERT-FIL C:/OPENSSL/TELNETD-RSA.PEM SET AUTH TLS RSA-KEY-FIL C:/OPENSSL/TELNETD-RSA-KEY.PEM
- 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:
SET AUTH TLS RSA-CERT-CHAIN-FILE C:/OPENSSL/TELNETD-RSA-CHAIN.PEM
- 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.
SET AUTH TLS DSA-CERT-FIL C:/OPENSSL/TELNETD-DSA.PEM SET AUTH TLS DSA-KEY-FIL C:/OPENSSL/TELNETD-DSA-KEY.PEM
- 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:
SET AUTH TLS DSA-CERT-CHAIN-FILE C:/OPENSSL/TELNETD-DSA-CHAIN.PEM
- 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:
SET AUTH TLS CIPHERS ADH4.5.4. Configuring IKSD to accept Client Side Certificates
Read about these commands in http://www.columbia.edu/kermit/security.html for information on the details of how Certificates and CRLs are stored in files and directories for use with OpenSSL.
- If you wish to accept client certificates you must specify:
SET AUTH TLS VERIFY PEER-CERT
- If you wish to require the use of client certificates specify:
SET AUTH TLS VERIFY FAIL-IF-NO-PEER-CERTIn 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:
SET AUTH TLS VERIFY-FILE C:/OPENSSL/CA_CERTS.PEM SET AUTH TLS VERIFY-DIR C:/OPENSSL/CERTSThe location of Certificate Revocation Files must also be specified:
SET AUTH TLS CRL-FILE C:/OPENSSL/CRLS.PEM SET AUTH TLS CRL-DIR C:/OPENSSL/CRLSAlso, 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:
SET AUTH KRB5 KEYTAB C:/ROOT/KEYTABand specify the use of KRB5 ciphers:
SET AUTH TLS CIPHERS KRB5NOTE: OpenSSL must have been built with support for MIT Kerberos 5.
Configuring IKSD to utilize TELNET AUTHENTICATION options:
- 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:
SET TELOPT AUTH {REQUEST, REQUIRED}
- To specify an authentication type(s) use:
SET TELNET AUTH TYPE type(s)where type(s) is one or more of KRB4, KRB5, SRP, NTLM.
[ Top ] [ Contents ] [ Next ] [ Previous ]
5. ACCESS TO SERVICES
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 InformationThe IKSD behaves at runtime just like the regular Kermit-95 program with the differences noted in this section and in Section 7.
[ Top ] [ Contents ] [ Section Contents ] [ Next ]
5.1. Automatic SettingsWhen Kermit-95 is started as an Internet Kermit Service, the following settings occur automatically:
- Login (authorization) is required.
- Shell access is disabled.
- Server-side Telnet negotiation is enabled.
- SET RELIABLE ON (see the C-Kermit 7.0 Update Notes).
- FAST file-transfer settings, including "cautious" unprefixing.
- No flow control, no parity.
Items d-f can be overridden in the IKSD configuration file.
[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]
5.2. Authentication and Authorization
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 BYEOnce authorized, the user may not re-authorize or change identities.
The connection persists until it is broken in any of the following ways:
- Client sends BYE or REMOTE EXIT or REMOTE LOGOUT to IKSD.
- Client sends FINISH to IKSD that has been started with -x.
- User gives a HANGUP or CLOSE command to the client.
- 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.
[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]
5.3. The DISABLE CommandIn 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.
[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]
5.4. Shell AccessAll 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.
[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]
5.5. Anonymous UsersAnonymous 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 creationto the IKSD Configuration file or the ON_LOGIN macro. Similarly for directory removal:
enable rmdir ; Enable directory removalOf course directories can be removed only if (a) they are empty, and (b) their permissions allow it.
[ Top ] [ Contents ] [ Section Contents ] [ Previous ]
5.6. Management InformationThe 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. MONITORING AND CONTROL
6.1. The Control Panel 6.2. The Event Log 6.3. The Task Manager 6.4. IKSDPYAs 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.
[ Top ] [ Contents ] [ Section Contents ] [ Next ]
6.1. The Control PanelControl 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.
[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]
6.2. The Event LogYou 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.
[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]
6.3. The Task ManagerYou 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 ]
6.4. IKSDPYA 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. OPEN ISSUES
7.1. Connection Establishment 7.2. Shell Access 7.3. Non-Kermit Protocols 7.4. Additional Administrative Controls 7.5. Known BugsSeveral services that are normally provided by Kermit-95 are not available when it is an Internet Kermit Service Daemon.
[ Top ] [ Contents ] [ Section Contents ] [ Next ]
7.1. Connection EstablishmentIf 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.
[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]
7.2. Shell AccessShell access is forbidden to anonymous users for obvious reasons. From a security standpoint, it could be allowed for authenticated users.
[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]
7.3. Non-Kermit ProtocolsSince 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".
[ Top ] [ Contents ] [ Section Contents ] [ Next ] [ Previous ]
7.4. Additional Administrative ControlsCertain 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.
[ Top ] [ Contents ] [ Section Contents ] [ Previous ]
7.5. Known Bugs
- 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
[ Top ] [ Contents ] [ Previous ]
8. TESTINGIn 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