Define protocols, partners, and flows

Available on Windows (win-x86-32, win-x86-64) and Unix (Linux-x86-64, Linux-ia64-64, Sun-x86-64, Sun-SPARC-64)

This section presents the protocol and partner definitions required to use SFTP with Transfer CFT.

Note Transfer CFT provides a basic SFTP configuration template. Click here to view the template.

Define the protocol parameters (CFTPROT)

The following parameters are used for SFTP protocol:

  • SAP: TCP/IP port for the server.
  • SPACING, RPACING: Internal size, in KB, between two synchronization points for the receiver. The value 0 means that there is no synchronization point. The default value is 32,000 (32MB).
  • SSH: Link to the CFTSSH object.
  • SCOMP: SSH compression when sending a file.
    0: No compression.
    1-9: Compression level, 9 is the most efficient but slower. The default is 1, which offers good compression with the smallest CPU overhead.
  • RCOMP: SSH compression when receiving a file.
    0: No compression.
    1-9: Compression level, 9 is the most efficient but slower. The default is 1, which offers good compression with the smallest CPU overhead.

Example

cftprot id = SFTP,

TYPE = 'SFTP',

SSH = 'SSH_DEFAULT',

SAP = '1763',

NET = NET0,

     RPACING = '100',

     RRUSIZE = '32750',

     RTO  = '260',

     DISCTC = '60',

     DISCTD = '10',

     DISCTS = '60',

     RCOMP       = '9',

     SCOMP       = '9'

Define the partner parameters (CFTPART)

Use the parameters in this section to define SFTP for the CFTPART object.

  • A CFTPART object represents an application, with one SFTP user per application (CFTPART = one application).
  • When Transfer CFT is the server, the client log-in determines the possible partners (CFTPART object), which must match an NRPART value. Transfer CFT then checks the client password, which must match the NRPASSW parameter. Each CFTPART NRPART must be unique: you cannot have 2 partners with the same NRPART value.
  •     Client Login arrow to NRPART, Ciient Password arrow to server NRPASSW
  • When Transfer CFT is the client, the Transfer CFT NSPART parameter provides the login, and NSPASSW provides the password.
  • Client NSPART arrow to Server Login, Cient NSPASSW arrow to server Password
  • The CFTPART model file identifier defines the default flow associated with a partner.
  • CFTPART id=partner,IDF=<default_model_for_this_partner>,…
  • Authorization for flows is provided in the SAUTH/RAUTH parameters for the CFTPART.
Note We recommend that you use the same value for the SAUTH and RAUTH parameters for a particular CFTPART definition. However, when Transfer CFT is acting as the server and you display the directory (ls), this displays the list of authorized flows for both the SAUTH and RAUTH.

The following parameters are used for SFTP protocol:

  • NRPART: User login in server mode
  • NRPASSW: User password in server mode
  • NSPART: User login in client mode
  • NSPASSW: User password in client mode
  • IDF: Model file identifier
  • SAUTH: Links to a CFTAUTH object containing the list of authorized flows
  • RAUTH: Links to a CFTAUTH object containing the list of authorized flows
  • PROT : Protocol ID
  • SSH: Links to the CFTSSH client. If this is not defined, Transfer CFT uses the CFTSSH (direct=Client) corresponding to the SSH value of the CFTPROT ID referenced by PROT parameter referenced in the CFTPART. The SSH profile contains the parameters to establish the SSH connection used by SFTP in client mode.
  • CFTPROT ID=SFTP,

    TYPE=SFTP,

    SSH=SSH1,

     

    CFTSSH id=SSH1,

    Direct=client,

    CFTSSH id=SSH2,

    Direct=client

     

    CFTPART ID=PART1,

    PROT=SFTP,…

    (no SSH parameter defined)

     

    For partner PART1, SSH1 profile used in client mode

     

    CFTPART ID=PART2,

    PROT=SFTP,

    SSH=SSH2,…

     

    For partner PART2, SSH2 profile used in client mode

Example

You require at a minimum the following definitions.

SERVER DEFINITION

 

cftpart id = SERV_SFTP,

