|
Filed under: FTP
Tags: FTP, FTP Clients
Since I started reviewing FTP clients I've had a few requests to look at a few different FTP clients, and I've managed to analyze a few of those clients in my blog. A few weeks ago I had a request from one of my readers that really caught my interest - Shabbir Talib contacted me through my blog and asked me to review the Kermit FTP Client. I found his request especially appealing because I used to use Kermit before the public learned about the Internet; back then I was using Kermit to access dial-up Bulletin Board Systems (BBS's) and to connect to my college's VAX system. That being said, I hadn't used Kermit in years so I couldn't resist taking a look.
To start things off, the Kermit Project is developed and distributed by Columbia University in New York City. More information about the project, downloadable installation packages, and software licenses for purchase are available from:
I need to stress here the Kermit is actually a full suite of connectivity applications, the Kermit FTP Client is only one part of that communications suite. So from the outset the Kermit is more than overkill if you're just looking to transfer some files to and from your FTP site. The Kermit Dialer takes the place of what most FTP clients would have as a Site Manager, and opening that application will display a large number of templates for various connection types.
Rephrasing my earlier statement, saying that Kermit is overkill is really an unfair assessment when you consider the sheer number of options that Kermit gives you. If you are used to creating and configuring FTP site connections in most FTP clients, you generally have a small handful of options that you can specify. This is not true for Kermit 2.1.3 - the wizard for creating a new FTP connection in the Kermit GUI led me through eleven wizard-based pages of options before the connection was created.
Once you connect, however, the Kermit GUI is just a wrapper for command-line FTP functionality - so you have to know what you're doing in FTP to get around, and there is no explorer-style functionality like you get with graphical FTP clients like Core FTP or FileZilla.
Since the Kermit GUI is just a wrapper for the command-line, you may have already guessed correctly that the Kermit FTP Client (ftp.exe) works just fine from a command prompt. What's more, Kermit has a built-in scripting language that far surpasses the scripting capabilities for the built-in Windows command-line ftp client (also named ftp.exe.) For example, you can script what action to take if something goes wrong - like retrying a failed upload. More information about scripting the Kermit FTP Client is available at the following URL:
From what I've seen of Kermit's scripting support, this appears to be an extremely rich feature for people that need more options for scripting an FTP client.
The Kermit FTP Client supports FTPS, and it allows you to configure options such as separate protection levels for the command and data channels for a connection.
Once you have the security options specified for the connection, connecting to an FTP site using FTPS is pretty straightforward.
I could find nothing in the Kermit FTP Client documentation that referenced support for implicit FTPS, and when I configured one of my FTP sites to use implicit FTPS I could not connect to it using Kermit. (But in all fairness, you may recall from some of my earlier blog posts that Implicit FTPS is often considered deprecated.)
Like the MOVEit Freely FTP client, everything is happening from a command-line, so you can use both FTP7's Virtual Hosts and the actual FTP HOST command. (As I have mentioned in previous blog posts, you should take a look at my Virtual Hosts and Host Names in FTP7 blog post for more information about FTP Virtual Host Names and FTP True Host Names, and see https://datatracker.ietf.org/drafts/draft-hethmon-mcmurray-ftp-hosts/ for more information about status of the FTP HOST command.)
That being said, FTP7 virtual hosts are supported by using the "ftp.example.com|username" syntax when specifying your username, and when you connect to the FTP7 server it will route your requests to the correct FTP virtual host site.
True FTP hosts can be used by specifying the FTP HOST command using the Kermit FTP Client's support for custom commands. The syntax for this command is listed below:
ftp quote host ftp.example.com
Note: You need to send the HOST command before sending USER and PASS.
This concludes our quick look at some of the features that are available with the Kermit FTP Client, and here's the scorecard results:
| Client Name | Directory Browsing | Explicit FTPS | Implicit FTPS | Virtual Hosts | True HOSTs |
|---|---|---|---|---|---|
| Kermit FTP Client 2.1.3 | N | Y | N | Y | Y 1 |
| 1 As noted earlier, true FTP HOSTs are available when using the "ftp quote HOST ftp.example.com" syntax. | |||||
Note: Keeping with my standard disclaimer, there are a great number of additional features that the Kermit FTP Client provides - I'm just keeping the focus on those topic areas that apply to FTP7.
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/For this installment in my series about FTP Clients, I'd like to take a look at the Core FTP client. For this blog post I used Core FTP Lite Edition (LE) version 1.3c (build 1447) and version 2.1 (build 1603), although all of my screen shots are from version 2.1. Core FTP is available from the following URL:
At the time of this blog post, Core FTP provides the LE for free and charges a small fee for a professional version.
Like most graphical FTP clients, the Core FTP LE user interface is pretty easy to use and rather straight-forward - you have separate windows for your local and remote files/folders, as well as a logging window that lists the FTP commands that are sent and the FTP server's responses:
Core FTP LE has a great Site Manager feature, which allows you to store commonly-used connections to FTP sites:
Clicking on the Advanced button gives you a great deal of additional configuration settings, and I'll say more about that later:
This is one of my favorite Core FTP LE features: command-line support. Yes - I'm a geek - and I like being able to script things and run batch jobs to automate whatever I can, so command-line support is always a plus for me. That said, the interface for the Core FTP LE command-line client is not an interactive experience like you get with the built-in Windows FTP.EXE or MOVEit Freely command-line clients. The Core FTP LE command-line client is provided as via the Corecmd.exe file that is installed in the main the Core FTP LE application directory, and is used for a single FTP operation like GET or PUT - although you can pass the name of a script file to execute several commands before/after logging in or before/after a file transfer.
So my final judgment is that the Core FTP LE client doesn't have great command-line support, but it's still really nice to have.
The Core FTP LE client supports both Implicit and Explicit FTPS, so the choice is up to you which method to use. When creating a connection to a server, Core FTP LE has three FTP options that you can use with FTP7:
It's important to choose this option correctly, otherwise you will run into problems when trying access a site using FTPS. If you'll recall from my "FTP Clients - Part 2: Explicit FTPS versus Implicit FTPS" and my other FTP client blog posts, Explicit FTPS allows the client to initiate SSL/TLS whenever it wants, but for most FTP clients that will be when logging in to your FTP site, and in that regard it may almost seem like Implicit FTPS, but behind the scenes the FTP client and server are communicating differently.
In the case of FTP7, the following rules apply:
The type of FTPS is specified on the Connection drop-down menu:
Once you have chosen an FTPS connection, the Core FTP LE client offers you additional options where you can customize which parts of the session will be encrypted:
You can combine the Core FTP SSL options with the advanced SSL policies for your FTP7 sites to customize your security level:
Because Core FTP LE's site manager allows you to specify the virtual host name as part of the user credentials, Core FTP LE works great with FTP7's virtual host names. All that you need to do is use the "ftp.example.com|username" syntax when specifying your username, and when you connect to the FTP7 server it will route your requests to the correct FTP virtual host site.
A really great feature of Core FTP LE is the ability to send pre-login commands, and since this feature allows you to enter custom commands you can specify the actual FTP HOST command as part of your login:
This is a tremendous feature if you're hosting multiple FTP sites on the same IP address, and gives Core FTP LE some of the best support for true FTP HOSTs.
That wraps it up for our quick round-trip for some of Core FTP LE's features, and here's the scorecard results:
| Client Name | Directory Browsing | Explicit FTPS | Implicit FTPS | Virtual Hosts | True HOSTs |
|---|---|---|---|---|---|
| Core FTP LE 1.3 | Rich | Y | Y | Y | Y 1 |
| Core FTP LE 2.1 | Rich | Y | Y | Y | Y 1 |
| 1 As noted earlier, true FTP HOSTs are available in Site Manager using pre-login commands. | |||||
Note: Keeping with my standard disclaimer, there are a great number of additional features that Core FTP LE provides - and I just focused on the topic areas that apply to FTP7.
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/For this installment in my series about FTP Clients, I'd like to take a look at the MOVEit Freely Command-Line Secure FTP Client ("FTPS.EXE") from Ipswitch. For this blog post I used MOVEit Freely FTP Client version 5.0.0.0, and it is available from one of the following URLs:
At the time of this blog post, Ipswitch is providing the MOVEit Freely FTP client for free, although you are required to fill out a registration page with a short questionnaire. For more information on the license for the MOVEit Freely command-line FTP client, please see Ipswitch's web site.
If you're like me and you like to script a lot of batch jobs on your servers, the MOVEit Freely command-line FTP client can be quite handy. The command set for the MOVEit Freely FTP client is a greatly-enhanced superset of the commands that are available with the command-line FTP.EXE client that is built-in to Windows, with added features that make additional functionality possible, such as SSL, passive FTP, resumable downloads, etc. There is a manual available with the MOVEit Freely FTP client, and I highly recommend using the manual as a reference when writing automation scripts because there are a lot of options that are available to you.
One of the great things about the MOVEit Freely command-line FTP client is the ability to use either Passive or Active connections, and you can switch between the two connection types using the "passive" command in the FTP session. This helps immensely when working with firewalls and such. The following example shows what that might look like:
The MOVEit Freely command-line FTP client supports both Implicit and Explicit FTPS, so the choice is up to you which one to use, but I generally use Explicit FTPS since Implicit FTPS should be considered obsolete. The SSL mode is specified using the "-e:" parameter on the command-line, and the 5.0.0.0 version of the MOVEit Freely command-line FTP supports the following values for that parameter:
Parameter FTPS Mode Description off n/a Specifies that no encryption will be used on either the control channel or data channel. Note: This is the default behavior.
on Explicit Specifies that both the control channel and data channel will use encryption over an explicit FTPS connection. Notes:
- This uses the AUTH TLS, PBSZ 0, and PROT P commands when establishing a connection.
- You can use "prot on" and "prot off" to specify whether encryption will be used. (See Note 1 below.)
on-ccc Explicit Specifies the control channel will use encryption over an explicit FTPS connection during login, but the control channel will switch to unencrypted after a login has been established. Data channel connections will still be encrypted. Notes:
- This uses the AUTH TLS, PBSZ 0, and PROT P commands to enable encryption when establishing a connection, then uses the CCC command after the username and password are successfully negotiated. (See Note 2 below.)
- The USER and PASS commands are the only commands that will be encrypted; all other FTP commands are unencrypted.
tls-p Explicit Specifies that both control and data channel will use encryption over an explicit FTPS connection. Notes:
- This uses the AUTH TLS and PROT P commands when establishing a connection.
- You can use "prot on" and "prot off" to specify whether encryption will be used. (See Note 3 below.)
tls-c Explicit Specifies that only the control connection will use encryption over an explicit FTPS connection. Data channel connections will be unencrypted. Notes:
- This uses only the AUTH TLS to enable encryption when establishing a connection.
- You must manually send a PBSZ command before you can use the "prot on" and "prot off" to specify whether encryption will be used. (See Note 1 and Note 3 below.)
tls-c-ccc Explicit Specifies that only the control connection will use encryption over an explicit FTPS connection during login, but the control channel will switch to unencrypted after a login has been established. Data connections will be unencrypted. Notes:
- This uses only the AUTH TLS to enable encryption when establishing a connection, then uses the CCC command after the username and password are successfully negotiated.
- The USER and PASS commands are the only commands that will be encrypted; all other FTP commands are unencrypted.
implicit Implicit Specifies that both the control channel and data channel will use encryption over an implicit FTPS connection, which can only be on port 990 for the FTP7 service. Notes:
- The implicit FTPS connection will encrypt both the control channel and data channel without the use of an AUTH command.
- You can use "prot on" and "prot off" to specify whether encryption will be used. (See Note 3 below.)
implicit-ccc Implicit Specifies that the control channel would use encryption over an implicit FTPS connection during login and switch the control channel to unencrypted after login, but this is not supported in FTP7. The implicit FTPS connection will succeed, but the FTP7 service will return an error when the CCC command is sent. You can ignore the error and continue to use the session. Notes:
- Implicit FTPS connections require encryption for the command channel. (See Note 4 below.)
- You can use "prot on" and "prot off" to specify whether encryption will be used. (See Note 3 below.)
The following notes should be considered:
Note: I turned on debugging for this example with the "-d" option so you can see the sequence of commands.
One last note about FTPS, if you are using a certificate with trust issues, you will see the following prompt displayed:
You can get around this certificate prompt when writing scripts by using the "-z" switch. The following example shows what that might look like:
Note: For this example I bypassed a certificate prompt with the "-z" switch, and I specified passive FTP with the "passive" command.
Since everything is happening from a command-line, you can use both FTP7's Virtual Hosts and the actual FTP HOST command. Once again, see my Virtual Hosts and Host Names in FTP7 blog post for more information about FTP Virtual Host Names and FTP True Host Names, and see https://datatracker.ietf.org/drafts/draft-hethmon-mcmurray-ftp-hosts/ for more information about status of the FTP HOST command.
In any event, FTP7 virtual hosts are supported by using the "ftp.example.com|username" syntax when specifying your username, and when you connect to the FTP7 server it will route your requests to the correct FTP virtual host site. The following example shows what that might look like:
True FTP hosts can be used by specifying the FTP HOST command before the client sends the USER and PASS credentials. This is accomplished in two parts:
The following example shows what that might look like:
This concludes our quick look at some of the features that are available with the MOVEit Freely command-line FTP client, and here's the scorecard results:
| Client Name | Directory Browsing | Explicit FTPS | Implicit FTPS | Virtual Hosts | True HOSTs |
|---|---|---|---|---|---|
| MOVEit Freely 5.0.0.0 | n/a | Y | Y | Y | Y 1 |
| 1 As noted earlier, true FTP HOSTs are available when using the "quote HOST ftp.example.com" syntax. | |||||
Note: Keeping with my standard disclaimer, there are a great number of additional features that the MOVEit Freely command-line FTP client provides - I'm just keeping the focus on those topic areas that apply to FTP7.
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/For this next installment in my FTP Clients series, I'd like to take a look at the FileZilla FTP client. For this blog post I was using FileZilla version 3.1.6.
There are a lot of places where you can find FileZilla, but the best location is the official FileZilla web site at http://filezilla-project.org/. The FileZilla FTP client is free, so you can't beat the price. ;-]
The user interface is pretty straight-forward: you have separate windows for your local and remote files/folders, as well as a logging window that lists the FTP commands that are sent and the FTP server's responses.
FileZilla has a great Site Manager feature, which allows you to store commonly-used connections to FTP sites.
When creating a connection to an FTPS server, FileZilla has two options: FTPS and FTPES. It's important to have this option configured correctly, otherwise you will run into problems when trying access a site using FTPS. If you'll recall from my "FTP Clients - Part 2: Explicit FTPS versus Implicit FTPS" blog post, Explicit FTPS allows the client to initiate SSL/TLS whenever it wants, but for most FTP clients that will be when logging in to your FTP site, and in that regard it may almost seem like Implicit FTPS, but behind the scenes the FTP client and server are communicating differently.
In the case of FTP7, the following rules apply:
Because FileZilla's site manager allows you to specify the virtual host name as part of the user credentials, FileZilla works great with FTP7's virtual host names. All that you need to do is use the "ftp.example.com|username" syntax when specifying your username, and when you connect to the FTP7 server it will route your requests to the correct FTP virtual host site.
Unfortunately, even though FileZilla allows you to send custom commands, you cannot send custom commands outside of an established FTP session, so you can't send the FTP HOST command as part of your login, therefore true FTP hosts are not supported.
Using MS-DOS or UNIX directory listings in FTP7 didn't have any impact on whether FileZilla could render directory listings, nor did configuring any of the other options such as four-digit years, etc. When I create FTP connections in FileZilla's site manager it defaults to auto-detecting the FTP server type, which makes the directory browsing behavior transparent to the client. (Behind the scenes FileZilla is sending an FTP SYST command, which allows FileZilla to detect the operating system.)
You can customize the server type in the advanced settings for your FTP connection, so you can match up your FTP7 directory listing options and the server type that FileZilla expects, but personally I have had no problems with auto-detection so I prefer to use that option.
On a side note, if you intentionally misconfigure FileZilla's server type settings, you can cause FileZilla to behave strangely. For example, choosing a VMS server type and configuring FTP7 to use MS-DOS directory listings will not work, but then again - I wouldn't expect that to work. ;-]
So - that concludes our quick round-trip for some of FileZilla's features, and here's the scorecard results:
| Client Name | Directory Browsing | Explicit FTPS | Implicit FTPS | Virtual Hosts | True HOSTs |
|---|---|---|---|---|---|
| FileZilla 3.1.6 | Rich | Y | Y | Y | N |
Note: As with all of the FTP clients in this blog series, there are a great number of additional features that FileZilla provides - I'm just keeping the focus on a few specific topic areas that apply to FTP7.
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/In my "FTP Clients - Part 1: Web Browser Support" blog post, I mentioned creating a secured Global Listener FTP Site when you're working with FTP virtual hosts, but I didn't really explain what I meant by that or why you would want to do this. With that in mind, today's blog post is to describe how and why you might want to create a Global Listener FTP Site.
To start things off, the concept is really simple - a Global Listener FTP Site is an FTP site with no virtual host binding and anonymous access disabled. It's kind of like having a "Default FTP Site" with restricted access. Here's why this is a good idea when you're working with FTP virtual hosts - some clients default to anonymous, like web browsers, and if anonymous succeeds then the FTP client doesn't have the opportunity to enter the FTP virtual host name, so you can't get to the virtual host site.
To refresh everyone's memory, there are two different methods for binding multiple FTP host names to IP addresses in FTP7:
Unless your FTP client allows sending custom FTP commands, you won't be able to use FTP True Host Names, so if you want to host several FTP sites on the same IP address then your only option is to use FTP Virtual Host Names. The trouble is, as I mentioned earlier, that some FTP clients (like web browsers) try to log in using anonymous first. If all of your FTP sites are bound to a virtual host name, the FTP client will get a "550-No such host is known" error from the FTP server, because the anonymous user did not specify a virtual host name as part of the USER command. On some clients you could fix that by specifying "ftp.example.com|anonymous" as your anonymous user name, but in most cases the login attempt will just fail.
If you create an FTP site that has no virtual host name, then the FTP service will have some place to send these default anonymous requests. When this FTP site does not have anonymous access enabled, the client will be prompted for their username, which will allow you to enter the "ftp.example.com|username" syntax to specify the virtual host name.
Please note that creating a Global Listener FTP site is really more of a workaround for the way that some FTP clients behave - it's certainly not required, and it only applies to situations where you are using FTP Virtual Host Names. For example, if you are using user isolation to restrict users to specific paths on a single FTP site, the Global Listener FTP site would be completely unnecessary.
Note: See my Virtual Hosts and Host Names in FTP7 blog post for more information about FTP Virtual Host Names and FTP True Host Names, and see https://datatracker.ietf.org/drafts/draft-hethmon-mcmurray-ftp-hosts/ for more information about status of the FTP HOST command.
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/In part 2 of my series on FTP clients, I thought it would be best to have a discussion about the differences between Implicit FTPS and Explicit FTPS. In my recent "FTP Clients - Part 1: Web Browser Support" blog post, I referenced Implicit and Explicit FTPS with a link to my Using FTP Over SSL walkthrough. But it occurred to me that some people may not understand the difference between the two, and my upcoming blog posts are going to build upon that knowledge, so I thought that a quick discussion of these two technologies would be prudent.
One of the many limitations of the File Transfer Protocol (FTP) is a general lack of security; e.g. user names and passwords are transmitted in clear text, data is transferred with no encryption, etc. In order to address this situation, FTP over SSL (FTPS) was introduced in Requests for Comments (RFC) article 2228 - FTP Security Extensions, and expanded in RFC 4217 - Securing FTP with TLS to address Transport Layer Security (TLS).
Following up on these RFC articles, the FTP service for Windows Server 2008 added support for FTPS, and the FTP SSL Settings Feature in the IIS Manager allows you to configure your FTPS settings to allow or require SSL, enforce 128-bit SSL, or customize your control/data channel SSL settings.
Explicit FTPS is really what RFCs 2228 and 4217 envisioned; basically the way this works is an FTP client connects over the control/command channel (usually on port 21), and then the client can negotiate SSL for either the command/control channel or the data channel using new FTP commands like AUTH, PROT, CCC, etc.
The FTP service for Windows Server 2008 allows customized settings for both the command/control channel and the data channel through the Advanced SSL Policy dialog:
There are several ways that Explicit FTPS might be implemented depending on your business needs:
Control Channel Data Channel Notes Allow Allow This configuration allows the client to decide whether any part of the FTP session should be encrypted. Require only
for credentialsAllow This configuration protects your FTP client credentials from electronic eavesdropping, and allows the client to decide whether data transfers should be encrypted. Require only
for credentialsRequire This configuration requires that the client's credentials must be secure, and then allows the client to decide whether FTP commands should be encrypted. However, all data transfers must be encrypted. Require Require This configuration is the most secure - the client must negotiate SSL using the FTPS-related commands before other FTP commands are allowed, and all data transfers must be encrypted.
Implicit FTPS takes SSL one step further than simply requiring that SSL-related commands must be sent first like you can with Explicit SSL; with Implicit FTPS, an SSL handshake must be negotiated before any FTP commands can be sent by the client. In addition, even though Explicit FTPS allows the client to arbitrarily decide whether to use SSL, Implicit FTPS requires that the entire FTP session must be encrypted. Basically the way that Implicit FTPS works is that an FTP client connects to the command/control channel, in this case using port 990, and immediately performs an SSL handshake; after SSL has been negotiated, additional FTP commands for the session can be sent by the FTP client.
Using FTPS in FTP service for Windows Server 2008 follows the Internet Assigned Numbers Authority (IANA) specification that the Implicit FTPS command/control channel is on port 990 and the Implicit FTPS data channel is on port 989.
Here's the way that you specify which type of FTP over SSL (FTPS) that you are using in Windows Server 2008:
Note: If you are using FTP on any ports other than the defaults of 21/20 and 990/989, you must make sure that those ports are not already assigned by IANA to another protocol. For more information, see the list of assigned port numbers on IANA's web site.
Choosing whether to use Explicit FTPS over Implicit FTPS is a personal choice, and generally this choice may depend on your business needs or your FTP client. In several FTP clients that I've tested, the FTP client chooses one form of FTPS over another as the default method, and the FTP client may require some manual configuration to use the other.
Shortly after shipping the FTP service for Windows Server 2008 we discovered an issue where the FTP service was not cleaning up Implicit SSL connections properly, and we issued a hotfix rollup package for the FTP service that is discussed in Microsoft Knowledge Base article 955136.
I hope this helps to clear things up a bit. ;-]
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/
