SRM may fail to transfer Scheduled Reports to Remote Locations using SSH. The relevant taskRun-0-0.log file shows the following error messages:
220201 10:29:13 : SEVERE: Error while sending file: SolutionPacks identified New_2022-02-01_10h29.pdf
220201 10:29:13 : org.apache.commons.vfs.FileSystemException: Could not resolve file "<given URL>".
(…)
220201 10:29:13 : Caused by: java.io.IOException: Key exchange was not finished, connection is closed.
220201 10:29:13 : at com.trilead.ssh2.transport.KexManager.getOrWaitForConnectionInfo(KexManager.java:92)
220201 10:29:13 : at com.trilead.ssh2.transport.TransportManager.getConnectionInfo(TransportManager.java:230)
220201 10:29:13 : at com.trilead.ssh2.Connection.connect(Connection.java:743)
220201 10:29:13 : ... 32 more
220201 10:29:13 : Caused by: java.io.IOException: Cannot negotiate, proposals do not match.
220201 10:29:13 : at com.trilead.ssh2.transport.KexManager.handleMessage(KexManager.java:413)
220201 10:29:13 : at com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:754)
220201 10:29:13 : at com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:469)
220201 10:29:13 : at java.lang.Thread.run(Thread.java:748)
The/var/log/messages log for the remote SSH server host shows corresponding messages indicating an inability to negotiate Key Exchange
(kex) methods with the client (such as SRM Report Scheduler):
The SRM SSH client as implemented uses a limited number of MAC and Key Exchange (kex) algorithms which are not compatible with the algorithms that are enabled by
default on recent SSH server implementations.
SRM Engineering is evaluating the requirements to address this issue in an upcoming product release. A workaround is available as described in this article.
Apply the workaround only when the task log contains the above mentioned errors, i.e. "Key exchange was not finished, connection is closed" and "Cannot negotiate, proposals do not match". Do not apply the workaround in any other circumstances.
Apply the workaround on the receiving remote host only. Do not apply the workaround on the sending component, i.e. the SRM Frontend host. The only exception is where the SRM Frontend host itself is specified as the "remote" host. Only in this special case should the workaround be applied on the Frontend host.
The workaround is to enable older Key Exchange (kex) and MAC methods on the remote host's SSH server in order to accommodate the limited options that the SRM
client offers.
The following instructions apply to an OpenSSH 7.x server on Linux:
Edit the sshd config file /etc/ssh/sshd_config:
1. Ensure PasswordAuthentication is set to yes.
2. Add hmac-sha1-96 to the MACS section as follows:
# Lists the available MACs algorithms
# Edited to allow hmac-sha1-96 for use by SRM client
3. Add diffie-hellman-group-exchange-sha1 to the kexalgorithms section as follows:
#Edited to allow diffie-hellman-group-exchange-sha1 for use by SRM client
kexalgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
4. Save the configuration file and restart the SSH daemon:
systemctl restart sshd
Consult the relevant documentation for different SSH servers and operating systems for details on how to enable the relevant MAC and Key Exchange (kex) algorithms (hmac-sha1-96 and diffi e-hellman-group-exchange-sha1) in order to allow connection from the SRM SSH client.