QM:SSHtransfer Queue Manager

SSHTransfer on the IBMi

Introduction

SSHTransfer is an upgraded version of the currently used Omxfer transfer and queuing (distribution) software. Within TD/OMS, Omxfer has the responsibility to transfer distribution files in an application environment to one or more, IBMi or non IBMi, servers.

When do you need to use SSHTransfer.

SSHTransfer has its merits in security. The software is based on the ubiquitous OpenSSH software. OpenSSH supplies all the mechanisms required to ensure that data transfers are secure (encrypted) to the highest level by way of SFTP (Secure File Transfer Protocol) or SCP (Secure Copy Protocol). So you would choose SSHTransfer over Omxfer in those situation where your distribution transfers are taking place over a public network (or going through a public network) or there are strict corporate rules to adhere to with respect to remote file transfers, for example only an SFTP or SCP based file transfer is allowed.

What also has changed is the 2gb size limit of distribution files. Omxfer distribution imposed this limit due to the fact that it used 32bit file I/O apis in its core, these file I/O apis had a 2gb file size limit. SSHTransfer runs the latest version OpenSSH on a 64bit Java VM this means that the file size of a distribution file is limited only by the amount of space available on the IFS file system.

Meant as drop-in replacement for Omxfer, SSHTransfer replaces Omxfer transfer and queuing software. As a rule both distribution systems cannot be active at the same time. Both systems (indirectly) use a registry entry to determine the location of the base working ‘omsqueue’ directory. This directory is configured per TD/OMS environment through the registry setting OMQDISTRBASEDIR. This registry defines the fully qualified location of the ‘omsqueue’ directory and must be different for every Omxfer or SSHTransfer instance setup on a single machine. It is from the ‘omsqueue’ directory where send and receive queue processing takes place and thus cannot be shared.

Installation and Configuration

As already indicated, SSHTransfer is a separate system within TD/OMS. It needs to be installed on every machine participating in a distribution. Installation is done by running the following command on the IBMi (assuming the required OMS lib is in the current library list):

inzomssrv *SSHTRANSFER (and F4)

The base directory network server is the base location for the SSHTransfer software. By default (*DEFAULT) the software is installed in ‘/QOpenSys/TD/SSHTransfer’. Using the default location is the logical choice if you do not plan to have multiple SSHTransfer instances (to support multiple distribution setups, for example 1 for testing and 1 for production). Even so if you later decide to add a distribution environment then just make sure they do not end up using the same base directory. Regarding a multi instance setup, SSHTransfer instances are partitioned by their install location and TCP/IP port through which the instances are accessed.

Note that when you provide an overriding ‘Base directory Network Server’ then the installation command will create the directory ‘SSHTransfer’ in the base directory as the qualified installation directory.

Configuring for multiple SSHTransfer instances

When installing multiple instances of SSHTransfer it is important to define a unique installation location for every instance when applying the inzomssrv *SSHTransfer command. Also per instance the TD/OMS registry setting OMQDISTRBASEDIR needs to point to the omsqueue directory of the created SSHTransfer instance. By default each instance will have its own 'omsqueue' directory located in the root of the instance installation directory. Finally, a unique TCP/IP port must be assigned to the instance to differentiate the multiple instances running on a single server. The port is set in the sshd.properties file as the property sshdserver.global.port, if not set the port number defaults to 45022.

A sending SSHTransfer instance is expected to have the same port configured as the receiving SSHTransfer instance, the port binds SSHTransfer environments making them closed distribution loops.

Most important in the SSHTransfer installation are the directories ‘.data\’ and ‘omsqueue\’, created in the base installation directory. These directories should not be removed as they contain important work and configuration files necessary for the correct functioning of the SSHTransfer application.

The following configuration files are involved:

sshd.properties, located in the directory .data/config, this configuration file is the primary SSHTransfer configuration file, containing all settings required for a correct initialization and startup of the core ssh programs. This file will be automatically created on first time startup (or when the file does not exist).

