|
The Kermit Project |
Now hosted by
Panix.com
New York City USA •
kermit@kermitproject.org
| ||||||||
|
As of: Kermit 95 2.1.3, C-Kermit 8.0.211[ FTP Client Overview ] [ FTP Scripting and Automation Tutorial ] [ IBM Info Exchange ] [ First Health Services ]
This File Last Updated: Tue Sep 27 20:55:16 2011
ftp mget /delete /move-to:../Ready *.edi
you would do:
ftp mget /delete *.edi if success rename *.edi ../Ready
For greater detail, see the Kermit FTP Client Overview.
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...
"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."
ftp open xyzcorp.com /user:olga if fail exit 1 "FTP Connection Failed." if not \v(ftp_loggedin) exit 1 "FTP Login Failed."
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.
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.
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.
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:
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.
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.
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.
SET FTP AUTHTYPE TLS ; Forces AUTH TLS because AUTH SSL is "deprecated". SET FTP AUTOAUTH OFF ; Disables negotiation of an authentication method.
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.
[ Top ]