prot = SFTP,

nrpart = "userlogin", /* enclosed in quotes " for case-sensitivity */

nrpassw = "userpassword"

 

cfttcp id = SERV_SFTP,…

 

 

CLIENT DEFINITION

 

cftpart id = CLIENT_SFTP,

prot = SFTP,

sap = <remote SFTP port>,

nspart = "userlogin",

nspassw = "userpassword"

 

cfttcp id = CLIENT_SFTP,

host = <remote host address>,… /* Partner Internet address */

Server mode

The Transfer CFT SFTP server is initialized using information found in the CFTPROT, CFTSSH server and CFTNET parameters.

For incoming client connection, the server searches for a CFTPART whose NRPART parameter is equal to the SFTP client log in. If none match, the connection is rejected. This CFTPART is used to identify the partner for the file transfer.

Server sends authentication to the client

  • SRVPRIVKEY: Is the Transfer CFT server's private key, which is used to authenticate the client (CFTSSH direct=server).
    • If SRVPRIVKEY(CFTSSH direct=server) is not set, Transfer CFT cannot start, and the message displays CFTN05E SFTP bind() failed: ECDSA, DSA, or RSA host key file must be set.
  •  Srvpubkey: Is the authorized public key used to verify the authenticity of the SFTP server (CFTSSH direct=client).
    • If Srvpubkey(CFTSSH direct=client) is not set, there is no server authentication and the server public key is accepted automatically.

Server checks the client authentication

  • NRPART=login name. The NRPART is case-sensitive when the value is enclosed in quotes " ", for example, NRPART="UsErLoGin".

Password authentication

  • NRPASSW=login password

Different modes of authentication are possible depending on the following value:

  • NRPASSW=password: This is a static password. Transfer CFT checks the provided password against this one.
  • NRPASSW=@|#mypasswordfile (@ on Unix and # on Windows): Transfer CFT checks the provided password against the one specified in the file.
  • NRPASSW=<empty>: If the password is empty, there is no authentication by password.
  • NRPASSW = _AUTH_: The authentication method is the one specified in uconf:cft.server.authentication_method (see cftlogin API).

The remote user possesses the associated private key.

Key authentication

When DIRECT=SERVER, set the CLIPUBKEY in CFTSSH (for example, CLIPUBKEY = '#conf/pki/public.pub'). For more information, please see Define CFTSSH (SFTP).

Key and password authentication

If both the parameters CLIPUBKEY and NRPASSW are defined, there is a double authentication by key and password. Uses both the key and password authentication as described above.

Model file identifier

Between two Transfer CFTs, the IDF is transmitted by the protocol. On the server side, the IDF is compared with the list of possible IDFs in the CFTAUTH object, as referenced in the SAUTH and RAUTH parameters. If it is not defined, the CFTPART default IDF is used.

If the provided IDF does not belong to either the SAUTH or RAUTH list, on the server side, the connection is rejected and the Transfer CFT client returns a DIAGI 413. For a put command on the client side, the IDF must be defined in the RAUTH on the server side. For a get command, the IDF must be defined in the SAUTH on the server side.

For each transfer, the transfer's IDF is in the SAUTH list for a client RECV, and a RAUTH list for a client SEND, otherwise the transfer is aborted with DIAGI 413.

When you are using a client other than Transfer CFT, the IDF that is used by the Transfer CFT server is determined by the remote path.

If the remote path is relative, the default IDF is used.

put LocalFile01.txt RemoteFile01.txt

If the remote path is absolute, the root directory IDF is used.

put LocalFile01.txt /flow01/RemoteFile01.txt

Above, flow01 corresponds to a CFTRECV object that is an authorized flow (RAUTH) for this partner.

Example

In the following example, the user <userlogin> has flow01 as the default template flow.

CFTPART id=app01,idf=flow01,nrpart=<userlogin>,nrpassw=<userpassword>,...

CFTTCP  id=app01,...

CFTSEND id=flow01,impl=yes,...

CFTRECV id=flow01,...

Client mode

