VanDyke Software Forums

VanDyke Software Forums (
-   Secure Shell (
-   -   8.31 error: Keys of type ecdsa-sha2 are not currently supported (

JaTu 12-10-2017 02:09 PM

8.31 error: Keys of type ecdsa-sha2 are not currently supported
This is a fresh install to a brand new laptop. I was just export/import:ing my old data from old laptop, but none of my ECDSA-keys seem to work.

That's really weird, same 8.31 64-bit install on both Windows 10 machines. Other one working, other one "not supported".

Any ideas what to try?

Jari Turkia

bgagnon 12-11-2017 08:51 AM

Hi Jari,

You use "working" and "not working" phrases frequently, but please elaborate.

Are both SecureCRT installations connecting to the same remote?

And publickey authentication fails on one SecureCRT installation and not the other?

It's often useful to see trace options output which provides debugging information that may help us better understand the problem that you're experiencing.

To enable trace options output:
  • First, open SecureCRT's main File pull-down menu and select Trace Options. If you open the File pull down menu again you should see a checkmark next to Trace Options, indicating that troubleshooting output is now enabled.
  • Next, connect to the remote machine. With trace options enabled, you will notice debugging information displayed in the terminal window that isn't normally there by default when SecureCRT is attempting to establish a connection, and at certain times throughout the lifetime of the connection.
  • Once the problem occurs, please right-click inside the terminal window and choose Select All, then right-click again and choose Copy to transfer the information to the clipboard.
  • Finally, open a text editor, paste the information from the clipboard into the editor program, and save it as a text file.
Since trace options can contain sensitive information, feel free to send it as an attachment via email to Please reference "Attn Brenda - Forum Thread #12936" in the subject line. Please attach trace options output from both a failed and successful connection to the email you send to support.

NOTICE: The requested troubleshooting data may include sensitive information (usernames, passwords, publicly-accessible host names or IP addresses, etc.).

Please redact sensitive information that would not be appropriate for email communication prior to sending the requested information.

If there is sensitive information that must be conveyed in order to provide a complete picture of the scenario you're facing, please let us know and we will set up a secure upload mechanism that can be used.

JaTu 12-11-2017 11:46 AM


SecureCRT at least since version 8.1.4 is on suitable conditions capable of emitting following error:

The wording in the English is: "not currently supported". So, I'd like to claim that I'm not using expression "not working" or "working" frequently in my original blog post.

On the old Windows, tracing enabled, the message I'm able to see is:
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ecdsa-sha2-nistp521) - unsigned,fingerprint (SHA-2 hash):

However, on the machine which doesn't SUPPORT ECDSA-keys, no usable trace line is available to copy/paste here. Since the ECDSA-key cannot be decrypted after appropriate password prompt, SecureCRT-login is in a forever-loop asking for credentials and ultimately I cancel the authentication attempt. The user interaction of cancelling the authentication, is appropriately logged to trace, I might add.

Still, my original claim stands. ECDSA-keys are supported on SecureCRT 8.3.1 installation on my old machine, but are apparently NOT supported on SecureCRT 8.3.1 installation on my new machine. The site configuration and keys ware imported from the old machine with export/import -functionality of SecureCRT.

Anything else you'd want me to try?

Jari Turkia

bgagnon 12-11-2017 12:15 PM

Hi Jari,


Anything else you'd want me to try?
Yes, I would like you to send complete trace options output to Trying to analyze just one line, out of context, from the trace options output is not usually a good idea.

JaTu 12-11-2017 03:07 PM

Yes, I understand that.

But this particular case is very trivial:
There is nothing in the trace to analyse. The trace does not contain anything about private key until it is sent to the server. And as the decrypting the key fails, SecureCRT does not send it to the server and thus, logs nothing.

Jari Turkia

bgagnon 12-11-2017 03:41 PM

Hi Jari,

How was the public/private keypair created?

JaTu 12-11-2017 04:32 PM

I use SSH mainly between Linuxes, so OpenSSH ssh-keygen was used to generate the key.

Let me remind: The keys work perfectly on my old laptop's SecureCRT. Also, my understanding is that doing the data export/import does transfer the settings and the private keys associated with those hosts successfully. Or at least that is what I can observe by comparing the settings and the filesystem between those two Windowses.

Jari Turkia

bgagnon 12-11-2017 04:47 PM

Hi Jari,

What version of OpenSSH?


Let me remind: The keys work perfectly on my old laptop's SecureCRT.
I cannot verify that without trace options output. So far you have posted one line of trace options output and it is the "unsigned" request.

JaTu 12-11-2017 05:39 PM

OpenSSH versions vary, as there are a number of servers and keys involved and they are generated over the years. All of ECDSA-keys work in my old laptop, so I don't think OpenSSH or its version is a factor here.

The trace-fragment I posted is from the machine where SecureCRT works and there is very little need for a trace to determine, that a connection opens as expected. You know it when you land at the prompt. I posted that trace-fragment to point out, that SecureCRT 8.3.1 with ECDSA private key does work on my old machine.

However, on my new machine, where I transferred SecureCRT configuration and keys to, it does not work. And the trace has absolutely nothing about the private key in it.

Jari Turkia

jdev 12-11-2017 06:39 PM

Dear Jari,

My name is Jake, and I manage the technical support department here at VanDyke Software.

One aspect of our troubleshooting process involves comparing success cases with failure cases to detect patterns that may help us arrive at a conclusion/solution.

In most scenarios involving connection/authentication failures, complete Trace Options output from a success case is used to provide a comparison with the complete Trace Options output from a failure case. We don't expect there to be any specifics regarding your private key file -- such information is never sent across the wire, nor is there anything private about the hashes that are displayed in the Trace Options output.

In some cases, Trace Options output comparisons can lead to the creation of a bug report. Since we're unable to replicate the problem you are experiencing, and we don't want you to expose your private keys in any way, we've asked you to send us Trace Options output (it doesn't contain private key data) to help us better understand your specific problem situation in comparison with what has worked for you on the other machine.

I hope this helps you to understand why Brenda has asked you to send in Trace Options information (not to post it here in the forums, but to send it via email to us directly).

Brenda also asked you what version of OpenSSH was used to create your private key file -- the one you're currently having trouble with.

Can you help me understand why you have so far been unwilling to provide the information she has requested?

Thank you!

JaTu 12-12-2017 12:54 AM

Hi Jake!

I understand what you're saying, but since this case is not involving connection/authentication failure, that is a moot point. The trace file still doen't contain anything about the local logic of verifying the existence of user given private key, nor validating it's content, nor decrypting it.

My success case trace lines are:
[LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK
[LOCAL] : Authenticating as user
[LOCAL] : RECV : USERAUTH_FAILURE, continuations [publickey,gssapi-keyex,gssapi-with-mic]
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ecdsa-sha2-nistp521) - unsigned,fingerprint (SHA-2 hash):
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ecdsa-sha2-nistp521) - signed,May 2000 Standard]