cdxfer.cfg, located in the directory omsqueue/config, this configuration file is used by the Omxfer client software. This file will be automatically created on first time startup (or when the file does not exist).

omxfer.cfg, also located in the directory omsqueue/config, this configuration is also used by the Omxfer client software. This file will be automatically created on first time startup (or when the file does not exist).

The cdxfer.cfg and omxfer.cfg configuration files are required for compatibility with the Omxfer queuing client. This client is still used for creating the distribution queue files on the IBMi and is responsible for placing these qif and data files in the queue send directory.

Configuration files further explained.

cdxfer.cfg

The cdxfer.cfg provides the location of the client log directory and omsqueue/config directory to be used by the Omxfer queuing client. For example:

log_directory /QOpenSys/TD/OMSDEMO/SSHTransfer/omsqueue/log omxfercfg_path /QOpenSys/TD/OMSDEMO/SSHTransfer/omsqueue/config log_info_messages yes log_stat_messages yes #'''debug'''

The properties log_info_messages and log_stat_messages determines the detail of Omxfer client logging. The log messages will be logged in the file cdxfer.log in the location set by the property log_directory.

The property omxfercfg_path tells the client where to find the omxfer.cfg file which is important with regards to the base queue directory to be used (by the Omxfer client) and the user that has access to this directory, see below.

omxfer.cfg

The omxfer.cfg provides the location of the omsqueue directory and the name of the user that has access to the omsqueue directory (and sub directories), specifically the send directory. For example:

queue_owner OMS queue_group *NONE log_directory /QOpenSys/TD/OMSDEMO/SSHTransfer/omsqueue/log queue_base_directory /QOpenSys/TD/OMSDEMO/SSHTransfer/omsqueue

Note that the queue_group is not used but for legacy reasons needs to be set with the value *NONE.

sshd.properties

The sshd.properties contains all settings required to get the SSHTransfer instance up and running.

By default the sshd.properties file contains the following (example) settings:

# listen on localhost and 192.168.1.1
# sshdserver.global.host=127.0.0.1,192.168.1.1
# listen on (default) TCP port 45022
sshdserver.global.port=45022
sshdserver.global.rootdirectory.os400=/
sshdserver.global.debugenabled=false
# required queuing oms user
sshdserver.user.oms.enableflag=true
sshdserver.user.oms.userpassword=...
sshdserver.user.oms.writepermission=true
sshdserver.global.openregistration=true
# enable shell, required for queuing commands
sshdserver.global.shell=true
# ties os400 ccsid to java charset for EBCDIC <-> ASCII conversion
queue.qexit.jobccsid=037
# text conversion strategy for qexit script output
queue.qexit.outputconvname=rawconv
# port legacy omxfer config settings
# exit programs script names
queue.qexit.file=qexitfile.qsh
queue.qexit.job=qexitjob.qsh
queue.qexit.msg=qexitmsg.qsh

On first time startup extra settings will be added:

queue.base.directory=/QOpenSys/TD/OMSDEMO/SSHTransfer
queue.omsqueue.directory=/QOpenSys/TD/OMSDEMO/SSHTransfer/omsqueue

The above directory locations are determined by the install location of the SSHTransfer instance.

By default SSHTransfer will on first startup attempt to set basic queuing properties using the settings of the currently installed Omxfer system. From this system the queuing settings will extracted and inserted into the SSHTransfer configuration file. If the required configuration files cannot be located then default configuration settings will be applied.

queue.legacy.base.directory=/QOpenSys/omsqueue
queue.legacy.config.directory=/QOpenSys/omsqueue/config
queue.delay.procloop=5000
queue.retry.time=600
queue.ttl.time=7200
queue.recover.qif=true

The above setting indicates that porting and or setting up legacy queuing settings has been completed.

Important post installation settings

By default the SSHTransfer server will listen on all ethernet interfaces for incoming connections. When you need to bind the SSHTransfer server to a specific ethernet interface, then set the property sshdserver.global.host=?ip-address?. Setting this option will ensure that the server will only listen on the configured IP address, for example sshdserver.global.host=172.17.2.2.