Transfer CFT uses the parameters defined in the CFTPART provided by the SEND or RECV command (PROT, SAP, IDF, SSH) and the CFTSSH client parameters to establish the connection. The login parameters are defined in the NSPART and NSPASSW parameters of the CFTPART. They must correspond to the NRPART and NRPASSW defined on the server side.

Client mode authentication

  • NSPART=login name

Password authentication

  • NSPASSW=password: Transfer CFT sends this password to the remote SFTP server.
  • NSPASSW=@|#mypasswordfile (@ on Unix and # on Windows): Transfer CFT retrieves the password from the file and sends it to the remote SFTP server.

When DIRECT=CLIENT, you must set the CLIPRIVKEY in CFTSSH (for example, CLIPRIVKEY = '#conf/pki/private.priv'). For more information, please see Define CFTSSH (SFTP).

Password and key authentication

This method uses both the key and password authentication, as described above.

CFTSEND/CFTRECV

There are no specific requirements when Transfer CFT is acting in client mode, however in server mode note the following requirements:

  • When performing a get command, the Transfer CFT must use implicit mode (IMPL=YES) on the server side.
  • When performing a put command, between a third-party SFTP client and a Transfer CFT server, the Transfer CFT must use open mode (FNAME= &NFNAME) on the server side.
  • If you defined both a CFTSEND (IMPL=YES) and CFTRECV for a given IDF, the WORKINGDIRs must match.

The root directory for the SFTP connection is the WORKINGDIR defined in the CFTSEND (IMPL=YES) or CFTRECV corresponding to the IDF. If both CFTSEND and CFTRECV are defined for that IDF but with different WORKINGDIR, there is a DIAGI 435 error for the Transfer CFT client, and an SFTP failure with an appropriate error message for other SFTP clients.

If the WORKINGDIR is not defined, Transfer CFT uses the current directory (commonly the runtime directory).

When defining the WORKINGDIR, you can use the following symbolic variables:

  • &USERID: user login
  • &NRPART: same as &USERID
  • &PART: partner
  • &HOME: home directory on UNIX, or the user directory on Windows (C:\Users\<user>)

Example

In this example, user1 can perform a get or put command using the space (WORKINGDIR) defined for user1.

CFTPART ID=user1, IDF=flow01,NRPART="user1",...

 

CFTSEND IDF=flow01, IMPL=YES, workingdir=user1_space, fname=&nfname

 

CFTRECV IDF=flow01, workingdir=user1_space, fname=&nfname

  • If the CFTSEND (IMPL=YES) is not defined, the client cannot perform a download (get), and a permission denied error occurs.
  • If the CFTRECV is not defined, the client cannot perform an upload (put), and a permission denied error occurs.

CFTAUTH

This section describes the use of SAUTH and RAUTH in the context of an SFTP implementation. You can use these parameters to limit the visibility for a given user, when in server mode, to a logical representation of available flows.

In the following example, defining a CFTAUTH creates visibility for flow01 and flow02 for the user2 client.

CFTPART ID=user2, IDF=(flow02), NRPART="user2", SAUTH=AUTH2, RAUTH=AUTH2...

CFTAUTH ID=auth2, IDF=(flow01,flow02)

 

CFTSEND IDF=flow01, IMPL=YES, workingdir=user1_space, fname=&nfname

 

CFTSEND IDF=flow02, IMPL=YES, workingdir=user2_space, fname=&nfname

CFTRECV IDF=flow02, workingdir=user2_space, fname=&nfname

From the client side, the view would be as shown below (where the flow identifier displays, but not the physical folder name). Note that in this example, the workingdir is relative to the runtime directory.

Note If there is only one defined flow, this flow identifier does not display in the SFTP client.

SAUTH/RAUTH

In the CFTAUTH command, the IDF parameter designates a list of authorized IDFs for send/receive transfers with a defined partner. The SAUTH/RAUTH in the partner definition refers back to the CFTAUTH ID.

If you enter an * (asterisk), all model files (IDFs) can be used. If the provided IDF is not in one of the two lists, the connection is rejected and the Transfer CFT client returns a DIAGI 411.

See the examples in SFTP use case examples.

Related Links