And subsequent failure trace lines are:
[LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK
[LOCAL] : RECV : USERAUTH_FAILURE, continuations [publickey,gssapi-keyex,gssapi-with-mic]
[LOCAL] : SEND: Disconnect packet: The user canceled authentication.

And as I've stated number of times before: I do cancel the authentication to get ouf of the forever-loop where my ECDSA-key isn't supported. This was never a connectivity issue, that I can debug successfully by using other clients. But this one is SecureCRT-specific and that's why I'm reaching for you. And this case is especially tricky, as the functionality is there, and on my old machine reading the private key works.

If I'd had the source code or knew somebody who knows the public key importing logic, I'd investigate the top-3 reasons why SecureCRT would emit error message "Keys of type ecdsa-sha2 are not currently supported", because that's the problem here. Targeting those top-3 reasons will surely yield the result for me. Not analysing the connection.

Jari Turkia

jdev 12-12-2017 10:45 AM


There is additional information contained in trace options output that can reveal other issues. The actual version of SecureCRT is confirmed, as well as the version of the SSH2 core library that SecureCRT is actually loading and using, and so on.

Having personally inspected the code for SecureCRT 8.3.1, I can say that the error you're seeing can occur in generally two cases; a) when a key type is not supported, or b) when a key file is corrupted such that SecureCRT is not able to successfully read all of the key data.

Would you be willing to confirm that your Trace Options output contains both "SSH2Core version" and "SecureCRT - Version 8.3.1" as well as an indication of "build 1537"?

If so, then I'm thinking that the error you're seeing is caused by some type of corruption in the key file itself (since 8.3.1 does indeed support ecdsa-sha2 key types).

Perhaps something might have gone wrong during the Export/Import process. Since I don't know how your key file was originally generated, nor with what version of OpenSSH, nor in what format your key file is saved (OpenSSH changed the format of their private key files some time ago), I'll need your continued cooperation to help me determine if this is really what's going on in your case.

When you compare the size of the key file on your old machine with the size of the key file on the new machine, are they the same?

When you compare the contents of the key file itself on your old machine with the key file contents of the file on your new machine, what differences do you notice?

If there are differences between your key file on the old machine vs. the key file on the new machine, then it indicates that there may very well be a flaw in the way SecureCRT is Exporting/Importing the key file in this specific case and it will become essential for us to know the format -- not the private/sensitive contents -- of your private key file so that we can replicate and then resolve the problem with a code change. Typically, the format of a key file can be determined by knowing exactly which version of OpenSSH was used to originally create this specific key file; that way, you don't have to risk revealing any of the sensitive information in your private key file.

If there are differences you notice in size and/or content of the key files on your old vs. new machine, would you be willing to manually copy over the key file from your old machine and put it into place on your new machine (in other words, bypassing SecureCRT's Export/Import mechanism for this specific case), and let me know if you are then able to successfully use the key for authentication in SecureCRT?


JaTu 12-12-2017 03:14 PM

Yes, I can confirm the version information:
[LOCAL] : SSH2Core version
SecureCRT - Version 8.3.1 (x64 build 1537)

About the key being altered in transit, that doesn't seem to be the case:
$ md5sum.exe ~/.ssh/id_ecdsa
83fd24812a29021fd43604b2a697996e */home/.ssh/id_ecdsa

The MD5-sum is identical on both machines.

Also, I don't believe the file can be corrupted, as SecureCRT appropriately prompts for the passphrase to decrypt the private key. That should suggest, SecureCRT did read the file, analyzed it and determined it to be an encrypted one. And after doing all that, says that ECDSA-SHA2 -keys are not supported.

Jari Turkia

jdev 12-12-2017 03:55 PM

Your original post indicated you had "same 8.31 64-bit install on both Windows 10 machines", yet the paths you're showing are UNIX-style.

While that's not outside the realm of possibility, I want to make sure I have all of the information accurate.

Can you confirm that this problem is occurring on Windows 10 in SecureCRT version 8.3.1?

And, can you pinpoint at all the version of OpenSSH that was used to originally create your private key file?


JaTu 12-12-2017 04:06 PM

Did you see the .exe-part in md5sum run?
Yes, I can confirm that I'm running a 64-bit Windows 10, but am running various *nix-tools on my Windows.

It is practically impossible to trace the precise OpenSSH-version. As I already said, I have dozen or so keys to various machines and they have been generated on different machines over some years.

Jari Turkia

All times are GMT -6. The time now is 04:29 PM.