Oracle Transactional Business Intelligence

Home› Oracle Analytics› Oracle Analytics Forums› More Solutions› Oracle Transactional Business Intelligence

Categories

Welcome to the Oracle Analytics Community: Please complete your User Profile and upload your Profile Picture

BI SFTP connection no longer working due to Key Exchange Algorithm Deprecation

Received Response
67
Views
9
Comments
JEngalan
JEngalan Rank 2 - Community Beginner
in Oracle Transactional Business Intelligence

One of our SFTP delivery configuration in Oracle BI Publisher has stopped working due to deprecation of diffie-hellman-group14-sha1 SSH Kexs on the target server.

Error message: Could not establish connection. oracle.xdo.delivery.ssh2.SshException: Timeout waiting for response from server

As per Oracle docs, https://support.oracle.com/epmos/faces/DocumentDisplay?parent=SrDetailText&sourceId=3-38028203491&id=2462380.1

the following later versions of Key Exchange methods are already supported:

  • diffie-hellman-group1-sha1
  • diffie-hellman-group14-sha1
  • diffie-hellman-group-exchange-sha1
  • diffie-hellman-group-exchange-sha256
  • diffie-hellman-group14-sha256
  • diffie-hellman-group16-sha512
  • diffie-hellman-group18-sha512

However, when we try to establish connection to the SFTP server, the logs only detect the deprecated Kex:

Kex=diffie-hellman-group14-sha1 Ciphers=aes128-ctr,aes128-ctr MACs=hmac-sha1,hmac-sha1

How can we configure this in Oracle BI to ensure we use the newer version of key exchange method during connection?

Tagged:

Answers

  • Hassan El Bouihi-Oracle
    Hassan El Bouihi-Oracle Rank 5 - Community Champion

    Hello JEngalan,

    Please schedule the report with diagnostics turned on and upload the diagnostics log for review:

    Review Doc ID 2126699.1 for more details on how to run this process

    Thank you

    Hassan

  • JEngalan
    JEngalan Rank 2 - Community Beginner
    edited October 2024

    Hi @Hassan El Bouihi-Oracle

    Thanks for the response. This is what I found from the logs regarding the Kex Algo exchange:

    [101524_214637947][oracle.xdo.delivery.ssh2.transport.MessageProcessor][STATEMENT] Client Kex Algos diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512


    [101524_214637947][oracle.xdo.delivery.ssh2.transport.MessageProcessor][STATEMENT] Server Kex Algos curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1


    [101524_214637947][oracle.xdo.delivery.ssh2.transport.MessageProcessor][STATEMENT] Negotiated Kex is diffie-hellman-group14-sha1

    How do we request to have the Negotiated Kex to a higher policy?

  • Hassan El Bouihi-Oracle
    Hassan El Bouihi-Oracle Rank 5 - Community Champion

    Hello JEngalan

    According to the snippet you shared, the connection was successful and the negotiated Kex was established as diffie-hellman-group14-sha1.

    Could you share the log where the negotiation failed.
    Oracle's existing Algos are shared in the documentation and only those will be used in the negotiation.

    Thank you
    Hassan

  • JEngalan
    JEngalan Rank 2 - Community Beginner

    @Hassan El Bouihi-Oracle Unfortunately, we are unable to retrieve the error logs since the diagnostics were not enabled when the report failed. Additionally, the target server has rolled back the change on their end and reinstated diffie-hellman-group14-sha1 in their KEX list, as shown in the logs I've provided. As a result, we cannot replicate the error at this time.

    I assume the KEX handshake looks similar to the following when the target server deprecated group14-sha1 on their end.

    [101524_214637947][oracle.xdo.delivery.ssh2.transport.MessageProcessor][STATEMENT] Client Kex Algos diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512


    [101524_214637947][oracle.xdo.delivery.ssh2.transport.MessageProcessor][STATEMENT] Server Kex Algos curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1

    If that's the case, would the negotiated KEX be diffie-hellman-group-exchange-sha256? And since it's both supported, should the connection went through?

    Do you have any thoughts or assumptions about what might have gone wrong?

  • Hassan El Bouihi-Oracle
    Hassan El Bouihi-Oracle Rank 5 - Community Champion

    Hello JEngalan,

    If the server removes diffie-hellman-group14-sha1, we will still be good as both client and server have these in common and one of them will be used:

    diffie-hellman-group-exchange-sha256
    diffie-hellman-group16-sha512
    diffie-hellman-group18-sha512
    diffie-hellman-group14-sha256

    If there are any issues after they remove the diffie-hellman-group14-sha1, please raise an SR and share the diagnostics log for further review.

    Thank you
    Hassan

  • JEngalan
    JEngalan Rank 2 - Community Beginner

    Hi @Hassan El Bouihi-Oracle thanks for the information.

    We have now tried establishing connection to the test server with the updated security policy and was able to recreate the error with FTP connection failing. See attached screenshot.

    Error captured on the target server is: 'no matching MAC found'

    As per their documentation: https://docs.aws.amazon.com/transfer/latest/userguide/security-policies.html#security-policy-transfer-2024-01

    The following MAC protocols are only supported by the server:
    hmac-sha2-256-etm@openssh.com
    hmac-sha2-512-etm@openssh.com

    From the diagnostic logs on previous successful report run, we only have client MAC protocols:
    hmac-sha1
    hmac-sha2-256
    hmac-sha2-512

    [101524_214637947][oracle.xdo.delivery.ssh2.transport.MessageProcessor][STATEMENT] Client MAC S->C Algos hmac-sha1,hmac-sha2-256,hmac-sha2-512

    Unfortunately, I'm unable to get the report diagnostic logs as the error is preventing me to save the SFTP connection to be used.

    Any advice please?

  • Hassan El Bouihi-Oracle
    Hassan El Bouihi-Oracle Rank 5 - Community Champion

    Hello JEngalan,


    Please raise an SR and Support will work with you on how to get the logs.

    Thank you

    Hassan

  • JEngalan
    JEngalan Rank 2 - Community Beginner
    edited October 2024

    Oracle SR raised and confirmed OTBI does not yet support the following MAC protocols allowed by the target SFTP server:

    - hmac-sha2-256-etm@openssh.com

    - hmac-sha2-512-etm@openssh.com

    The advice was to raise an Enhancement request to have these new MAC protocols supported:

    https://community.oracle.com/customerconnect/discussion/818659/enhancing-otbi-ssh-options-for-sftp-to-include-new-mac-protocols/p1?new=1

  • Hassan El Bouihi-Oracle
    Hassan El Bouihi-Oracle Rank 5 - Community Champion

    Thank you for keeping us posted.

    Hassan