Teraterm Key Verify Error #434

TeraTerm99 · 2025-01-22T19:22:21Z

Getting an "ssh2_kex_finish: key verify error (-1)" error when attempting a connection from a Window10 PC running Tera Term (including latest version 5.3). Wireshark capture shows the Windows 10 PC running Tera Term closing the connection "Client: Disconnect" upon receiving "Server: New Keys" packet.

Tera Term client is running SSH-2.0-TTSSH/2.92 Win32.
Server is running SSH-2.0-dropbear_2020.81.

Snapshot of the error and 'ssh2connect.log' file are attached.

Thank You,
M.

ssh2connect.log

nmaya · 2025-01-23T23:38:45Z

Thank you for your reporting.

I can't reproduce this issue in my environment.
I started up dropbear_2024.86 and connect to it, Key verify error didn't occur.

2025-01-23 23:15:30.288Z [23928] Initiating SSH session
2025-01-23 23:15:30.288Z [23928] Received server identification string: SSH-2.0-dropbear_2024.86
2025-01-23 23:15:30.288Z [23928] Sent client identification string: SSH-2.0-TTSSH/3.2 Win32
2025-01-23 23:15:30.303Z [23928] CRYPT_set_random_data: RAND_bytes call
2025-01-23 23:15:30.312Z [23928] client proposal: KEX algorithm: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512,diffie-hellman-group14-sha256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c,[email protected]
2025-01-23 23:15:30.312Z [23928] client proposal: server host key algorithm: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
2025-01-23 23:15:30.326Z [23928] client proposal: encryption algorithm client to server: [email protected],camellia256-ctr,[email protected],aes256-ctr,camellia256-cbc,aes256-cbc,camellia192-ctr,aes192-ctr,camellia192-cbc,aes192-cbc,[email protected],camellia128-ctr,aes128-ctr,camellia128-cbc,aes128-cbc,3des-ctr,3des-cbc,blowfish-ctr,blowfish-cbc,cast128-ctr,cast128-cbc
2025-01-23 23:15:30.331Z [23928] client proposal: encryption algorithm server to client: [email protected],camellia256-ctr,[email protected],aes256-ctr,camellia256-cbc,aes256-cbc,camellia192-ctr,aes192-ctr,camellia192-cbc,aes192-cbc,[email protected],camellia128-ctr,aes128-ctr,camellia128-cbc,aes128-cbc,3des-ctr,3des-cbc,blowfish-ctr,blowfish-cbc,cast128-ctr,cast128-cbc
2025-01-23 23:15:30.336Z [23928] client proposal: MAC algorithm client to server: [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,hmac-sha1,[email protected],[email protected],[email protected],hmac-md5
2025-01-23 23:15:30.338Z [23928] client proposal: MAC algorithm server to client: [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,hmac-sha1,[email protected],[email protected],[email protected],hmac-md5
2025-01-23 23:15:30.343Z [23928] client proposal: compression algorithm client to server: none
2025-01-23 23:15:30.343Z [23928] client proposal: compression algorithm server to client: none
2025-01-23 23:15:30.354Z [23928] CRYPT_set_random_data: RAND_bytes call
2025-01-23 23:15:30.354Z [23928] SSH2_MSG_KEXINIT was sent at SSH2_send_kexinit().
2025-01-23 23:15:30.354Z [23928] SSH2_MSG_KEXINIT was received.
2025-01-23 23:15:30.354Z [23928] server proposal: KEX algorithm: curve25519-sha256,[email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,[email protected],[email protected]
2025-01-23 23:15:30.370Z [23928] Server supports strict kex. Strict kex will be enabled.
2025-01-23 23:15:30.374Z [23928] server proposal: server host key algorithm: ssh-ed25519,ecdsa-sha2-nistp256,rsa-sha2-256,ssh-rsa
2025-01-23 23:15:30.374Z [23928] server proposal: encryption algorithm client to server: [email protected],aes128-ctr,aes256-ctr
2025-01-23 23:15:30.374Z [23928] server proposal: encryption algorithm server to client: [email protected],aes128-ctr,aes256-ctr
2025-01-23 23:15:30.386Z [23928] server proposal: MAC algorithm client to server: hmac-sha1,hmac-sha2-256
2025-01-23 23:15:30.386Z [23928] AEAD cipher is selected, ignoring MAC algorithms. (client to server)
2025-01-23 23:15:30.386Z [23928] server proposal: MAC algorithm server to client: hmac-sha1,hmac-sha2-256
2025-01-23 23:15:30.386Z [23928] AEAD cipher is selected, ignoring MAC algorithms. (server to client)
2025-01-23 23:15:30.401Z [23928] server proposal: compression algorithm client to server: [email protected],none
2025-01-23 23:15:30.406Z [23928] server proposal: compression algorithm server to client: [email protected],none
2025-01-23 23:15:30.406Z [23928] server proposal: language client to server:
2025-01-23 23:15:30.406Z [23928] server proposal: language server to client:
2025-01-23 23:15:30.418Z [23928] KEX algorithm: ecdh-sha2-nistp256
2025-01-23 23:15:30.418Z [23928] server host key algorithm: ecdsa-sha2-nistp256
2025-01-23 23:15:30.418Z [23928] encryption algorithm client to server: [email protected]
2025-01-23 23:15:30.418Z [23928] encryption algorithm server to client: [email protected]
2025-01-23 23:15:30.433Z [23928] MAC algorithm client to server: <implicit>
2025-01-23 23:15:30.437Z [23928] MAC algorithm server to client: <implicit>
2025-01-23 23:15:30.437Z [23928] compression algorithm client to server: none
2025-01-23 23:15:30.437Z [23928] compression algorithm server to client: none
2025-01-23 23:15:30.449Z [23928] CRYPT_set_random_data: RAND_bytes call
2025-01-23 23:15:30.449Z [23928] SSH2_MSG_KEX_ECDH_INIT was sent at SSH2_ecdh_kex_init().
2025-01-23 23:15:30.449Z [23928] SSH2_MSG_KEX_ECDH_REPLY was received.
2025-01-23 23:15:30.468Z [23928] Calling known_hosts dialog...(SSHUNKNOWNHOST)
2025-01-23 23:15:30.468Z [23928] SSH2_MSG_NEWKEYS was received(DH key generation is completed).
2025-01-23 23:15:30.468Z [23928] handle_SSH2_newkeys: Strict kex is enabled, resetting receiver sequence number 3
2025-01-23 23:15:30.468Z [23928] SSH2_EXT_INFO was received.
2025-01-23 23:15:30.468Z [23928] handle_SSH2_ext_info: 1 extensions
2025-01-23 23:15:30.481Z [23928] handle_SSH2_ext_info: extension: server-sig-algs, value: ssh-ed25519,[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],rsa-sha2-256,ssh-rsa
2025-01-23 23:15:37.562Z [23928] CRYPT_set_random_data: RAND_bytes call
2025-01-23 23:15:37.565Z [23928] ssh2_send_newkeys: SSH2_MSG_NEWKEYS was sent.
2025-01-23 23:15:37.575Z [23928] ssh2_send_newkeys: Strict kex is enabled, resetting sender sequence number 3
2025-01-23 23:15:37.580Z [23928] Entering secure mode

Please let us know what TTSSH debug log says.

Edit TERATERM.INI (in Tera Term 5, maybe in C:\Users\username\AppData\Roaming\teraterm5) LogLevel=100 in [TTSSH] section, and connect to server.
Attach TTSSH.LOG (in Tera Term 5, maybe in C:\Users\username\AppData\Local\teraterm5) this issue.

At last, currently we only maintain Tera Term 5.x.

Thanks,

docker hub の hactrom/dropbear を利用
- latest で dropbear_2024.86 だった
切り分け
- dropbear の特定のバージョンでのみ起こるのか
  - 上記のテストでは dropbear_2024.86 で再現しなかった
- 選択された KEX アルゴリズム
  - 上記のテストでは ecdh-sha2-nistp256 で再現しなかった

TeraTerm99 · 2025-01-24T19:52:37Z

Hello, Thank you for looking into this. Attached is the file requested. The client & server seem to agree on the algorithms to use, but something within the SSH2_MSG_KEXDH_REPLY appears to cause a key verify error. From the code, it looks like somewhere in key_verify() or ssh_ed25519_verify(). I don’t have a compiler installed to dig deeper. Could also be a bug in SSH-2.0-dropbear_2020.81 that was perhaps fixed in the latest version (SSH-2.0-dropbear_2020.81) that you are using. Please let me know. Thank You, M.

TeraTerm99 · 2025-01-24T19:54:22Z

In case the files didn't make it in the e-mail response above.

TTSSH.LOG

ssh2connect.log

nmaya · 2025-01-24T22:42:46Z

Thank you for sending your log.

I set parameters as above and connected to dropbear_2024.86.

Received server identification string: SSH-2.0-dropbear_2024.86
<snip>
KEX algorithm: diffie-hellman-group14-sha256
server host key algorithm: ssh-ed25519
encryption algorithm client to server: [email protected]
encryption algorithm server to client: [email protected]
MAC algorithm client to server: <implicit>
MAC algorithm server to client: <implicit>
compression algorithm client to server: none
compression algorithm server to client: none

key verify error didn't occur.

I changed the dropbear version to dropbear_2020.81.

Received server identification string: SSH-2.0-dropbear_2020.81
<snip>
KEX algorithm: diffie-hellman-group14-sha256
server host key algorithm: ssh-ed25519
encryption algorithm client to server: [email protected]
encryption algorithm server to client: [email protected]
MAC algorithm client to server: <implicit>
MAC algorithm server to client: <implicit>
compression algorithm client to server: none
compression algorithm server to client: none

key verify error didn't occur.

Hmm...

dropbear_2020.81 は hectormolinero/dropbear:v12 を使用
アルゴリズムを同じにしても再現しない

TeraTerm99 · 2025-01-24T23:34:08Z

Very strange indeed. Would you be able to send me a Wireshark capture your 2nd test (the one with SSH-2.0-dropbear_2020.81 using the same parameters as I use ? I’d like to see if there is anything different within the packets, perhaps that will yield a clue. Also note that I am using a Windows 10 machine and SSH-2.0-TTSSH/3.2 Win32, whereas you are using SSH-2.0-TTSSH/3.3 Win32. Thank you for your continued support. M.

nmaya · 2025-01-25T00:32:11Z

same parameters as I use

I think they are same. I showd decided algorithms by negotiation above.

it looks like somewhere in key_verify() or ssh_ed25519_verify().

I think your guess above is right.
But that function seems to work right in other env.

I added debug messages and built binary.
Please let us know what message is shown in ssh_ed25519_verify().

Thanks,

TeraTerm99 · 2025-01-25T04:20:12Z

The debug message shown is: "crypto_sign_ed25519_open(): failed"

Thank You,
M.

nmaya · 2025-01-25T12:57:41Z

Added debug message and new binary.
Please let us know two messages.

In my env, 1st message is "signaturelen: 83, datalen: 32, len: 64, rlen: 0, smlen: 96, mlen: 96"
latest ed25519 source code in OpenSSH is here, TTSSH uses old OpenSSH code, but I think old code is not wrong.

TeraTerm99 · 2025-01-25T23:43:08Z

The debug messages shown are...
"signaturelen: 83, datalen: 32, len: 64, rlen:0, smlen: 96, mlen: 96:
"crypto_sign_ed25519_open(): failed"

The issue then likely occurs in crypto_sign_ed25519_open(). Need a few debug messages in there at various points to identify which variable value is wrong.

Thank You,
M.

nmaya · 2025-01-28T12:03:44Z

I added some debug print to dump file of variables. Binary is here.
debug print files is outputted to C:\Users\username\AppData\Roaming\teraterm5.

Please let us know dump41-44.bin contents.

Thanks,

The error occurs in this section of KEX in SSH sequence.

dump41.bin is signature from SSH server.
It is "KEXDH_REPLY description: signature" in ssh2connect.log
It is s in above image.

dump42.bin is hash that is calculated in TTSSH.
It is H in above image.

dump43.bin is sm in ssh_ed25519_verify() and crypto_sign_ed25519_open().
It is concated of blob of signature s (len=0x40) and hash H (len=0x20).
It is printed in here.

dump44.bin is t2 in crypto_sign_ed25519_open().
It is derived from server host public key and s and hash by ge25519_double_scalarmult_vartime().
Its length = 0x20. It is compared with head 0x20 length of s by crypto_verify_32(). (I'm not a expert of cryptographic. I don't know why only first half of signature is compared. But OpenSSH does so.)
It is printed in here. If this file is not outputted, crypto_sign_ed25519_open() is returned here.

pk in crypto_sign_ed25519_open() is K_S in above image.

TeraTerm99 · 2025-01-28T23:37:16Z

Something may be wrong with this latest build. I downloaded and installed it [installer\Output\teraterm-5.4-dev-20250128_202120-a0c8af77b-appveyor-snapshot.exe], but am not seeing any dump41-44.bin files. In fact, I am no longer seeing any of the previous debug messages. I only see the original "ssh2_kex_finish: key verify error (-1)" error.

Were all the previous debug statements maintained or removed ?

To validate, I uninstalled this version and installed the previous version. All the debug statements are there.

nmaya · 2025-01-29T09:54:56Z

Hi,

I removed debug popup messages because it clarified that this problem occurs in crypto_sign_ed25519_open().

I ran and confirmed in Visual Studio. But I forgot that the debug dump function only works in debug build. I apologize for that.
This is debug build ttxssh.dll. Please replace with this ttxxh.dll, and use this for test.
ttxssh-debug_print.zip

TeraTerm99 · 2025-01-29T17:21:43Z

Hello, Same result, no debug dump files. I re-installed [installer\Output\teraterm-5.4-dev-20250128_202120-a0c8af77b-appveyor-snapshot.exe], then replaced the installed ttxssh.dll with the new one, but no change. ![Image](https://github.com/user-attachments/assets/f4baacba-8cd3-448b-9319-49b05242163c)

nmaya · 2025-01-29T23:48:59Z

Hi,

Did you dig both C:\Users\username\AppData\Local\teraterm5 and C:\Users\username\AppData\Roaming\teraterm5?

Or use snapshot zip archive as portable mode.

unzip
put portable.ini file (empty file is OK)
replace ttxssh.dll
copy TERATERM.INI from Roaming\teraterm5 to use current setting.
dump file is output to exe present dir

TeraTerm99 · 2025-01-30T18:16:53Z

Hi,

My apologies, the files were indeed within the Roaming directory, I could swear I looked, but missed it.

Attached are the dump41-45.bin files.

dump41-44.zip

nmaya · 2025-01-30T23:51:05Z

The key blob part of dump41.bin and the first 0x40 bytes of dump43.bin are the same. It is OK.
dump42.bin and 33rd byte onwards in dump43.bin are the same. It is OK.
The first 0x20 bytes of dump43.bin and dump44.bin are not the same. It is unexpected behavior.

If you use OpenSSH client to connect your dropbear server, the problem (this issue) occurs?

TeraTerm99 · 2025-01-30T23:55:14Z

I am not sure I understand the question. I am using OpenSSH client to connect to a device that is running dropbear server, and this is where the issue occurs. Please advise if I misunderstood ?

nmaya · 2025-01-31T03:19:46Z

TTSSH copies many source code from OpenSSH, it is nearly the same as OpenSSH about crypto/sign usage.
If TTSSH fails to connect dropbear and OpenSSH fails to connect too, it must be trouble, but I can understand.
But if TTSSH fails to connect but OpenSSH connect to successfuly, it seems to strange for me.

TeraTerm99 · 2025-01-31T03:29:36Z

Thank you for the clarification. I erred when I said I am using OpenSSH, I was thinking about TeraTerm using OpenSSL and got confused. I have not tested with OpenSSH client to dropbear server.

Lookin at OpenSSH, I see it is not supported for WIndows, but it is for Linux, so I'll have to see if I can get it runing on a Linux Ubuntu distribution runing within VirtualBox on a WIndows PC.

nmaya · 2025-01-31T11:09:24Z

Microsoft provides OpenSSH on Windows 10. If it is installed, ssh -V on cmd returns OpenSSH version.
https://learn.microsoft.com/en-us/windows-server/administration/OpenSSH/openssh-overview
https://www.ionos.com/digitalguide/server/configuration/windows-10-ssh/

When connect from OpenSSH client, to use algorithms which is decided between Tera Term and your dropbear (it is shown in your TTSSH.LOG), specify it.

ssh -o [email protected] -o KexAlgorithms=diffie-hellman-group14-sha256 -o HostKeyAlgorithms=ssh-ed25519 -o Compression=no -vvv 192.0.2.1

specify:

kex algo
hostkey algo
cipher algo
mac algo (if [email protected], automatic)
compression

-vvv shows debug messages.

nmaya · 2025-02-04T14:56:53Z

Summary

I can not reproduce this issue in my server. What is the different and same in our envs.

decided algorithms between TTSSH and TeraTerm99' s dropbear server

	decided
KEX	diffie-hellman-group14-sha256
hostkey	ssh-ed25519
cipher	[email protected]
MAC	implicit, because [email protected]
comp	none

diffie-hellman-group14-sha256 KEX algorithm and ssh-ed25519 server hostkey have to be selected.
This info is important to reproduce this issue.
And also this info is important to test with other SSH client with TeraTerm99's dropbear server.

supported algorithms at dropbear (server proposal)

Each (client and server) proposal strings are used in key exchange.

	TeraTerm99's	nmaya's
ver	2020.81	2020.81
KEX	curve25519-sha256,[email protected],diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,[email protected]	curve25519-sha256,[email protected], ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256, diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,[email protected]
hostkey	ssh-ed25519	ssh-ed25519 ,ecdsa-sha2-nistp256,rsa-sha2-256,ssh-rsa,ssh-dss
cipher	[email protected],aes128-ctr,aes256-ctr	[email protected],aes128-ctr,aes256-ctr
MAC	hmac-sha1,hmac-sha2-256	hmac-sha1,hmac-sha2-256
comp	[email protected],none	[email protected],none

To make all server proposal the same, I have to disable ECDH algorithms in server, and ECDSA, RSA and DSA server hostkeys.

Things that can't be the same

server host key
- It is unique for each SSH servers.
shared secret
- It is random number. It is generated for each connection.

Even if I try to make the maximum conditions the same, I cannot make the server key and random numbers the same.

nmaya · 2025-02-04T15:10:29Z

Other SSH clients can connect to your server? ex. OpenSSH, PuTTY.
diffie-hellman-group14-sha256 KEX algorithm and ssh-ed25519 server hostkey have to be selected.
If same issue occurs while connecting, probably your server has a problem.
If only Tera Term can not connect, probably Tera Term (or perhaps OpenSSH) has a problem.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Teraterm Key Verify Error #434

Teraterm Key Verify Error #434

TeraTerm99 commented Jan 22, 2025

nmaya commented Jan 23, 2025

TeraTerm99 commented Jan 24, 2025 via email •

edited

Loading

TeraTerm99 commented Jan 24, 2025

nmaya commented Jan 24, 2025

TeraTerm99 commented Jan 24, 2025 via email •

edited

Loading

nmaya commented Jan 25, 2025

TeraTerm99 commented Jan 25, 2025

nmaya commented Jan 25, 2025

TeraTerm99 commented Jan 25, 2025

nmaya commented Jan 28, 2025

TeraTerm99 commented Jan 28, 2025

nmaya commented Jan 29, 2025

TeraTerm99 commented Jan 29, 2025 via email •

edited

Loading

nmaya commented Jan 29, 2025

TeraTerm99 commented Jan 30, 2025

nmaya commented Jan 30, 2025

TeraTerm99 commented Jan 30, 2025 •

edited

Loading

nmaya commented Jan 31, 2025

TeraTerm99 commented Jan 31, 2025

nmaya commented Jan 31, 2025

nmaya commented Feb 4, 2025

nmaya commented Feb 4, 2025

Teraterm Key Verify Error #434

Teraterm Key Verify Error #434

Comments

TeraTerm99 commented Jan 22, 2025

nmaya commented Jan 23, 2025

TeraTerm99 commented Jan 24, 2025 via email • edited Loading

TeraTerm99 commented Jan 24, 2025

nmaya commented Jan 24, 2025

TeraTerm99 commented Jan 24, 2025 via email • edited Loading

nmaya commented Jan 25, 2025

TeraTerm99 commented Jan 25, 2025

nmaya commented Jan 25, 2025

TeraTerm99 commented Jan 25, 2025

nmaya commented Jan 28, 2025

TeraTerm99 commented Jan 28, 2025

nmaya commented Jan 29, 2025

TeraTerm99 commented Jan 29, 2025 via email • edited Loading

nmaya commented Jan 29, 2025

TeraTerm99 commented Jan 30, 2025

nmaya commented Jan 30, 2025

TeraTerm99 commented Jan 30, 2025 • edited Loading

nmaya commented Jan 31, 2025

TeraTerm99 commented Jan 31, 2025

nmaya commented Jan 31, 2025

nmaya commented Feb 4, 2025

Summary

decided algorithms between TTSSH and TeraTerm99' s dropbear server

supported algorithms at dropbear (server proposal)

Things that can't be the same

nmaya commented Feb 4, 2025

TeraTerm99 commented Jan 24, 2025 via email •

edited

Loading

TeraTerm99 commented Jan 24, 2025 via email •

edited

Loading

TeraTerm99 commented Jan 29, 2025 via email •

edited

Loading

TeraTerm99 commented Jan 30, 2025 •

edited

Loading