Home ]   [ Kermit 95 ]   [ C-kermit ]   [ Scripts ]   [ Current ]   [ New ]   [ FAQ ]   [ Support ]

KERMIT FTP CLIENT - FREQUENTLY ASKED QUESTIONS

As of: Kermit 95 2.1.3, C-Kermit 8.0.211
This File Last Updated: Wed Jun 20 11:43:22 2007
[ FTP Client Overview ] [ FTP Scripting and Automation Tutorial ] [ IBM Info Exchange ] [ First Health Services ]


CONTENTS

If you are having problems with FTP in C-Kermit...
Please try the latest daily build, which includes fixes to FTP bugs that were discovered after C-Kermit 8.0.209 was released. CLICK HERE to get the latest daily build. Similarly, if you are having trouble building a secure version of C-Kermit, please try the daily build, in which new targets have been added (e.g. for HP-UX), new OpenSSL libraries (0.9.7) allowed for, etc.

If you are having problems with FTP in Kermit 95...
See the New Bugs List for bugs in Kermit 95 (including its FTP client) that have surfaced since version 2.0 was released, and in particular since the latest version, 2.1.3, was released. One such bug is a failure to properly convert line terminators during text-mode uploads. This will be fixed in the next K95 release. Until then, you can work around this problem with THIS MACRO.


GENERAL QUESTIONS

[ Next ] [ Previous ] [ Top ]

For What Platforms Is the Kermit FTP Client Available?
Windows 95, 98, ME, NT, 2000, XP, and 2003 (as Kermit 95).
IBM OS/2 (as Kermit 95).
Unix: All varieties that support TCP/IP, including Linux, FreeBSD, Mac OS X, Solaris, AIX, HP-UX, Tru64, SCO, QNX, IRIX, OpenBSD, NetBSD, etc (as C-Kermit).

How Is the Kermit FTP Client Different from Regular FTP Clients?
Previous versions of C-Kermit and Kermit 95 already supported a wide variety of connection methods and protocols, as well as a general-purpose communications oriented scripting language. It was relatively easy to add an FTP client over the existing TCP/IP interface and command language. The advantages over regular command-line FTP clients include:

For greater detail, see the Kermit FTP Client Overview.

Where is the Kermit FTP Client Documented?
In the C-Kermit 8.0 Update Notes.

What Are Active and Passive Mode?
FTP protocol uses two connections; one for commands and responses, another for data. When you give your FTP client a data transfer command such as GET or PUT, a second port is opened for the data. The server's command (control) port is normally 21 and its data port is normally 20. The client, however, can use any random port numbers greater than 1024 for its end of each connection:

Passive is Kermit's default mode since it tends to work better with firewalls. This is because the choice of port numbers is controlled inside the server-side firewall, and thus the server and the firewall can be configured by the site's network and system administrators to accommodate each other.

On secure FTP connections, commands and responses are encrypted and therefore cannot be understood by firewalls. Which brings us to the next question...

What Are Active and Passive Mode?
Here's another explanation, from Jeff Altman:

"FTP works this way. The server has a standard port for command channels, port 21. The client allocates a random port number to use when making a connection and then connects to port 21. If the client does not randomize its port number then it would be impossible for two processes on the same machine to connect to the same FTP server.

"The data connection depends entirely on which side is being the acceptor. In the original 'active' model, the client allocates a random port number and offers it to the server. The server then uses port 20 to connect to the client's port.

"This does not work through firewalls and NATs. Therefore, the passive model was developed. In the passive model, the server allocates a random port and publishes it to the client. The client then allocates a random port number and connects to the server. The reason the client uses a random value is because the server may have a small number of reused ports.

"Kermit defaults to the passive model as does almost every other current FTP client. FTP servers are assumed to be in public space; the FTP client is assumed to be in private space given the current Internet architecture."

Can I Use Kermit to Make FTP Proxy Connections?
The FTP Proxy feature allows an FTP client to tell an FTP server to send send or receive data to or from a third party, such as another FTP server. The Kermit FTP client does not support this feature, as it lacks any form of security and is frequently used in denial-of-service attacks. If all you are looking to do is circumvent a firewall, a better way is to use Kermit's SOCKS4 or HTTP Proxy support (the latter via Kermit's HTTP CONNECT command).

