File transfer security is important when transferring files across the Internet. One of the often overlooked areas, when addressing layered security, is file transfer security. Some companies (including Internet Service Providers) seldom make the switch, in a timely manner, to replace File Transfer Protocol (FTP) clients with a secured solution such as Secure FTP (SFTP) and a Secure Shell (SSH2) Server. Other companies replace Telnet...
servers with SSH servers, but do not address file transfer security. Then there are companies that implement SFTP with an SSH2 Server, and overlook users that utilize FTP clients for file transfers in other areas. This article provides the answers that you will need to configure and operate an SFTP client (SecureFX) with an SSH2 Server (WinSSHD) - securely.
When was the last time that confidential data was delivered over a standard non-secure transfer program, such as an FTP client, in your company or over the Internet?
Companies sending sensitive files over a network - unencrypted and unprotected - may find it more difficult to establish secure transfers and an overall sense of 'real' data security. File transfers that use the standard File Transfer Protocol (FTP) are susceptible to eavesdroppers, and can greatly benefit from the high level encryption ciphers and security that SSH2 protocol offers. By implementing an SFTP client with an SSH2 Server organizations can expect to achieve an effective level of file transfer security.
Transferring files (manually or automatically) can be done without security, however, with the availability of SSH2 - and the ease of setup of an SFTP client and an SSH2 server - confidential file transfers no longer have to be exposed to unwanted network solicitors. Let's begin to secure your file transfers by configuring an SFTP client and SSH2 server. In this case we'll use SecureFX by Vandyke Software (www.vandyke.com), and WinSSHD Server by Bitvise Products (www.bitvise.com).
NOTE: It is important to note that the hands-on tips included in this article (as with other articles I have written) have been fully tested in a live production environment that supports many users and file transfer requirements.
The SecureFX client requires SSH2 (I'll describe SSH2 later) utilizes an interface similar to Windows Explorer, is quickly configurable with password authentication and public key support, and works very well with WinSSHD Server to establish a 'real' sense of security moving forward. A 30-day evaluation copy of SecureFX is available and can be downloaded at http://www.vandyke.com/download/securefx/index.html.
If budget constraint is an important issue, then check out www.openssh.org for free SSH clients, such as WinSCP (secure copy with PuTTY) and Secure iExplorer GPL (another Explorer-like interface), for the Windows platform. However, keep in mind that some free clients - as is the case with some third-party clients - may only be compatible with SSH1 and not SSH2 protocol. SSH2 provides improvements over SSH1 and both versions protect sensitive data in file transfers by utilizing strong cryptography that is difficult to hack. Although SSH is typically used to address the security issues of telnet, remote shell (rsh), and remote login (rlogin), standard non-secure transfer programs can benefit from SSH2.
The combination of password and public key authentication (private / public key pair) using digital signatures - per account or shared key among trusted hosts - enable host-to-host encrypted connections over an insecure infrastructure, such as the Internet. However, depending on the size of the organization, it is important to plan ahead and determine the number of public keys that will be supported by the SSH2 server. For example, WinSSHD Server can be configured to require 1) a password or key, and 2) a password and key combination for authentication. But rather than generate a key from every host and then register the key on the WinSSHD Server, you can copy the private / public key pair and distribute the key pair to a group of trusted hosts. Unlike the private key, which is stored on the host side only, the public key is uploaded to the WinSSHD Server, and is stored on both the host, and on the server; the server acknowledges the public key, once uploaded and assigned to a specific login account. If supporting both password and key authentication, the client must be configured to match the authentication set on the WinSSHD Server.
SecureFX (SFTP Client)http://www.iana.org/assignments/port-numbers
Next, enter the username and password created on the WinSSHD Server - the username is an account that exists locally on the server. The Initial Directory and other connection settings can be overwritten by the configuration set on the WinSSHD Server. Right-click on the newly created session and select Properties.
Next, confirm that Protocol, Hostname, Port, and Username reflect your input. (Note that password is set for primary authentication; secondary authentication is set to none, by default. We will revisit this section later on.) Go to Category>Site>SSH2 Options and confirm that "None" is NOT selected for Cipher or MAC. Now, double-click on the new session to authenticate to the WinSSHD Server using password. Upon contacting the server, you will receive a New Host Key message box. Click on the Accept & Save button to accept the host key (e.g., MD5 hash fingerprint) from the server.
At this time, you should be able to log in using password authentication. If you receive an error: "Unable to authenticate using any of the configured authentication methods," it is most likely due to the setting "PWD and Key" in WinSSHD Server (see below) - in which case, you will need to change the SFTP client authentication to "Password and Key", to match the authentication requirements of the server. Now let's create the public-key that will be copied up to the WinSSHD Server. To generate a new public / private key pair, go to Tools>Create Public Key to launch the Key Generation Wizard. Select DSA For Key type, enter a Passphrase, and then select 1024 bits (minimum recommended strength) for Key length. Next, move the mouse around to create random input for the key generation process. Name the private key and note the default location for both keys (the public key has the suffix .pub):
C:Documents and Settings<username>Application DataVanDykeSecureFX<FILE>http://www.iana.org/assignments/port-numbers
Permit Remote Administration = No Map Remote Home Directory = No Permit Terminal Shell = No Terminal Shell = C:Program FilesBitvise WinSSHDsftps.exe Initial Directory = C:<unique folder name> Permit Exec Requests = No Permit C2S Port Forwarding = No Permit S2C Port Forwarding = No
Drop down to the Accounts section and deny "all others" from authenticating to WinSSHD. Enter a local Win2K/NT account, and change the Authentication Type to "PWD and Key". Except for SFTP, everything else on the account should be set to no. Click on the Keys field for the account that will use the public key (the one created on the SecureFX client), and import the key.
Stop and Start the WinSSHD service.
Note: Use caution when using PuTTY as there have been reported bugs, such as no limits on socket buffering and issues with SCP.
Congratulations! You have configured an SFTP client and an SSH2 server.
For more security informationwww.medinasystems.com
Luis Medina is the author of "The Weakest Link Series," which offers network managers an opportunity to identify ongoing network security issues. Luis also answers security questions in our Ask-the-Expert section. Submit a security question to Luis here or view his previously answered Ask-the-Expert questions.
Dig deeper on Managed services