Transmitting CRM data via SFTP

The heartbleed bug is wreaking havoc throughout the IT security landscape.I was recently tasked with developing a windows service that transmits daily files of credit card information from CRM to a third party company via SFTP.  SFTP is a secure version of file transfer protocol that uses SSH (secure shell).  The main difference between FTP and SFTP is that with SFTP your data is encrypted over the network, leaving it less vulnerable to disclosure from packet sniffers.  In addition, it allows for multiple authentication methods, including public key authentication.

This type of authentication requires a key pair, where a public key is placed on the target server and a private key is placed on your server. In addition, the private key can be protected by a unique pass phrase.  Since the public key is unique to the private key, without the matching key placed on either server and the correct pass phrase (if applicable), a connection to the target server cannot be established.  While there are different opinions on security and ease of administration between different authentication methods, public key authentication can provide greater security as it does not depend on the end user to generate a strong password and for some, can avoid frequent password reset policies.

To create the windows service, I used .NET which does not have built-in methods for using SFTP with SSH.  However, there are many 3rd party SSH libraries available to choose from.  The one I used was SSH.NET.  It is available for download from Microsoft’s codeplex: I also used public key authentication and to generate my key pair, I used a popular SSH client.  You can find several supported clients on the web with a quick search.

After setting up the windows service and testing, I was receiving a “Bad packet length” error while trying to establish an SFTP connection.  After doing some research, it appeared that this is a common error often associated with an issue during encryption or decryption.  One reason could be due to extra characters in one of the packets of data being transmitted.  For example, there may be some statements which output certain text messages intended for interactive connections on login such as “Hello user”.  Another reason could be that the default encryption method is unsupported. While there could be other reasons, I was able to get around this error by explicitly stating an encryption method that works.  An example can be found here:

The code I used was:
conninfo.Encryptions.Add(“3des-cbc”, new CipherInfo(192, (key, iv) => { return new TripleDesCipher(key, new CbcCipherMode(iv), null); }));


I hope this experience will help others out there.  For assistance, please contact Beringer.