Why Does FTP OPEN xxx /USER:yyy Succeed Even If Login Fails?
When you include a /USER: switch with the FTP OPEN command, you are asking Kermit to do two things in one command: make the FTP connection and log you in to the server. The FTP OPEN command succeeds if the connection is opened and fails if it isn't. Successful login can be tested separately; for example:

ftp open xyzcorp.com /user:olga
if fail exit 1 "FTP Connection Failed."
if not \v(ftp_loggedin) exit 1 "FTP Login Failed."

How Do I Automate an FTP Session?
This is described in a separate document; CLICK HERE to read it.

How Can I Make an FTP Command Time Out?
At present, you can't. Like most other FTP clients, the Kermit client relies on the underlying TCP/IP stack to time out unresponsive connections. Unfortunately, most TCP/IP stacks are not very helpful in this regard. A timeout feature for FTP commands will be added in a future Kermit release.

What About File Transfer with VMS ODS-5 Servers?
Traditionally VMS filenames have a name and an extension, separated by a period (dot), e.g. LOGIN.COM, plus some other parts -- only one dot allowed (except that the semicolon separating the extension from the version number can also be a dot, but version numbers are generally omitted in file transfer). Recent VMS versions support an "extended" file system allowing multiple dots, as well as mixed case, e.g. Kermit.tar.gz (case is preserved but not significant). When such a file is sent by the regular FTP server, it "escapes" all but the last dot; e.g. Kermit^.tar.gz. You can have Kermit remove the escapes automatically like so:

mget /rename-to:\freplace(\v(filename),^.,.) *

Presently Kermit doesn't have a method for adding escapes when uploading, should that be necessary, but if you tell it to "set file names converted", or use the /FILENAMES:CONVERTED, it will convert all dots except the final one in a filename to underscore (_); e.g. Kermit_tar.gz.


MAKING SECURE FTP CONNECTIONS

[ Next ] [ Previous ] [ Top ]

