As of: Kermit 95 2.1.3, C-Kermit 8.0.209[ Overview ] [ Scripting Tutorial ] [ IBM Info Exchange ]
This File Last Updated: Tue Oct 28 11:42:23 2003
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...
Secure FTP connections can be authenticated with SSL or TLS ("ftps"), Kerberos 4, GSSAPI / Kerberos 5, and SRP. SFTP is something else (not FTP). Most secure FTP sites use SSL or TLS.
; Security/Authentication settings.... set ftp autologin on set ftp autoauthentication on set ftp autoencryption on set ftp command-protection-level private set ftp data-protection-level private set ftp passive-mode on set ftp authtype tls set authentication certs-ok on ; Accept host certificate without warning ; General FTP settings (modify as desired)... set ftp dates on set ftp filenames literal set ftp verbose on ; Open the connection... ftp open secureftp.fhsc.com 21000
In Kermit 95, you can create connection with these settings by creating a Dialer entry and filling in its General, FTP, and TLS pages with the corresponding information.
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't log in at all, you have to talk to the firewall administrator. If you can log in but can't transfer data (DIR, GET, PUT, etc), try switching modes (Active/Passive). 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 a different protocol (such as Kermit, which uses only one connection, not two).
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.
For a table of FTPS servers that shows which of the three methods each uses, see:
SET FTP AUTHTYPE TLS ; Forces AUTH TLS because AUTH SSL is "deprecated". SET FTP AUTOAUTH OFF ; Disables negotiation of an authentication method.
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:
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.
[ Top ]