When the default TD/OMS library is not OMS or when working with multiple SSHTransfer instances on a single machine then it is important to define the TD/OMS library of which the SSHTransfer instance will be a part of, this is done by setting the property: queue.qexit.jobomslib, for example:

queue.qexit.jobomslib=OMSDEMO

By default the queue.qexit.jobomslib is ‘OMS’.

Working with SSHTransfer

Logging

The SSHTransfer server has 2 log files, the sshd.log and the queuing.log. Both logs are located in the SSHTransfer installation directory under ‘./.data/logs’ directory. The sshd.log will contain the bulk of the SSHTransfer log output.The queuing.log will contain logging pertaining to output created during the processing of an exit program (qexitfile, qexitjob, qexitzip or qexitmsg). There is also a 3rd log, cdxfer.log, used by the Omxfer transfer client. Depending on configuration setup this log is expected to be located, either in ‘./.data/logs’ or './omsqueue/log directory'.

A bit on security

SSH (Secure Shell) is designed to provide secure encrypted communication between two untrusted hosts over an insecure network. The SSH protocol encrypts all traffic, including login credentials and any data transmitted during the session, using strong encryption algorithms such as AES (Advanced Encryption Standard).

By encrypting user data, SSH ensures that the data cannot be read by unauthorized parties who may be monitoring the network. This is particularly important when sensitive information is being transmitted, such as passwords, financial data, or other confidential information.

In addition to encryption, SSH also provides other security features such as host key verification and data integrity checks to detect any tampering or modification of the data during transmission.

SSHTransfer server identity check