As business transactions migrate from older communication methods to the Internet, more and more EDI providers (EDI = Electronic Data Interchange, a complex set of standards and technologies for automating the exchange of routine business documents between trading partners) are offering, or even requiring, secure FTP connections. As explained in great detail HERE, security includes many facets, including authentication and encryption. In the Kermit FTP client (Kermit 95 for Windows or C-Kermit for Unix), secure FTP sessions can be authenticated with SSL or TLS ("ftps"), Kerberos 4, GSSAPI / Kerberos 5, and SRP. SFTP is something else (it's not FTP). Most secure FTP sites use SSL or TLS. For all practical purposes, SSL, TLS, and SSL/TLS are synonyms for each other, i.e. different names for the same thing.

For What Platforms Are Secure Kermit FTP Clients Available?
Windows 95, 98, ME, NT, 2000, XP, and 2003 (as Kermit 95).
Unix: All varieties that support TCP/IP and have Kerberos, OpenSSL, or SRP libraries and header files installed. Our working copy of C-Kermit includes secure targets for Linux, FreeBSD, OpenBSD, NetBSD, AIX, HP-UX, IRIX, SCO OSR5, SCO Unixware, Solaris, and SunOS. Similar targets can be added for any other Unix version for which security libraries and headers are available.

Where Can I Get a Prebuilt C-Kermit Binary that Includes Secure FTP?
Not from us, sorry. US export law forbids putting binaries that include strong encryption on an FTP site that is accessible to the world. You'll need to download the C-Kermit source code and build it yourself. See the Kermit Security Reference for details. (Kermit 95 for Windows is a different story.)

I Have the Secure C-Kermit Binary - Now What?
Most secure FTP sites are secured with SSL. The details for making a connection depend on the server site. It might be as easy as this:

C-Kermit> ftp open somehost.xyzcorp.com

When both the client and server support SSL/TLS, they will negotiate a secure connection automatically. In this example, the server is on the regular FTP port, 21.

Sometimes the secure server is on a different port. For SSL/TLS, this would usually be port 990. The following two commands are equivalent; they both open a connection to an FTP server on Port 990.

C-Kermit> ftp open somehost.xyzcorp.com 990
C-Kermit> ftp open /ssl somehost.xyzcorp.com

Of course there are many variations and wrinkles involving client-side and server side certificates, not to mention firewalls, and you will probably run into these. For a through discussion of certificates, see our Security Reference, particularly Appendix III, Introduction to Certificates. Firewalls a mentioned below, and also discussed in Appendix II of the Security Reference, Multihomed Hosts, Firewalls, NATs.

How Do I Access IBM Information Exchange?
This is described in a separate document; CLICK HERE to read it.

How Do I Access IBM IDDX, AT&T Advantis or Worldnet, or GE Global eXchange?
These FTP services are similar to IBM Information Exchange; see the IBM Info Exchange document.

How Do I Access the First Health Services FTP Site?
This is described in a separate document; CLICK HERE to read it.

Why Can't I Make a Connection to a Secure FTP Server?
Assuming your client and server support the same protocols, and you have configured your client appropriately for the server, and you have installed the required certificates in the right format, the problem is almost always a firewall on one end or the other (most likely your end). Firewalls inspect packets as they go by. Once an FTP session has negotiated and switched to some form of encryption, the firewall can no longer read the packets, and therefore blocks them and/or closes the connection. For starters, get your network administrator to allow port 21 traffic without inspection.

Numerous other potential problems remain: the dynamic secondary ports used by FTP for the data connection; potential SSL or TLS bugs or version mismatches, etc. To help diagnosis of misbehaving SSL/TLS FTP connections, use:

set auth tls debug on
set auth tls verbose on
set ftp authtype tls
set ftp debug on

For details and troubleshooting hints, also see:

I Can Log in to the Secure FTP Server but Can't Transfer Files
If you have a firewall that filters the FTP command stream, it does not understand the encrypted messages and therefore is likely to terminate the control connection and/or block the data connection. Error messages will usually be uninformative, as in this example where the firewall closes the connection as soon as the client and server begin to encrypt their messages:

K-95> set ftp authtype ssl
K-95> set ftp debug on
K-95> ftp open xyzcorp.com
---> AUTH SSL
234 SSL enabled and waiting for negotiation
SSL accepted as authentication type
ftp: SSL/TLS connect command error:
error:00000000:lib(0):func(0):reason(0)
SSL authentication failed
K-95>

If you can log in but can't transfer data (DIR, GET, PUT, etc), try switching modes (see the items on Active and Passive Mode above). Passive mode is the default and usually works on secure connections and/or through firewalls and network address translators, but in some cases Active mode is required; it depends on the configuration of the client's network and of the server's network.

More often the problem is a "Catch-22" in the server network's firewall configuration. FTP passive mode should work if the firewall is configured to allow connections to the ports that the FTP server chooses. If not, the problem can be solved only by your network/firewall administrator. Failing that, you'll have to make clear-text FTP connections (if the servers to which you need to make connections allow them), or else use a different protocol (such as Kermit, which uses only one connection, not two).

Another possibility, noted recently (June 2007) with a certain VAN (nuBridges EDI*NET), is that a specific data protection level is required, in this case CONFIDENTIAL:

SET FTP DATA-PROTECTION-LEVEL { CLEAR, CONFIDENTIAL, PRIVATE, SAFE }
Determines the level of protection applied to the command channel:
CLEAR Data is sent in plaintext and not protected against tampering.
CONFIDENTIAL    Data is encrypted but not protected against tampering.
PRIVATE Data is encrypted and is protected against tampering.
SAFE Data is sent in plaintext but protected against tampering.

The default is PRIVATE. In this case, the server did not reject the transfer request, but simply sent the data in "confidential" format, which did not match the client's configuration, and the result was garbage. Telling Kermit to SET FTP DATA-PROTECTION-LEVEL CONFIDENTIAL fixed the problem.

What Are the Variations on SSL/TLS Security for FTP?
The following variations have come up during development of Secure FTP (FTPS):

  1. "SSL CONNECT", in which a connection is made to a special port (e.g. 990 instead of 21) and SSL negotiations happen automatically. Kermit does this when you include the /SSL (or /TLS) switch in the FTP OPEN command.

  2. "AUTH SSL", in which the connection is made to port 21 and then SSL negotiations are started when the client sends an AUTH SSL command.

  3. "AUTH TLS", in which the connection is made to port 21 and then TLS negotiations are started when the client sends an AUTH TLS command, and then a protection level is negotiated with the PROT command.

You have to use a method that is supported by the server. Method 3 is currently favored; the other two are "deprecated". Method 1 is not used by Kermit unless you ask for it. Methods 2 and 3 are negotiated automatically, with the first preference going to TLS; i.e. Kermit sends AUTH TLS first and then sends AUTH SSL only if AUTH TLS is refused. If necessary you can force Kermit to send AUTH SSL first (or send only AUTH SSL) with the SET FTP AUTHTYPE command.

How Do I Get Past Interactive Certificate Warnings?
It seems more that a few FTP sites attempt to set up SSL or TLS security based on innapropriate sample, self-signed, or other invalid certicates. In such cases, the Kermit FTP client prompts you with an error message, such as "Warning: Server has a self-signed certificate" or "Warning: certificate signature failure", prompts you whether to continue:

Continue? (Y/N)

and waits for you to respond Y or N. The solution to this problem is for the administrator of the server to install a valid X.509 certificate, as explained HERE. Failing that, a workaround (which you should employ only with yours eyes open) is to tell Kermit to:

set auth tls verify no

(or "set auth ssl verify no"); this defeats the whole purpose of secure authentication, eliminating any certainty that the server is who it claims to be and that the connection is private.

For more information on automation of secure FTP connections, READ THIS.

How Do I Force a Clear-Text (Non-Secure) FTP Connection?
Secure FTP is rather new on the scene and not all combinations of client and server interoperate smoothly. When faulty negotions for SSL, TLS, or other security methods prevent Kermit from getting through to a server, you might have to force a particular kind of negotiation, or disable security negotiations altogether. For example:

SET FTP AUTHTYPE TLS  ; Forces AUTH TLS because AUTH SSL is "deprecated".
SET FTP AUTOAUTH OFF  ; Disables negotiation of an authentication method.

Why Can't I Make a Secure Connection to WS_FTP?
When Kermit 95 attempts to make a secure FTP connection ("set ftp auth ssl" or "set ftp auth tls") to the Ipswitch FTP server, WS_FTP:

http://www.ipswitch.com/Products/file-transfer.html

the connection fails. Debugging messages show:

ftp: SSL/TLS connect COMMAND error: error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number

The protocol for this is still in the discussion (Internet Draft) stage. The current draft is here:

http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-11.txt

According to the proposed specification, when negotiating AUTH TLS, the TLSv1 protocol is required. WS_FTP, however, does not seem to support SSLv3 or TLSv1 but only SSLv2.

Experimentation shows that the WS_FTP implementation of AUTH SSL and AUTH TLS is incorrect, or at least undependable, in WS_FTP versions 3.0 to 3.1.4 to 4.0.0. In each case it was possible to establish connections using SSLv3. However, more often then not after the SSLv3 client Hello packet was sent to WS_FTP the server Hello packet was never returned. Eventually the connection timed out and the Kermit client reported an incorrect version number because the connection was dropped. There is nothing that can be done about this problem from within the Kermit client, which follows the specification.

Note that there is no way to tell the client to select between SSLv2, SSLv3, and TLSv1. These are (and must be) negotiated between client and server.

What Other Secure FTP Servers Are Available?
See Peter Runestig's public ftp server at ftp://ftp.runestig.com/ for source code to popular FTP servers patched to support AUTH TLS. Also see http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html for more FTPS implementations and a great deal more information on this topic.

[ Top ]


Kermit FTP Client FAQ / Columbia University / kermit@columbia.edu / 8 Apr 2004