4.2.4.6. SFTP Server Gateway In – Babelway

Using the SFTP Server In Gateway, incoming messages are received on a Babelway specific server and processed as soon as they arrive. The SFTP server gateway supports SFTP version 3 and password and/or public key user authentication mechanisms.

The specific settings are:

Server	Babelway sftp server is the hostname for the sftp server where the files will be fetched.
Username	Login or username to access your account on the Babelway SFTP server. This username must be unique as it is linked to a specific directory on the SFTP server.
Password	The password associated with the username. This can be left empty if you choose to only use the public key authentication mechanism.
Public Key	The public key associated with the username. This can be left empty if you choose to only use the password authentication mechanism. The supported formats are RSA public key (OpenSSH, Putty or DER format). More information about generating such a key can be found at the end of this page.
Directory	The directory on the ftp server on which you wil have to put your files so that they are processed by this gateway.

You can set both password and public key fields. Therefore, you will be able to connect to your account either by using a password or by using your private key associated with the uploaded public key.

After channel deployment, your SFTP server will be available to send messages. You can access this SFTP server using any SFTP (version 3) client software set up with the previous account parameters.

When a message is received by the SFTP server, it is directly processed. After processing, the file is removed from the server.

The public key is expected to be in an RSA format (OpenSSH, Putty or DER). If you don’t already have a public/private key, you can generate one using ssh-keygen from OpenSSH :

ssh-keygen.exe
Generating public/private rsa key pair.
Enter file in which to save the key (/.ssh/id_rsa): /tmp/identity
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /tmp/identity.
Your public key has been saved in /tmp/identity.pub.
The key fingerprint is:
f0:e4:2f:(...) user@computer

PUBLIC KEY AUTHENTICATION FOR SSH
The SSH protocol supports many authentication methods. Arguably one the most important of these is public key authentication for interactive and automated connections.

Public key authentication over simple passwords is used for security. It provides cryptographic strength that even extremely long passwords can not offer. With SSH, public key authentication improves security considerably as it frees the users from remembering complicated passwords (or worse yet, writing them down).

In addition to security public key authentication also offers usability benefits - it allows users to implement single sign-on across the SSH servers they connect to. Public key authentication also allows automated, passwordless login that is a key enabler for the countless secure automation processes that execute within enterprise networks globally.

Public key cryptography revolves around a couple of key concepts. The sections below explain these briefly.

ASYMMETRIC CRYPTOGRAPHY - ALGORITHMS
As with any encryption scheme, public key authentication is based on an algorithm. There are several well-researched, secure, and trustworthy algorithms out there - the most common being the likes of RSA and DSA. Unlike the commonly known (symmetric or secret-key) encryption algorithms the public key encryption algorithms work with two separate keys. These two keys form a pair that is specific to each user.

KEY PAIR - PUBLIC AND PRIVATE
In the SSH public key authentication use case, it is rather typical that the users create (i.e. provision) the key pair for themselves. SSH implementations include easily usable utilities for this (for more information see ssh-keygen and ssh-copy-id).

Each SSH key pair includes two keys:

A public key that is copied to the SSH server(s). Anyone with a copy of the public key can encrypt data which can then only be read by the person who holds the corresponding private key. Once an SSH server receives a public key from a user and considers the key trustworthy, the server marks the key as authorized in its authorized_keys file. Such keys are called authorized keys.

A private key that remains (only) with the user. The possession of this key is proof of the user's identity. Only a user in possession of a private key that corresponds to the public key at the server will be able to authenticate successfully. The private keys need to be stored and handled carefully, and no copies of the private key should be distributed. The private keys used for user authentication are called identity keys.

SETTING UP PUBLIC KEY AUTHENTICATION FOR SSH
The following simple steps are required to set up public key authentication (for SSH):

Key pair is created (typically by the user). This is typically done with ssh-keygen.
Private key stays with the user (and only there), while the public key is sent to the server. Typically with the ssh-copy-id utility.
Server stores the public key (and marks it as authorized).
Server will now allow access to anyone who can prove they have the corresponding private key.

Reference: https://www.ssh.com/ssh/public-key-authentication

Note:

If there is a file name provided in the "Message In" or "Message Out" which contain ~ tilde character, All browser based on Chromium will replace the ~ tilde character by the _ underscore character when you try to download the file from the Babelway interface, For more details you can check this link https://bugs.chromium.org/p/chromium/issues/detail?id=479419
The maximum file size accepted by this gateway is 100/250 MB.