Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
RE: Unable to exchange encryption keys
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Werner Stolz via curl-users <curl-users_at_lists.haxx.se>
Date: Wed, 26 Nov 2025 15:34:02 +0000
Yes, I am aware that we should not be using DSS keys. We must use them to accommodate some of our data partners.
Your link show exactly what we have been doing when we drive the SFTP command line tool for file transfers, but I was under the impression that
using the “-k” / “—insecure” option for curl does the same thing.
Historically, it has, with our previous version of curl, but somehow it is broken with this version.
[A black and pink logo Description automatically generated]
Werner Stolz
Advisor, Senior Software Developer
Office: 848.305.7158
Mobile: 630.404.3815
Chicago
InvestCloud.com<https://www.investcloud.com/> | LinkedIn<https://www.linkedin.com/company/investcloud/>
CNBC World’s Top Fintech Companies 2024
From: Jeffrey Walton <noloader_at_gmail.com>
Sent: Tuesday, November 25, 2025 10:10 AM
To: curl-users - the curl tool <curl-users_at_lists.haxx.se>
Subject: Re: Unable to exchange encryption keys
On Tue, Nov 25, 2025 at 9:50 AM Werner Stolz via curl-users <curl-users_at_lists.haxx.se<mailto:curl-users_at_lists.haxx.se>> wrote:
I have made a tiny bit of progress.
For this particular file transfer partner, I can log in manually using the sftp command if I use the following command line option: -o HostKeyAlgorithms=+ssh-dss
You should have two (maybe three) keys nowadays. The first two are ed25519 and ecdsa keys. They should work just about everywhere. The third key is a RSA key to connect to old SSH servers. If you don't connect to old servers, then don't have a RSA key.
You should not be using DSS keys. They were deprecated about 10 years ago in OpenSSH 7.0 (2015-08-11). From <https://www.openssh.org/releasenotes.html>:
* Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled
by default at run-time. These may be re-enabled using the
instructions at http://www.openssh.com/legacy.html
This actually confuses me even more, because I am already using the ‘-k’ option on the curl command line, which has always allowed
this to work in the past.
Also, when I remove the ‘-k’ option from curl, I get a different error message:
* Unknown host key type: 3932160
* closing connection #0
curl: (79) Unknown host key type: 3932160
It almost seems like someone broke the ‘-k’ option in this version of curl. Which seems unlikely, at the least.
________________________________
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.
________________________________
Received on 2025-11-26
Date: Wed, 26 Nov 2025 15:34:02 +0000
Yes, I am aware that we should not be using DSS keys. We must use them to accommodate some of our data partners.
Your link show exactly what we have been doing when we drive the SFTP command line tool for file transfers, but I was under the impression that
using the “-k” / “—insecure” option for curl does the same thing.
Historically, it has, with our previous version of curl, but somehow it is broken with this version.
[A black and pink logo Description automatically generated]
Werner Stolz
Advisor, Senior Software Developer
Office: 848.305.7158
Mobile: 630.404.3815
Chicago
InvestCloud.com<https://www.investcloud.com/> | LinkedIn<https://www.linkedin.com/company/investcloud/>
CNBC World’s Top Fintech Companies 2024
From: Jeffrey Walton <noloader_at_gmail.com>
Sent: Tuesday, November 25, 2025 10:10 AM
To: curl-users - the curl tool <curl-users_at_lists.haxx.se>
Subject: Re: Unable to exchange encryption keys
On Tue, Nov 25, 2025 at 9:50 AM Werner Stolz via curl-users <curl-users_at_lists.haxx.se<mailto:curl-users_at_lists.haxx.se>> wrote:
I have made a tiny bit of progress.
For this particular file transfer partner, I can log in manually using the sftp command if I use the following command line option: -o HostKeyAlgorithms=+ssh-dss
You should have two (maybe three) keys nowadays. The first two are ed25519 and ecdsa keys. They should work just about everywhere. The third key is a RSA key to connect to old SSH servers. If you don't connect to old servers, then don't have a RSA key.
You should not be using DSS keys. They were deprecated about 10 years ago in OpenSSH 7.0 (2015-08-11). From <https://www.openssh.org/releasenotes.html>:
* Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled
by default at run-time. These may be re-enabled using the
instructions at http://www.openssh.com/legacy.html
This actually confuses me even more, because I am already using the ‘-k’ option on the curl command line, which has always allowed
this to work in the past.
Also, when I remove the ‘-k’ option from curl, I get a different error message:
* Unknown host key type: 3932160
* closing connection #0
curl: (79) Unknown host key type: 3932160
It almost seems like someone broke the ‘-k’ option in this version of curl. Which seems unlikely, at the least.
________________________________
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.
________________________________
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.html
(image/png attachment: image001.png)