Aspera

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

Right, it's not the same code that is in charge of transfer and browsing.

Transfer is done in C in "ascp"

While browsing (GUI) is done in java in "asperascp".

If you look at release notes:

https://www.ibm.com/docs/en/asdc/4.4?topic=rn-release-notes-aspera-high-speed-transfer-server-high-speed-transfer-endpoint-desktop-client-443

You can see:

Added support for newer algorithms that allow the transfer tools to connect as clients to servers with a hardened SSH configuration. (Aspera #1484)

So, newer algorithms have been added, but maybe less secure ones have been removed.

As I can see, version 0.1.62 of JSch is used. (http://www.jcraft.com/jsch/)

Logs should be looked at on server or client side, to see which key type or algorithm do not match.

For example, server propose only DSA host key and client. does not accept DSA, etc...

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

I don't have direct access to the server logs, but I can check on the client side. Which log file would these entries potentially appear in?

Thanks again.

Right, it's not the same code that is in charge of transfer and browsing.

Transfer is done in C in "ascp"

While browsing (GUI) is done in java in "asperascp".

If you look at release notes:

https://www.ibm.com/docs/en/asdc/4.4?topic=rn-release-notes-aspera-high-speed-transfer-server-high-speed-transfer-endpoint-desktop-client-443

You can see:

Added support for newer algorithms that allow the transfer tools to connect as clients to servers with a hardened SSH configuration. (Aspera #1484)

So, newer algorithms have been added, but maybe less secure ones have been removed.

As I can see, version 0.1.62 of JSch is used. (http://www.jcraft.com/jsch/)

Logs should be looked at on server or client side, to see which key type or algorithm do not match.

For example, server propose only DSA host key and client. does not accept DSA, etc...

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

Since the problem occurs in the GUI, then in the GUI's logs.

One can find them in the GUI, like this:

Menu -> Tools -> Open Log Folder

In there locates the files: asperascp*

especially: asperascp.log

I don't have direct access to the server logs, but I can check on the client side. Which log file would these entries potentially appear in?

Thanks again.

Right, it's not the same code that is in charge of transfer and browsing.

Transfer is done in C in "ascp"

While browsing (GUI) is done in java in "asperascp".

If you look at release notes:

https://www.ibm.com/docs/en/asdc/4.4?topic=rn-release-notes-aspera-high-speed-transfer-server-high-speed-transfer-endpoint-desktop-client-443

You can see:

Added support for newer algorithms that allow the transfer tools to connect as clients to servers with a hardened SSH configuration. (Aspera #1484)

So, newer algorithms have been added, but maybe less secure ones have been removed.

As I can see, version 0.1.62 of JSch is used. (http://www.jcraft.com/jsch/)

Logs should be looked at on server or client side, to see which key type or algorithm do not match.

For example, server propose only DSA host key and client. does not accept DSA, etc...

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

I'm checking the asperascp*.log files in /var/log/ and most of what I see is peer connection information with, GUID/SID, addresses, account info, creation dates, etc. I'm not seeing anything on connection attempts and resulting failures (or successes for that matter). The other transfer logs do show the hot folder working correctly, but as you noted, they operate differently.

I did go into the log.html file in the AppData folder and found the following attempts and subsequent failures how you noted above, but no additional information:

This is password-based authentication and not key-based.

Since the problem occurs in the GUI, then in the GUI's logs.

One can find them in the GUI, like this:

Menu -> Tools -> Open Log Folder

In there locates the files: asperascp*

especially: asperascp.log

I don't have direct access to the server logs, but I can check on the client side. Which log file would these entries potentially appear in?

Thanks again.

Right, it's not the same code that is in charge of transfer and browsing.

Transfer is done in C in "ascp"

While browsing (GUI) is done in java in "asperascp".

If you look at release notes:

https://www.ibm.com/docs/en/asdc/4.4?topic=rn-release-notes-aspera-high-speed-transfer-server-high-speed-transfer-endpoint-desktop-client-443

You can see:

Added support for newer algorithms that allow the transfer tools to connect as clients to servers with a hardened SSH configuration. (Aspera #1484)

So, newer algorithms have been added, but maybe less secure ones have been removed.

As I can see, version 0.1.62 of JSch is used. (http://www.jcraft.com/jsch/)

Logs should be looked at on server or client side, to see which key type or algorithm do not match.

For example, server propose only DSA host key and client. does not accept DSA, etc...

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

Hi Jorge,

We have a KB article with some more details about the possible cause of this error message: https://www.ibm.com/support/pages/algorithm-negotiation-failed-error-while-connectingtransfering-hsts-41-windows

This is for instance a problem when connecting to HSTS servers on Windows typically with versions 4.1 and previous. In those older versions HSTS bundled a version of the Cygwin OpenSSH server with a configuration that only allowed for some specific Key Exchange algorithms that were needed to support some older client versions. That configuration is nowadays a bit too restrictive and those two algorithms are not supported anymore by the SSH implementation used in the Desktop Client app itself (the java code Laurent mentioned). 

Changing the configuration in the HSTS server as detailed in the KB article should address the issue. If the configuration they have is not quite the same or the partner has any questions or concerns about the change they can also create a support case and we can help them directly if needed.

I'm checking the asperascp*.log files in /var/log/ and most of what I see is peer connection information with, GUID/SID, addresses, account info, creation dates, etc. I'm not seeing anything on connection attempts and resulting failures (or successes for that matter). The other transfer logs do show the hot folder working correctly, but as you noted, they operate differently.

I did go into the log.html file in the AppData folder and found the following attempts and subsequent failures how you noted above, but no additional information:

This is password-based authentication and not key-based.

Since the problem occurs in the GUI, then in the GUI's logs.

One can find them in the GUI, like this:

Menu -> Tools -> Open Log Folder

In there locates the files: asperascp*

especially: asperascp.log

I don't have direct access to the server logs, but I can check on the client side. Which log file would these entries potentially appear in?

Thanks again.

Right, it's not the same code that is in charge of transfer and browsing.

Transfer is done in C in "ascp"

While browsing (GUI) is done in java in "asperascp".

If you look at release notes:

https://www.ibm.com/docs/en/asdc/4.4?topic=rn-release-notes-aspera-high-speed-transfer-server-high-speed-transfer-endpoint-desktop-client-443

You can see:

Added support for newer algorithms that allow the transfer tools to connect as clients to servers with a hardened SSH configuration. (Aspera #1484)

So, newer algorithms have been added, but maybe less secure ones have been removed.

As I can see, version 0.1.62 of JSch is used. (http://www.jcraft.com/jsch/)

Logs should be looked at on server or client side, to see which key type or algorithm do not match.

For example, server propose only DSA host key and client. does not accept DSA, etc...

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

Hi Jorge,

We have a KB article with some more details about the possible cause of this error message: https://www.ibm.com/support/pages/algorithm-negotiation-failed-error-while-connectingtransfering-hsts-41-windows

This is for instance a problem when connecting to HSTS servers on Windows typically with versions 4.1 and previous. In those older versions HSTS bundled a version of the Cygwin OpenSSH server with a configuration that only allowed for some specific Key Exchange algorithms that were needed to support some older client versions. That configuration is nowadays a bit too restrictive and those two algorithms are not supported anymore by the SSH implementation used in the Desktop Client app itself (the java code Laurent mentioned). 

Changing the configuration in the HSTS server as detailed in the KB article should address the issue. If the configuration they have is not quite the same or the partner has any questions or concerns about the change they can also create a support case and we can help them directly if needed.

I'm checking the asperascp*.log files in /var/log/ and most of what I see is peer connection information with, GUID/SID, addresses, account info, creation dates, etc. I'm not seeing anything on connection attempts and resulting failures (or successes for that matter). The other transfer logs do show the hot folder working correctly, but as you noted, they operate differently.

I did go into the log.html file in the AppData folder and found the following attempts and subsequent failures how you noted above, but no additional information:

This is password-based authentication and not key-based.

Since the problem occurs in the GUI, then in the GUI's logs.

One can find them in the GUI, like this:

Menu -> Tools -> Open Log Folder

In there locates the files: asperascp*

especially: asperascp.log

I don't have direct access to the server logs, but I can check on the client side. Which log file would these entries potentially appear in?

Thanks again.

Right, it's not the same code that is in charge of transfer and browsing.

Transfer is done in C in "ascp"

While browsing (GUI) is done in java in "asperascp".

If you look at release notes:

https://www.ibm.com/docs/en/asdc/4.4?topic=rn-release-notes-aspera-high-speed-transfer-server-high-speed-transfer-endpoint-desktop-client-443

You can see:

Added support for newer algorithms that allow the transfer tools to connect as clients to servers with a hardened SSH configuration. (Aspera #1484)

So, newer algorithms have been added, but maybe less secure ones have been removed.

As I can see, version 0.1.62 of JSch is used. (http://www.jcraft.com/jsch/)

Logs should be looked at on server or client side, to see which key type or algorithm do not match.

For example, server propose only DSA host key and client. does not accept DSA, etc...

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

I'm checking the asperascp*.log files in /var/log/ and most of what I see is peer connection information with, GUID/SID, addresses, account info, creation dates, etc. I'm not seeing anything on connection attempts and resulting failures (or successes for that matter). The other transfer logs do show the hot folder working correctly, but as you noted, they operate differently.

I did go into the log.html file in the AppData folder and found the following attempts and subsequent failures how you noted above, but no additional information:

This is password-based authentication and not key-based.

Since the problem occurs in the GUI, then in the GUI's logs.

One can find them in the GUI, like this:

Menu -> Tools -> Open Log Folder

In there locates the files: asperascp*

especially: asperascp.log

I don't have direct access to the server logs, but I can check on the client side. Which log file would these entries potentially appear in?

Thanks again.

Right, it's not the same code that is in charge of transfer and browsing.

Transfer is done in C in "ascp"

While browsing (GUI) is done in java in "asperascp".

If you look at release notes:

https://www.ibm.com/docs/en/asdc/4.4?topic=rn-release-notes-aspera-high-speed-transfer-server-high-speed-transfer-endpoint-desktop-client-443

You can see:

Added support for newer algorithms that allow the transfer tools to connect as clients to servers with a hardened SSH configuration. (Aspera #1484)

So, newer algorithms have been added, but maybe less secure ones have been removed.

As I can see, version 0.1.62 of JSch is used. (http://www.jcraft.com/jsch/)

Logs should be looked at on server or client side, to see which key type or algorithm do not match.

For example, server propose only DSA host key and client. does not accept DSA, etc...

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

By the way,

You can change the log level in asperascp to debug: Menu -> Tools -> preferences -> log level -> debug

Then you get the kex proposals from server and client, if you look for string: "cmdclient.CmdClient".

Or especially lines with "kex:" you can see what is proposed by the server andf client..

Maybe th jsch lib allows elsewise to add kex algorithms using a config file such as ssh_config file,...

I'm checking the asperascp*.log files in /var/log/ and most of what I see is peer connection information with, GUID/SID, addresses, account info, creation dates, etc. I'm not seeing anything on connection attempts and resulting failures (or successes for that matter). The other transfer logs do show the hot folder working correctly, but as you noted, they operate differently.

I did go into the log.html file in the AppData folder and found the following attempts and subsequent failures how you noted above, but no additional information:

This is password-based authentication and not key-based.

Since the problem occurs in the GUI, then in the GUI's logs.

One can find them in the GUI, like this:

Menu -> Tools -> Open Log Folder

In there locates the files: asperascp*

especially: asperascp.log

I don't have direct access to the server logs, but I can check on the client side. Which log file would these entries potentially appear in?

Thanks again.

Right, it's not the same code that is in charge of transfer and browsing.

Transfer is done in C in "ascp"

While browsing (GUI) is done in java in "asperascp".

If you look at release notes:

https://www.ibm.com/docs/en/asdc/4.4?topic=rn-release-notes-aspera-high-speed-transfer-server-high-speed-transfer-endpoint-desktop-client-443

You can see:

Added support for newer algorithms that allow the transfer tools to connect as clients to servers with a hardened SSH configuration. (Aspera #1484)

So, newer algorithms have been added, but maybe less secure ones have been removed.

As I can see, version 0.1.62 of JSch is used. (http://www.jcraft.com/jsch/)

Logs should be looked at on server or client side, to see which key type or algorithm do not match.

For example, server propose only DSA host key and client. does not accept DSA, etc...

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

Unfortunately there is no configuration file or local workaround unfortunately since these settings are not read from any file. We'd need to make changes to the Desktop client app to make these configurable via some configuration file or explicitly override the different default algorithm set.

Until the problem is resolved on the server side, one maybe creative approach, and admittedly involving a bunch of additional complexities, would involve setting a reverse proxy so the Desktop client would connect to the local reverse proxy for this server, and that proxy would then establish the ssh connection with the destination HSTS server. Then again, maybe it's simpler to set up another instance of the old Desktop Client on another machine just to connect to this server.

By the way,

You can change the log level in asperascp to debug: Menu -> Tools -> preferences -> log level -> debug

Then you get the kex proposals from server and client, if you look for string: "cmdclient.CmdClient".

Or especially lines with "kex:" you can see what is proposed by the server andf client..

Maybe th jsch lib allows elsewise to add kex algorithms using a config file such as ssh_config file,...

I'm checking the asperascp*.log files in /var/log/ and most of what I see is peer connection information with, GUID/SID, addresses, account info, creation dates, etc. I'm not seeing anything on connection attempts and resulting failures (or successes for that matter). The other transfer logs do show the hot folder working correctly, but as you noted, they operate differently.

I did go into the log.html file in the AppData folder and found the following attempts and subsequent failures how you noted above, but no additional information:

This is password-based authentication and not key-based.

Since the problem occurs in the GUI, then in the GUI's logs.

One can find them in the GUI, like this:

Menu -> Tools -> Open Log Folder

In there locates the files: asperascp*

especially: asperascp.log

I don't have direct access to the server logs, but I can check on the client side. Which log file would these entries potentially appear in?

Thanks again.

Right, it's not the same code that is in charge of transfer and browsing.

Transfer is done in C in "ascp"

While browsing (GUI) is done in java in "asperascp".

If you look at release notes:

https://www.ibm.com/docs/en/asdc/4.4?topic=rn-release-notes-aspera-high-speed-transfer-server-high-speed-transfer-endpoint-desktop-client-443

You can see:

Added support for newer algorithms that allow the transfer tools to connect as clients to servers with a hardened SSH configuration. (Aspera #1484)

So, newer algorithms have been added, but maybe less secure ones have been removed.

As I can see, version 0.1.62 of JSch is used. (http://www.jcraft.com/jsch/)

Logs should be looked at on server or client side, to see which key type or algorithm do not match.

For example, server propose only DSA host key and client. does not accept DSA, etc...

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------

I would expect that feature request to take some time to get worked into a sprint. I tried downgrading in-place, but received a downgrade rights error.

Would I be able to uninstall the current version and install a previous version to downgrade? Or is there something saved in AppData that would prevent that?

Unfortunately there is no configuration file or local workaround unfortunately since these settings are not read from any file. We'd need to make changes to the Desktop client app to make these configurable via some configuration file or explicitly override the different default algorithm set.

Until the problem is resolved on the server side, one maybe creative approach, and admittedly involving a bunch of additional complexities, would involve setting a reverse proxy so the Desktop client would connect to the local reverse proxy for this server, and that proxy would then establish the ssh connection with the destination HSTS server. Then again, maybe it's simpler to set up another instance of the old Desktop Client on another machine just to connect to this server.

By the way,

You can change the log level in asperascp to debug: Menu -> Tools -> preferences -> log level -> debug

Then you get the kex proposals from server and client, if you look for string: "cmdclient.CmdClient".

Or especially lines with "kex:" you can see what is proposed by the server andf client..

Maybe th jsch lib allows elsewise to add kex algorithms using a config file such as ssh_config file,...

I'm checking the asperascp*.log files in /var/log/ and most of what I see is peer connection information with, GUID/SID, addresses, account info, creation dates, etc. I'm not seeing anything on connection attempts and resulting failures (or successes for that matter). The other transfer logs do show the hot folder working correctly, but as you noted, they operate differently.

I did go into the log.html file in the AppData folder and found the following attempts and subsequent failures how you noted above, but no additional information:

This is password-based authentication and not key-based.

Since the problem occurs in the GUI, then in the GUI's logs.

One can find them in the GUI, like this:

Menu -> Tools -> Open Log Folder

In there locates the files: asperascp*

especially: asperascp.log

I don't have direct access to the server logs, but I can check on the client side. Which log file would these entries potentially appear in?

Thanks again.

Right, it's not the same code that is in charge of transfer and browsing.

Transfer is done in C in "ascp"

While browsing (GUI) is done in java in "asperascp".

If you look at release notes:

https://www.ibm.com/docs/en/asdc/4.4?topic=rn-release-notes-aspera-high-speed-transfer-server-high-speed-transfer-endpoint-desktop-client-443

You can see:

Added support for newer algorithms that allow the transfer tools to connect as clients to servers with a hardened SSH configuration. (Aspera #1484)

So, newer algorithms have been added, but maybe less secure ones have been removed.

As I can see, version 0.1.62 of JSch is used. (http://www.jcraft.com/jsch/)

Logs should be looked at on server or client side, to see which key type or algorithm do not match.

For example, server propose only DSA host key and client. does not accept DSA, etc...

Thanks Laurent, I've forwarded this to our partner so they can take a look at their server.

Incidentally, the Hot Folder began working again without issue, however, we still get the algorithm negotiation fail error when attempting to connect to the directory.

EDIT: Partner confirms using Aspera Client Mac version 3.5.5. Waiting on server version. Any fix they can apply to allow connections from 4.4.3?

Also, we began to see another connection reporting a server aborted session: license expired error. 

EDIT: This license expired issue seems unrelated to version / encryption differences. Confirmed by partner.

We're using Windows versions on our end but will check with our partners.

------------------------------
Jorge F.

Original Message:
Sent: Wed January 03, 2024 12:59 PM
From: Laurent Martin
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

So, you upgraded "Desktop Client" to 4.4.3

With a quick research I see that "Algorithm negotiation fail" comes from a java SSH implementation.

One can check like this (on mac or linux):

unzip -p asperascp.jar|strings|grep 'Algorithm negotiation fail'

This error is due to the fact that newer Desktop Client uses more secure encryption, and maybe the server uses an older SSH server.

------------------------------
Laurent Martin

Original Message:
Sent: Wed January 03, 2024 12:11 PM
From: Jorge F.
Subject: Algorithm negotiation fail with certain connections following Aspera Client upgrade to 4.4.3.891

Hi all, Happy New Year.

We upgraded all our Aspera Client instances to the current 4.4.3.891 version (upgraded from 3.8 I believe) and have started to see Algorithm negotiation fail errors with certain connections.

In troubleshooting with our partner, they insist we should be using Aspera Connect, and that this is the problem, however we have been using Aspera Client since we validated connectivity and even had a watch folder configured and working correctly until this upgrade.

I've asked the partner to confirm their server version.

Any insight and troubleshooting steps would be appreciated.

Thanks.

Jorge

------------------------------
Jorge F.
------------------------------