MFT - Setting up SFTP Transfers using Key-based Authentication

Executive Overview

MFT supports file transfers via SFTP. Often MFT customers receive a public key from their partners and want to use them to receive files via SFTP. This blog describes the setup required to enable such an MFT flow that would receive files from partners using key-based authentication.

MFT includes an embedded SFTP server. We will configure it with the supplied public key to receive files from remote partners. Upon receipt of a file, a simple MFT transfer will initiate and place the file in a pre-defined directory within the local filesystem.

Solution Approach

Overview

The overall solution consists of the following steps:

• Generate public-private key pair on the remote machine and copy the public key to MFT server
• Generate public-private key pair on the machine running MFT server
• Import the private key from MFT machine in MFT keystore
• Import the public key from partner machine in MFT keystore
• Configure SFTP server with private key alias
• Configure MFT users and corresponding SFTP directories to be used by remote partners
• Enter SSH Keystore password
• Restart embedded SFTP Server
• Create Embedded SFTP Source
• Create File Target
• Create an MFT transfer using the above source and target
• Deploy and Test

Task and Activity Details

The following sections will walk through the details of individual steps. The environment consists of the following machines:

• VirtualBox image running MFT 12c on OEL6 (oel6vb)
• Remote Linux machine used for initiating the transfer via SFTP client (slc08vby)

I. Generate public-private key pair on the remote machine and copy the public key to MFT server

To generate a private-public key pair, we use the command-line tool ssh-keygen. The tool creates 2 files for private and public key. For our purposes in this exercise, we will only be using the public key by copying it to the MFT machine from here. As a common practice, all the key files are saved in $HOME/.ssh directory. A transcript of a typical session is shown below.

[slahiri@slc08vby .ssh]$ pwd
/home/slahiri/.ssh
[slahiri@slc08vby .ssh]$ ssh-keygen \-t rsa \-b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/slahiri/.ssh/id_rsa): sftpslc
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in sftpslc.
Your public key has been saved in sftpslc.pub.
The key fingerprint is:
56:db:55:48:4c:db:c4:e1:8b:70:40:a8:bf:12:07:94 slahiri@slc08vby
The key's randomart image is:
+--[ RSA 2048]----+
|        . oo +o++|
|       E .  . +=.|
|      . . .. .o..|
|       o . oo.. .|
|        S . .. . |
|       o o       |
|        o .      |
|       . .       |
|        .        |
+-----------------+
[slahiri@slc08vby .ssh] ls
sftpslc  sftpslc.pub
[slahiri@slc08vby .ssh] cat ~/.ssh/sftpslc.pub | ssh oracle@oel6vb "cat >> ~/.ssh/authorized_keys"
oracle@oel6vb's password:
[slahiri@slc08vby .ssh]

II. Generate public-private key pair on the machine running MFT server

As shown in the previous step, ssh-keygen is used on the MFT machine to generate a key pair. From the pair generated here, we will only be using the private key for our exercise. The session transcript is shown below.

[oracle@oel6vb .ssh]$ pwd
/home/oracle/.ssh
[oracle@oel6vb .ssh]$ ssh-keygen \-t rsa \-b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/oracle/.ssh/id_rsa): sftpmft
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in sftpmft.
Your public key has been saved in sftpmft.pub.
The key fingerprint is:
36:a8:ac:a7:0c:bd:34:c9:bd:cd:1b:fe:05:a8:1d:47 oracle@oel6vb
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| E |
| + |
| + S |
| o + + + o |
|. * = o . |
| + +.= . . |
| =o. =o. |
+-----------------+
[oracle@oel6vb .ssh]$ ls
sftpmft sftpmft.pub
[oracle@oel6vb .ssh]$

III. Import the private key from MFT machine in MFT keystore

The private key from Step II is imported into MFT keystore using WLST utility. It must be noted that for MFT, a different version of WLST is shipped and installed with the product. It is found in /mft/common/bin directory. The version of WLST in this directory must be used. The WLST session should be connected to the MFT Server port using an Administrative credential. A typical session transcript is shown below.

[oracle@oel6vb .ssh]$ cd /u01/oracle/SOAInstall/mft/common/bin
[oracle@oel6vb bin]$ ./wlst.sh
CLASSPATH=:/u01/oracle/SOAInstall/mft/modules/oracle.mft_12.1.3.0/core-12.1.1.0.jar

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> connect("weblogic","welcome1","t3://localhost:7003")
Connecting to t3://localhost:7003 with userid weblogic ...
Successfully connected to managed Server "mft_server1" that belongs to domain "base_domain".

Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.

