Thursday, March 23, 2006

Secure Shell SSH Enabled FTP Adapter for BizTalk

Secure Shell (SSH) Enabled FTP Adapter for BizTalk

Since there is not enough information available on the sFTP adapters for BizTalk, thought would post this one, This document is more focused on the BizTalk side rather than SSH, however I have provided some basic background information on SSH servers and clients using the RSA key based authentication.

Transfer files to and from Secure Shell (SSH) Enabled servers, need to implement using sFTP protocol,
BizTalk 2004/2006 doesn’t have any built in support for sFTP adapters, they only support traditional FTP adapters, hence we are only left with two options, either we need to develop our own custom adapters for sFTP or purchase it from other clients,
I went ahead using the /n software SFTP Adapter, this lets you add sFTP adapter using the configuration settings, and transfer files remotely using sFTP, also has the feature to implement RSA Key based authentication using public and private keys, which I would be explaining later,
Let me give you some background information for sFTP, where it is used, and how to implement it.
The /n software SFTP Adapter uses the SFTP protocol to transfer files to and from Secure Shell (SSH) Enabled servers. Using the adapter is identical to using the /n software FTPS Adapter, requiring only that you supply a server to connect to, user name, and password. As with the FTPS Adapter, simply bind your port to a BizTalk Orchestration and the SFTP Adapter will take care of the rest.

The SFTP Adapter features:
  1. Send and receive files to/from BizTalk Adapters and any FTP or Secure Shell (SSH) Enabled FTP server
  2. Secure Shell (SSH) data protection
  3. Secure Shell (SSH) - a low-level communications protocol providing security via strong encryption and advanced cryptography.
  4. Secure Shell Public-Key Authentication ( RSA Key )


Get the sFTP adapter, go ahead with the installations, once installation is complete, you have to get the keys and activate it,

Once installation is done we need to register the adapter, which can be done using the BizTalk Administration Console,

sFTP configuration:

Process: RSA key based authentication
A more secure method of authentication is through the use of RSA keys. The basic principle is as follows. Each user generates a 1024bit public/private key pair,
Any host to which the user wants to connect must be aware of his public RSA key, as the server uses it during the authentication process. The user must place his public key living on the originating client machine, into his own authorized_keys file on the server.
When he wants to connect to that server, ssh will first negotiate an encrypted session, then send the server the client's public key. The server checks that the public key is in the user's authorized_keys. If so, the server sends the client a challenge (a random number encrypted with the user's public key). If the client can then send back the random number unencrypted, it has just proven that it has the private key (there is no other way to unencrypt the challenge number), and is therefore authentic.
The user's private key is a very sensitive piece of data - with it, anyone can connect to any host on which the corresponding public key is in the authorized_keys. Therefore, the user's private key is never written to disk unencrypted.
Public key authentication solves this problem. You generate a key pair, consisting of a public key (which everybody is allowed to know) and a private key (which you keep secret and do not give to anybody). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine.
The Authentication layer uses one or more of the following authentication methods to validate the user:
  1. Password Authentication
  2. RSA/DSA Public-Key Authentication
  3. Kerberos Authentication
  4. Host-based Client Authentication
We have focused only on the RSA Public-Key based Authentication in this process,

Summary of the steps;
Key-based authentication in a SSH environment uses public and private keys. The following is a summary of the steps required to generate a key pair for SSH:
  1. An authorized user must generate a public and private key pair.
  2. The user has the option of password protecting the private key (RSA key), which is recommended in almost all environments.
  3. The user's public key needs to be securely uploaded to the SSH server, usually stored in the user's home directory. For example, the user Vamsi would have a public key stored in /home/Vamsi/.ssh/ or Documents and Settings\Vamsi\.ssh of the SSH server.
  4. Authorization, Identification, and authorized_keys files need to be populated.
  5. Public-key authentication needs to be configured on the SSH server, which is enabled by default on many SSH installations.
  1. First, install the SFTP adapter.
  2. Then create the send and/or receive ports as needed based on sFTP configuration.
  3. Once done, assuming that we gotten this far. Let’s say that we have set up a Receive location that will pick up files from some remote SFTP server - so we have to setup a Receive location of transport type /n software SFTP.
  4. From the BizTalk Explorer, edit your receive location. In the Address (URI) configuration property, click on the ellipsis (...). This will bring up properties specific for the adapter. This is will let us configure the actual SFTP transport properties. Included here are properties to specify the sftp server, port, user, etc.
  5. Now, lets say the client has given us an RSA (private) key for authentication to this SFTP server where we will pick up files. This means we want to set the "SSH Auth Mode" property to "Public Key" (as opposed to password authentication). This tells the adapter to authenticate to the server using a username and RSA key (private) rather than a username and password. Specify the username of course in the "SSH User" property. We can leave the "SSH Password" property blank in the case of public key based authentication.
  6. Now that we've told the adapter to use public key auth, we must point it to the private key to use. I have used RSA key, (Note: If we need we can also go with a PFX file, or a PEM file, we can install the key to a machine store and access it from there as well, depending on the client needs).
  7. Anyway lets come back to the way I have implemented, I went with RSA key based authentication, hence I had to provide the SSH Cert Store with location of the rsa key(id_rsa), for the adapter to pick it up,
  8. Once this is done, we need to specify what type of SSHCertStore it is, Typically the public key might be in a PEM file, in which case you'd set the "SSH Cert Store Type" property to "PEMKey".
  9. Finally set the "SSH Cert Subject" to "*", which means the first certificate or key in the store.
  10. That’s it, we should be able to capture the file from the remote location,
SFTP Transport properties:

Here I have provided both types of authentication,
  1. Password based authentication
  2. RSA key based authentication
This is based on the userID and password based authentication:

This is based on the RSA key based authentication:

sFTP Adapter properties(nSoftware):

  1. Remote File: %SourceFileName%
  2. Remote Path: “/usr/Path/”
  3. SSH Accept Server Host Key: ALL
  4. SSH Auth Mode: Public Key
  5. SSH Cert Store: “home\RSAKey\SFTP_DEV\id_rsa”
  6. SSH Cert Store Password: <Empty>
  7. SSH Cert Store Type: PEMKey
  8. SSHCert Subject: "*"
  9. SSHHost: <IPAddress>
  10. SSHPassword: <empty>
  11. SSHPort: 22
  12. SSHUser: <user>
Thats it!!!

Overview of SFTP, FTPS, SCP and FTP

Overview of SFTP, FTPS, SCP and FTP:

I am not going go in detail about sFTP or FTPS here, since my main motive is to integrate sFTP with BizTalk, hence if you need more information need to research by yourself


"sftp is an interactive file transfer program, similar to ftp, which performs all operations over an encrypted ssh transport".

SFTP is part of the OpenSSH standard. Along with SSH you have capabilities to use commands such as SCP, SFTP, etc. So....SFTP is very secure because each packet is encrypted and compressed while sending is taking place. It utilizes public key authentication and compression. The Abbreviation SFTP nowadays invariably means Secure File Transfer Protocol, however there is another protocol with the same abbreviation (Simple File Transfer Protocol). So lets not get confused.

Differences between FTP, SFTP and FTPS:

Why not just use FTP? Why should I use Secure FTP instead of FTP? Why is SFTP better than FTP?


FTP (File Transfer Protocol) does not take any precautions to protect information transmitted during a session. This includes your username, password, and any files transmitted.

SFTP (Secure File Transfer Protocol) is a secure replacement for FTP (File Transfer Protocol) based on the Secure Shell protocol. Unlike FTP, SFTP encrypts both commands and data providing effective protection against common network security risks. SSH Client and Server provide both command-line SFTP tools and a graphical user interface for Windows users. SFTP encrypts the session, preventing the casual detection of your username, password or anything you've transmitted.

The major reason for implementing SFTP versus FTP is security. FTP is not even remotely secure. During an FTP session, your username and password are transmitted in clear text. If someone is eavesdropping, it is not difficult for them to log your FTP username and password.

In FTP all data is passed back and forth between the client and server without the use of encryption. This makes it possible for an eavesdropper to listen in and retrieve your confidential information including login details. With SFTP all the data is encrypted before it is sent across the network.

SFTP is not the same as FTP/S; the latter implements the original FTP protocol through a separately-created secure tunnel.

FTPS is a real ftp that uses TSL/SSL to encrypt the control session and if required the data session. With FTPS the control session is always encrypted, but the data session might not be. Why is this? Because with the control session encrypted the authentication is protected and you always want this (normal ftp uses clear text). If you are NOT pre-encrypting the file, you want the data session encrypted so that the file is encrypted while the data is in flight. However, if you are pre-encrypting the file then you do not need to have the data connection encrypted as you do not need to add the overhead of encrypting the data connection, since the file is already encrypted. Understand that SFTP is SSH file transfer and FTPS is FTP with SSL, FTPS is a file transport layer on top of SSL or TLS. The FTPS adds SSL-enabled FTP send and receive capabilities, uses the FTP protocol to transfer files to and from SSL-enabled FTP servers.

SCP (Secure Copy) is a non-interactive command-line tool for securely transmitting files from a machine to another. It is a secure replacement for RCP and provides a similar command-line syntax. SCP is strongly based on SFTP but is often a more suitable choice when setting up unattended file transfers using scripts.

List of SFTP Servers:
SSH Servers

OpenSSH (

  1. OpenSSH is a free version of the SSH protocol suite. OpenSSH servers and clients are available for both Unix and Windows.
  2. OpenSSH has been ported to Windows with the popular CYGWIN utility. The project was created by Network Simplicity (
SSH2 (
  1. SSH2 is a commercial version of SSH, with required license fees for commercial use (noncommercial use is free). Commercial SSH clients/servers are available for both Windows and Unix systems.
List of SFTP Clients:

There are many client tools, you can use to connect to the SFTP servers, few of them I was interested were Core FTP LE, putty.exe, freeSSHd.exe, FileZilla_Server-0.9.12c.exe, Cygwin, WINSCP,

Your choice of an SSH client is highly dependant on the type of functionality required for SSH. For example, if SSH is being deployed primarily for its file-transfer capabilities, Core FTP/WinSCP and SSH Communications' SSH clients are probably good choices. On the other hand, if SSH is being deployed for remote shell access via an HTTP proxy server, the SecureCRT and PuTTY clients are probably good choices. Lastly, if SSH is being deployed for remote access from undefined and uncontrolled terminal locations, MindTerm is probably a good choice, since it offers SSH access with the need of only a Web browser.

Operating system support
The operating systems the clients can run on.

Protocol support
Information about what internet protocols the clients support. External links lead to information about support in future versions of the clients or extensions that provide such functionality.