In addition to SSH’s host key verification, SSHTransfer implements a Server to server identity mechanism based on a SSHTransfer server’s queue-id. A sending server identifies itself with its queue-id (from here on known as the key-pass) and with a signed attestation (signed with the sending server's private key). The receiving server attempts to processes the key-pass (has it already got a key-pass and public key from the sending server? is it the same?, if all is ok then the signed attestation is checked. After successfully processing the key-pass it will accept the connection and continue with queue processing.

The queue name ‘oms’ is used by all installed SSHTransfer installations, they all have ‘oms’ as the base queue name (theoretically SSHTransfer can be used to support multiple queues using different queue names). This means that the user name ‘oms’ is reserved for queuing and cannot/should not be disabled in a configuration.

As already explained, SSHTransfer utilises a public key exchange scheme (with a 3072 RSA bit key) using a key-pass and a server’s public key. If the receiving server is configured properly it will accept the profile as the public key and key-pass as the identity for the queue host that sent the profile. The key-pass and public key will be stored in the receiving server’s configuration as a host with a key-pass. Once the identity exchange has taken place future connection requests will use the created host and key related entries and use this to validate incoming connections.

An important Implication of this setup is that, if the public key of a sending server changes, then a receiving server (which still has the old public key) will reject the connection request. In such a situation the sending server’s key-host entries need to be deleted so that the receiving server can accept a fresh version of the sending server’s identity (see the shell command delqueuehost).

In addition to the above security measurements SSHTransfer also employs an Open/Close registration scheme. This is a simple scheme to gather a collection of whitelist servers and then at one point to close registration. When registration is closed then this will block any unknown server from being registered and rejecting the connection request (see the shell command enableopenreg and disableopenreg). By default a server is configured for open registration.

Using SSHTransfer command shell

Major configuration settings can be changed using the SSHTransfer command shell. The shell can be accessed with an ssh client using the host name and server port of the SSHTransfer server and valid (IBMi) credentials. The shell has a fixed set of commands that can be run and are all related to SSHTransfer configuration settings, there are no shell commands allowing access to OS or external programs.

Note that when you change a server’s configuration property through a shell command, you do not have to restart the server for the property to become active, opposed to manually updating a configuration property which always requires a server restart for the property setting to become active.

****************************************************
*         SSHTransfer Shell.                              *
****************************************************
sshtransfer> help
List of commands (?command? -help for more info on a command):
…
dspcfg
enabledebug
enableopenreg
enablepkverify
ping
qdspenv
qsndmsg
…
sshtransfer>

For a complete list of available commands see “SSHTransfer shell commands”. Each command has a simple help explanation by entering the command and the parameter -help.

For problem determination, commands of interest are:

enabledebug/enabletrace, enable debug/trace logging (sshd.log)

qdspenv, show the basic queue settings

dspcfg, show the complete sshd.properties

ping, ping a remote SSHTransfer instance

qsndmsg, send a message to a remote

Particularly useful for checking the availability of a remote SSHTransfer system are the commands ping and qsndmsg. Ping will check the connectability/reachability of a server and qsndmsg will try to send a message to the remote system via the queuing mechanism, similar to the TD/OMS sndnetmoms command on the IBMi.

SSHD shell commands

List of available commands followed by their shorthand notation:

help : help

adduser : au

chguserpswd : cup

delqueuehost : delqh

disabledebug : dd

disablelocalhostlogin : dlhl

disableopenreg : dor

disablepkverify : dpkv

disablequefilestaging : dqfs

disablequeuehost : disqh

disablescp : dscp

disablesftp : dsftp

disabletrace : dt

disableuser : du

dspqenv : dspqe

dspcfg : dspcfg

dspmailcfg : dspmcfg

dspqueuehosts : dspqh

dspversioninfo : version

enabledebug : ed

enablelocalhostlogin : elhl

enableopenreg : eor

enablepkverify : epkv

enablequefilestaging : eqfs

enablequeuehost : eqh

enablescp : escp

enablesftp : esftp

enabletrace : et

enableuser : eu

ping : ping

qsndmsg : qsm

sendtestmail : stm

setloginserver : sls

setloginserverport : slsp

SSHTransfer shell commands explained

How to login to a shell

SSHTransfer shell commands can be run on a SSHTransfer server by making a connection with the server using a ssh client (such as putty for Windows) or on a Unix system by using the ssh command. When using putty you use the connection type SSH on port 45022 (default for SSHTransfer) and provide the required host and user information. On Unix you can start a shell terminal using the ssh command, for example ‘ssh -p 45022 joeybe@myhost’, this will start an ssh session that will connect to the SSHTransfer server on host ‘myhost’ using port 45022 and user name ‘joeybe’. On the IBMi you can run ssh by first starting a qshell with the command qsh.

Note that for security reasons the shell commands available is limited to SSHTransfer related commands only, you cannot run any operating system (shell) commands or programs.

With regards to the user name to be used for a login, for an SSHTransfer server running on the IBMi platform the user must be a valid IBMi user and for other platforms the user must be registered in the SSHTransfer server configuration file. For non IBMi platforms there is although the possibility to delegate a login request to an SSHTransfer server running on the IBMi. Using login delegation can alleviate the process of managing users who need shell access for multiple SSHTransfer servers. To enable the delegated login option either use the shell commands setloginserver and setloginserverport or set the properties for the login server in the configuration file using the properties:

sshdserver.global.login.server.name = my-ibmi-sshtransfer-server

If the server port is not the default 45022 then you can override the port with the property ‘sshdserver.global.login.server.port’, for example:

sshdserver.global.login.server.port = 45122

Almost all commands below translate to a property setting in the sshd.properties file. The property setting involved will be mentioned in the explanation of the command.

Note that access to a server’s shell terminal can be disabled by manually setting the following property in the sshd.properties file:

sshdserver.global.shell = false

SSHTransfer commands

help

The help command will show a list of available commands with their shorthand notation. To see the help of a command you enter the command name followed by the parameter -help or help, for example adduser help or au help

adduser

For non IBMi configurations this command allows you to add a user that can access the shell through an ssh connection.

Syntax: adduser -u username -p password

The password will be stored in an encrypted format.

Note that on the IBMi a login will request will be delegated to the IBMi login mechanism.

chguserpswd

This command allows you to update the password of an existing configured user. This command is not available on an IBMi SSHTransfer server.

Syntax: chguserpswd -u username -p password

The password will be stored in an encrypted format.

dspcfg

This command displays a complete list of the properties set in the configuration file (sshd.properties), the list also includes the properties that have a default value and are not set in the configuration file.

Syntax: dspcfg

dspmailcfg

This command displays a complete list of configuration properties of the email and mail server configuration. With mail setup, SSHTransfer related messages can be sent to a user.

Syntax: dspmailcfg (dspmcfg)

dspqenv

This command will display the configuration properties involved with the queue processing.

Syntax: dspqenv (dspqe)

dspqueuehosts

This command displays a list of the registered queue hosts. The listed names can for example be used to delete a queue host entry with the command: delqueuehost (delqh).

Syntax: dspqueuehosts (dspqh)

dspversioninfo

This command displays SSHTransfer version and build information.

Syntax: dspversioninfo (version)

enablelocalhostlogin, disablelocalhostlogin

This command will allow (enablelocalhostlogin) or prohibit (disablelocalhostlogin) a user to login the server’s shell without providing credentials when the login takes place on the machine the server is installed. If enabled then auto login on the server is allowed when the connection address is an IP4/6 local host type address (i.e localhost, 127.0.0.1, 1::1 ...). This option is primarily used for server setup and should be set to false as soon as first time setup is completed. Note that this setting is not applicable to the IBMi, in this case the option will always be disabled. By default the option is disabled.

To allow local host login without credentials:

Syntax enablelocalhostlogin (elhl)

To disallow local host login without credentials:

Syntax disablelocalhostlogin (dlhl)

enablequeuehost, disablequeuehost

This command will allow (enablequeuehost/eqh) or prohibit (disablequeuehost/dqh) a remote SSHTransfer server from connecting to the running server. This command can be used to temporarily reject the queuing requests of a remote server. On first contact and registration a requesting server is automatically accepted and gets the value true for the below configuration property:

sshdserver.queue.oms.?DNS name | IP address?.enableflag=true | false

To allow a remote SSHTransfer server to connect:

Syntax: enablequeuehost host-name | enablequeuehost -q oms -h host-name

To block a remote SSHTransfer server from connecting:

Syntax: disablequeuehost host-name | disablequeuehost -q oms -h host-name

By default all SSHTransfer servers have the default queue name ‘oms’. The queue name can only be different in a multi queue setup. If you need to delete a queue host for a specific queue then it is required to provide the queue name and host name.

enabledebug, disabledebug

This command will enable debug logging output in the sshd.log. It is not advised to keep debug logging enabled in a production environment due to the amount of log output that can be produced. Use only for short debug sessions. When you are finished debugging, disable by running the command disabledebug.

Syntax: enabledebug (ed) / disabledebug (dd)

Property setting: : sshdserver.global.debugenabled=true | false (by default false)

enabledetrace, disabletrace

A step up from debug logging, trace logging will enable all levels of investigative logging. It is not advised to keep trace logging enabled in a production environment due to the amount of log output that can be produced. Use only for short debug sessions. When you are finished trace debugging, disable by running the command disabletrace.

Syntax: enabletrace (et) / disabletrace (dt)

Property setting: sshdserver.global.traceenabled=true | false (by default false)

enableopenreg, disableopenreg

SSHTransfer has a mechanism that supports an open registration scheme. This means that as long as a server is configured for open registration, new and unregistered remote SSHTransfer servers can connect to, and be registered, on a running server. As soon as the open registration option is disabled, a connection request of a new and unregistered server will no longer be accepted. Once a server has been registered it will be allowed to connect regardless of the state of the open registration option. The main purpose of open/closed registration is to allow only well-known servers have access to a running server.

Property setting: sshdserver.global.openregistration=true | false

Command allow a remote SSHTransfer server to connect: enableopenreg (eor)

Command to block a connect request of an unregistered SSHTransfer server: disableopenreg (dor)

emailtst

This command can be used to test the functioning of the configured mail properties by sending an email to the configured mail server and provided email user. Make sure all the required mail server settings have been set before running this command.

Syntax: emailtst

ping

With this command you can ping a remote SSHTransfer server, for example ping SYSTEMX. If connection was successful then the response will be:

host SYSTEMX is reachable on port 45022

otherwise a message will be displayed explaining the cause of the connection failure.

Syntax: ping ?host-name?

qsndmsg

Use this command to test the local and remote queuing mechanism. Essentially with this command you can send a message to remote SSHTransfer server. The message will be put on the local queue and sent to the remote server. When sending to a server on an IBMi system then this command works similar to the TD/OMS command sndnetmoms. On the target system you can check the result of the command by looking at the logging (queuing.log) created by the qexitmsg command.

Syntax: qsndmsg -r ?receiver-name? -h ?host-name? -s ?sender-name? -m ?"quoted-message"? -u ?target-user-name? -p ?target-user-password?

For example: qsndmsg -r OMSUSER -h HOSTX -s USERX -m "A message"

If no host user or password set using the -u and -p options, then the queue host key will be used.

setccsid

OS400 only command. This command will set the CCSID to be used when converting the queuing meta files from ASCII to EBCDIC so that it can be read by the IBMi native programs used in the qexit batch program. The IBMi native programs have the responsibility of post processing a queue file. By default the CCSID 037 is used.

Syntax: setccsid ?ccsid-nr?

Property setting: queue.qexit.jobccsid=?ccsid-nr?

setloginserver, setloginserverport

With the command setloginserver (and setloginserverport) the login of a user can be delegated to an IBMi SSHTransfer server. Using this option you do not need to add users to a SSHTransfer serverm the user's credential will be validated on the configured IBMi server. To enable the delegated login option either use the shell commands setloginserver and setloginserverport or set the properties for the login server in the configuration file using the properties:

sshdserver.global.login.server.name=?ibmi-sshtransfer-server?

If the server port is not the default 45022 then you can override the port with the property ‘sshdserver.global.login.server.port’, for example:

sshdserver.global.login.server.port=45122

setomslib

OS400 only command. This command will set the library to be used when post processing a queue file though a qexit batch program. The library name will be passed on to the qexit batch file responsible for post processing a queue file and be added to the library list of the running post process. The default library name used is ‘OMS’. If there are multiple SSHTransfer servers on a machine or the TD/OMS library name is not ‘OMS’ then you need to provide the correct library name to be used.

Syntax: setomslib ?oms-lib-name?

Property setting: queue.qexit.jobomslib=?oms-lib-name?

Advanced commands

delqueuehost

This command will remove the connection registration of a remote SSHTransfer (queuing) server. Doing this will force the SSHTransfer server, for which the connection registration was removed, to re-connect. Net result is that the running server will get a fresh set of registration connection details from the requesting server (key-pass, public key …). Note that if server registration option is set to closed then the deleted queue host will not be able to re-connect (see enableopenreg, disableopenreg). Deleting a queue host will most likely be necessary when a known queue server renews its public key (possibly due to a full reinstall).

Syntax: delquehost ?queue-host-name??

enablekeypassverify, disablekeypassverify

The command enablekeypassverify will enable the SSHTransfer server-to-server key-pass value validation. Key-pass signature checking will take place when a server attempts to connect to the running server. The key-pass signature checking mechanism is used by the SSHTransfer to complete the id validation of a connecting server. This is done by using the public key of the connecting server to validate a received signed key-pass value. Note that for signature checking the public key of a server is made available when a server connects to the running server for the very first time (first time registration).

The result of the command disablekeypassverify is that in the server-to-server verification process the signature validation will be skipped as part the standard key-pass identity check. Skipping the signature validation will speed up server connections significantly but should only be done if the servers are, for example, running in a private network, or security at this level is not required.

Syntax: enablekeypassverify (ekpv) | disablekeypassverify (dkpv)

Property setting: sshdserver.global.queueverifykeypass=true | false (default is false)

enablequefilestaging, disablequefilestaging

This command will enable the functionality responsible for optimizing SSHTransfer queue file data storage. The purpose of ‘queue file staging’ is to optimize the file space used by queue data files. It can occur that a queue data file is used in many host distributions, queue file staging optimizes this scenario by storing the data file once and providing a link to be used in further processing of the data file. Not all operating systems can support the logic used for file staging so it might be necessary to disable it for a specific OS.

Syntax: enablequefilestaging (ekfs) | disablequefilestaging (dqfs)

Property setting: queue.file.stagingenabled=true | false (default is true)

enablescp, disablescp

These commands enable or disable the SSH SCP sub system that is available as part of the SSHTransfer server. Disabling SCP has no effect on the queuing functionality of the server. The scp functionality can for example be used by the non IBMi distributions where queue file post processing can be configured to directly copy a file from the running server to a remote scp server. Which in this case is also the SSHTransfer server for which scp was enabled.

Syntax: enablescp (escp) | disablescp (dscp)

Property setting: sshdserver.global.scpenabled=true | false (default is false)

enablesftp, disablesftp

These commands enable or disable the SSHTransfer SFTP sub system. Disabling SFTP has no effect on the queuing functionality the server. By default the SFTP sub system is disabled.

Syntax: enablesftp (esftp) | disablesftp (dsftp)

Property setting: sshdserver.global.sftpenabled=true | false (default is false)

setoutputconvname

OS400 only command. With this command you can set the logic to be used to convert the log output of the qexit programs. For readability reasons the output of a native IBMi exit program needs to be translated from EBCDIC to ASCII. This is required as the SSHTransfer logs are by nature ASCII files. Possible values for this command is a valid IBMi character-set name, for example Cp1047 or the values ‘raw’ or ‘rawconv’. The value raw will not do any character conversion, the value rawconv, which is the default, will use an internal EBCDIC to ASCII conversion table. If log output is garbled (partially or not unreadable at all) then the originating CCSID of the output needs to determined and provide as the character-set name for ASCII conversion.

Syntax: setoutputconvname raw | rawconv | ?character-set?

Property setting: queue.qexit.outputconvname=raw | rawconv | character-set (default is rawconv)

Mail configuration

When a transfer fails in any of the process steps a mail can be sent to a mail box. To enable sending emails, the following (minimal) properties must be set:

# single send-from address
sshdserver.mail.from.address=

# 1 or more space separated send-to addresses
sshdserver.mail.sendto.addresses=

# mail server name
sshdserver.mail.server.name=

# mail server port
sshdserver.mail.server.port=

The following settings can be applied to fine tune connection parameters:

# provide the mail server login user name
sshdserver.mail.server.user=

# provide the mail server login user name password, password will be stored encrypted
sshdserver.mail.server.password=

# set to true if oauth2 is to be used, the password is then this the mail server token
sshdserver.mail.enable.oauth2=false

# set to 'ssl' or 'tls' as the communication encryption protocol, leave empty for clear text
# (major email providers will be at least on TLS version 1.2)
sshdserver.mail.encryption.type=tls

# set to true if TLS is set and communication setup must use the default or provided TLS protocol
sshdserver.mail.require.tls=true

# optionally provide 1 or more space separated SSL/TLS protocol(s) (e.g. TLSv1.2)
sshdserver.mail.require.protocols=TLSv1.2

# to override a rejected host due to security issues (expired or unsupported self signed ssl certificate),
# provide 1 or more space separated mail server host names (e.g. smtp.office365.com)
sshdserver.mail.trusted.hosts=

# output mail debug to log, true or false
sshdserver.mail.debug=false

Below is an example of a minimal mail configuration:

sshdserver.mail.server.name=company-name.com.mail.protection.outlook.com
sshdserver.mail.server.port=25
# tls will default to TLSv1.2
sshdserver.mail.require.tls=true
sshdserver.mail.from.address=sshtransfer@company-name.com
sshdserver.mail.sendto.addresses=sshtransfer-admin@company-name.com