wls:/base_domain/serverConfig> importCSFKey('SSH', 'PRIVATE', 'MFTAlias', '/home/oracle/.ssh/sftpmft')
CSF key imported successfully.
wls:/base_domain/serverConfig> listCSFKeyAliases('SSH', 'PRIVATE')
Key Details
--------------------------------------------------------------------------
'MFTAlias', Format PKCS#8, RSA

IV. Import the public key from partner machine in MFT keystore

The same WLST session can be used to import the public key copied over from the remote machine in Step I. It must be noted that the public key alias used here should be the same as the userID that is to be used by the remote SFTP client to connect to the embedded SFTP server. Transcript of a sample session is shown below.

wls:/base_domain/serverConfig> importCSFKey('SSH', 'PUBLIC', 'MFT_AD', '/home/oracle/.ssh/authorized_keys')
CSF key imported successfully.
wls:/base_domain/serverConfig> listCSFKeyAliases('SSH', 'PUBLIC')
Key Details
--------------------------------------------------------------------------
'MFT_AD', Format X.509, RSA

wls:/base_domain/serverConfig> exit()

Exiting WebLogic Scripting Tool.

[oracle@oel6vb bin]$

V. Configure SFTP server with private key alias

After logging in to MFT UI, go to Administration Tab. Under Embedded Servers, go to sFTP tab and complete the following:

1. enable SFTP
2. set Public Key as authenticationType
3. set KeyAlias to the private key alias set during import in Step III.
4. save settings

Example screenshot is shown below.

VI. Configure MFT users and corresponding SFTP directories to be used by remote partners

From MFT UI, under Administration Tab, configure the user and the SFTP root directory, that will be used by in remote SFTP client session. Note that the userID will be the same as the Public Key Alias, used while importing the public key in Step IV.

Sample screenshots for user and directory are shown below.

VII. Enter SSH-Keystore Password

From the MFT UI, go to Administration tab and select KeyStore node in the left navigator tree.

Enter the password for SSH-Keystore as the same passphrase used during key pair generation on local machine in Step II.

Example screenshot is given below.

VIII. Restart embedded SFTP Server

The embedded SFTP Server should be restarted for any embedded server related configuration changes to take effect. In case the SFTP server is not running, it can be started now.
This wraps up the administrative setup necessary for the exercise. The following sections are part of a simple MFT design process to create a source, target and transfer.

IX. Create Embedded SFTP Source

From MFT UI, go to the Designer tab. Create a SFTP Source pointing to the directory created in Step VI. Sample screenshot is shown below.

X. Create File Target

For the sake of simplicity, a local file directory is chosen as the directory. From the MFT UI, navigate to the Designer tab and create a target as shown below.

XI. Create a transfer using the above source and target

From the Designer tab within MFT UI, create a transfer using the source and target created in Steps IX and X. Sample screenshot is shown below.

XII. Deploy and Test

After deploying the transfer, we are ready to test the entire flow.

We initiate the test by starting a simple, command-line SFTP client in the remote machine (slc08vby) and connecting to the embedded SFTP server running within MFT. The userID is the one specified in Step IV and VI (MFT_AD). The passphrase is the same as that used in generating the key pair in the remote machine during Step I.

After the sftp session is established, we put a file into the SFTP root directory of the user on MFT server machine, as specified in Step VI. The transcript from a sample SFTP client session is shown below.

[slahiri@slc08vby ~]$ cat ~/.ssh/config.sftp
Host 10.159.179.84
Port 7522
PasswordAuthentication no
User MFT_AD
IdentityFile /home/slahiri/sftpslc
[slahiri@slc08vby ~]$

[slahiri@slc08vby ~]$ sftp -F ~/.ssh/config.sftp oel6vb
Connecting to oel6vb...
Enter passphrase for key '/home/slahiri/sftpslc':
sftp> pwd
Remote working directory: /MFT_AD
sftp> put sftptest.txt
Uploading sftptest.txt to /MFT_AD/sftptest.txt
sftptest.txt                                  100%   24     0.0KB/s   00:00
sftp> quit
[slahiri@slc08vby ~]$

After the SFTP operation is completed, the MFT transfer takes over. MFT picks up the file from the embedded SFTP source and places it in the directory within the local file system, defined as target. Example screenshot from Monitoring Tab of MFT UI is shown below.

Finally, we verify that our test file is saved in the local directory specified as the target in Step X.

[oracle@oel6vb in]$ pwd
/home/oracle/in
[oracle@oel6vb in]$ ls
sftptest.txt
[oracle@oel6vb in]$

Summary

The test case described here is one way to establish secure transfers with MFT. There are other use cases as well and will be discussed in other articles of this blog series on MFT. For further details, please contact the MFT Product Management team or SOA/MFT group within A-Team.

Acknowledgements

MFT Product Management and Engineering teams have been actively involved in the development of this solution for many months. It would not have been possible to deliver such a solution to the customers without their valuable contribution.