This tutorial describes how to configure a YADE Command Line Client (CLC) to transfer files to a target server via a second YADE CLC that has been installed on a jump host.

This is a relatively complex example but it has been deliberately selected to demonstrate how simply real life use cases can be configured using YADE and the XML Editor.

This tutorial describes the use of the SOS XML Editor to generate the necessary transfer configuration file. The use of the Editor is intended to simplify and speed up the configuration process, particularly for complex file transfer situations, and reduce the occurrence of configuration errors. The Editor uses an XSD schema to generate and validate the YADE configuration. In addition, the Editor is able to generate the the new XML format that will be introduced with release 1.11 of YADE. A comparison between the new XML format and the current (i.e. used in releases up to and including 1.10) is available in the YADE user manual Configuring and Running File Transfers section.

YADE Tutorials List

This tutorial is part of a series describing how to get started with using the YADE Client via its Command Line Interface and configuring simple file management tasks.

YADE Client Command Line Interface

  1. Getting Started and Downloading files
  2. Simple File Selection
  3. More Advanced File Selection
  4. File Transfer

  5. Checking files for completeness
  6. Public / Private Key Authentication
  7. Transfer via a Jump Host / DMZ

YADE Background Service

  1. Installation, Configuration and Use

See the Using the tutorials with the YADE Client Command Line Interface article for information about setting-up and running the tutorial examples.

Background Information:

Download Configuration Files

  • The XML configuration file used for the example shown in this tutorial can be downloaded using the following link:
  • Note that in contrast to the other YADE tutorials we have not opened the servers used to make this tutorial for public use. 
    Users wishing to test out this configuration will have to first of all set up their own test environment.

Use Case

Consider the situation in an organization where security restrictions prohibit direct file transfer both between parts of the organization network and the Internet and between different organization locations.

In particular, consider the case where a user wishes to transfer files from their desktop computer over the Internet to a server, Japan, and where:

  • The user can only reach the Internet via a proxy server (in this example, Homer).
    The Japan server can only be reached via a jump host on a server UK, which is installed in a so-called demilitarized zone (DMZ).
    The jump host already has a YADE Command Line Client installed to enable file transfer across the DMZ.
  • Direct connections between the user's computer (localhost) and the Internet and from the Homer proxy server to the Japan target server are blocked.



  1. The jump fragment

    1. The first step is to configure the JumpFragment for the London server, as shown in the next screenshot.
      This configuration fragment is identified by the name attribute of the JumpFragment parameter and as can be seen in the screenshot has three main components:

      1. BasicConnection element,

      2. an SSHAuthentication element and

      3. the ProxyForSFTP element. Detailed descriptions of all these elements can be found in the relevant Parameter Reference sections, which are linked behind the parameter names.

    2. Note that:

      1. The JumpCommand parameter specifies the operation that is to be carried out by the YADE Client on the jump server.

      2. The AuthenticationFile element specifies the path to the RSA key file on the user's local file system that is used to authenticate the user on the jump host.

  2. The target fragment

    1. The second step is to configure the target protocol fragment for the London server, as shown in the next screenshot.
      1. This element specifies the parameters required so that the YADE Client on the jump host can access the target server.
      2. As can be seen from the screenshot the fragment is protocol-specific and contains a JumpFragmentRef parameter which specifies the name of the JumpFragment element to be used to access the target server.
        This means that it is only necessary to specify the target server and the jump host will be automatically added once the JumpFragment has been configured and referenced for the target.

  3. The transfer profiles

    1. Transfer to the Internet
      The next screenshot shows the transfer profile specifying the operation to be carried out (copy), the operation source (local) and target (the Japan server accessed using the Tokyo account via the UK jump server, specified using the SFTPFragmentRef parameter)

    2. Transfer from the Internet
      The next screenshot shows the profile configuration that would be required to carry out a similar transfer operation from the Japan server to the user's local file system via the jump host and proxy server.
      This profile can be seen to be very similar to the jump_copy_to_internet profile shown above and illustrates how relatively simple configuration elements can be generated.

Generation of the settings.ini configuration file

  • The XML Editor can save configurations in XML format using the standard Save or Save as buttons shown in the editor task bar. This file is compatible with the YADE version 1.11 described ...
    The YADE Xml2ini Converter Button in the task bar causes the Editor to generate a settings.ini file that is compatible with earlier YADE releases.
  • For more information about using the Editor see the XML Editor Usage for compatible .ini and .xml configuration files article.

Calling the transfer operation (YADE Releases 1.10 and earlier)

A jump host file transfer operation is called from the command line in a similar manner to a 'standard' file transfer operation - i.e. by calling  the configuration settings file and the relevant profile where the settings file has the name jump_host.ini.

However note that the jade4DMZ.cmd script is called instead of the standard jade.cmd script.

The call for a Windows system would be:

Calling the 'jump_copy_file_to_internet' profile - Windows'
jade4dmz.cmd -settings="%USERPROFILE%\jade_demo\tutorial_7_jump_host\jump_host.ini" -profile="jump_copy_to_internet_proxy"

and on a Unix system:

Calling the 'jump_copy_file_to_internet' profile - Unix'
./ -settings="${HOME}/jade_demo/tutorial_7_jump_host/jump_host.ini" -profile="jump_copy_to_internet_proxy"

File Transfer Details

  • Whilst any protocol can be used for the transfer stage from the jump host to the target, transfer from the source to the jump host must be carried out using SFTP.
  • Atomic transfer is the default mode for both stages of a jump host transfer operation. This means that if a file transfer error occurs in either stage of the operation, none of the files that would otherwise have been selected will be transferred. Files already transferred to either the jump host or the target server will be deleted.

Integration with the YADE Background Service

  • The YADE Background Service is not able to directly access the YADE Client on the jump server. This means while the Background Service can access the transfer history and log files of the local YADE Client, it is not able to access log or file transfer information from the YADE Client on the jump host.
    However the originating YADE Client (i.e. the current example, the client on the source server) receives feedback from the client on the jump host containing information about whether transfer from the jump host to the target server was successful.