ecdsa-sha2-nistp521 Signature verification failed

[fyac]

I tried to connect to the switch, but encountered a signature verification error. By adjusting the DEFAULT_SERVER_HOST_KEY constant and moving the ecdsa-sha2-nistp521 algorithm to the end, I was able to pass the verification. It seems that there is an issue with the verification step for the ecdsa-sha2-nistp521 algorithm? Additionally, I also noticed two other issues where connection attempts to Huawei switches failed verification, and similarly, the failures occurred when the ecdsa-sha2-nistp521 algorithm was matched. I used Terminus to connect to this switch, and the verification passed, also using ecdsa-sha2-nistp521.

#925
#904

Custom crypto binding not available

Local ident: 'SSH-2.0-ssh2js1.16.0'
Client: Trying x.xx.xx.xxx on port xxx ...
Socket connected
Remote ident: 'SSH-2.0--'
Outbound: Sending KEXINIT
Inbound: Handshake in progress
Handshake: (local) KEX method: curve25519-sha256@libssh.org,curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group15-sha512,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,ext-info-c,kex-strict-c-v00@openssh.com
Handshake: (remote) KEX method: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
Handshake: KEX algorithm: diffie-hellman-group-exchange-sha1
Handshake: (local) Host key format: ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa
Handshake: (remote) Host key format: ecdsa-sha2-nistp521,ssh-dss,ssh-rsa
Handshake: Host key format: ecdsa-sha2-nistp521
Handshake: (local) C->S cipher: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
Handshake: (remote) C->S cipher: aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
Handshake: C->S Cipher: aes128-ctr
Handshake: (local) S->C cipher: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
Handshake: (remote) S->C cipher: aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
Handshake: S->C cipher: aes128-ctr
Handshake: (local) C->S MAC: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
Handshake: (remote) C->S MAC: hmac-sha2-256,hmac-sha2-256-96,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
Handshake: C->S MAC: hmac-sha2-256
Handshake: (local) S->C MAC: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
Handshake: (remote) S->C MAC: hmac-sha2-256,hmac-sha2-256-96,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
Handshake: S->C MAC: hmac-sha2-256
Handshake: (local) C->S compression: zlib@openssh.com,zlib
Handshake: (remote) C->S compression: none,zlib
Handshake: C->S compression: zlib
Handshake: (local) S->C compression: zlib@openssh.com,zlib
Handshake: (remote) S->C compression: none,zlib
Handshake: S->C compression: zlib
Outbound: Sending KEXDH_GEX_REQUEST
Received DH GEX Group
Outbound: Sending KEXDH_GEX_INIT
Received DH GEX Reply
Received DH Reply
Host accepted by default (no verification)
Host accepted (verified)
Outbound: Sending NEWKEYS
Inbound: NEWKEYS
Verifying signature ...
Signature verification failed
Outbound: Sending DISCONNECT (3)
Uncaught Error Error: Handshake failed: signature verification failed
    at makeError (/xx/ssh2/lib/protocol/utils.js:142:15)
    at doFatalError (/xx/ssh2/lib/protocol/utils.js:184:13)
    at finish (/xx/ssh2/lib/protocol/kex.js:709:18)
    at parse (/xx/ssh2/lib/protocol/kex.js:1267:23)
    at onKEXPayload (/xx/ssh2/lib/protocol/kex.js:1828:20)
    at decrypt (/xx/ssh2/lib/protocol/crypto.js:612:26)
    at parsePacket (/xx/ssh2/lib/protocol/Protocol.js:2028:25)
    at parse (/xx/ssh2/lib/protocol/Protocol.js:313:16)
. ..
Process exited with code 1

Terminus Logs：

👤 Starting a new connection to: "xxx" port "xxx"
⚙️ Address resolution finished
⚙️ Starting SSH session
⚙️ Remote server: SSH-2.0--
⚙️ Agreed KEX algorithm: diffie-hellman-group14-sha1
⚙️ Agreed Host Key algorithm: ecdsa-sha2-nistp521
⚙️ Agreed server-to-client cipher: aes256-ctr MAC: hmac-sha2-256
⚙️ Agreed client-to-server cipher: aes256-ctr MAC: hmac-sha2-256
⚙️ Agreed client-to-server compression: none
⚙️ Agreed server-to-client compression: none
⚙️ Handshake finished
👤 Checking host key: SHA256:c+YEbnDPsGL5tJBUQRn05uZBg2v4Q/Zj9UggaxvabBg
❗ Host xx is unknown
👤 Connection to "xx accepted
👤 Authenticating to xx as "xx"

In the other two cases, the issue could be circumvented by adjusting the algorithm, but my algorithm may need to connect to many devices. I'm not sure if this is a general problem. Are there any better solutions to address this?

node version: v24.12.0 ,I don't think Node is the culprit here. It's likely something else.

[mscdex]

At this stage it's more likely to be a bug in the remote side's SSH implementation, in which case there's not much that can be done about that, especially when their SSH ident is stripped like it is. For whatever reason this seems to be a recurring theme among network switch SSH implementations (Cisco has been notorious for this in the past).

[mscdex]

Terminus can probably connect because it's using a different set of algorithms, most notably the key exchange algorithm is different.

[fyac]

Terminus 可能能够连接，因为它使用了不同的算法集，最显著的是密钥交换算法不同。

I tried using the same set of algorithms as Termus, but it still didn't work. Switching to either diffie-hellman-group-exchange-sha1 or diffie-hellman-group14-sha1 resulted in the same error.

[mscdex]

Unfortunately in that case there's not much I can do because I don't have the same hardware to further troubleshoot things.

[fyac]

Unfortunately in that case there's not much I can do because I don't have the same hardware to further troubleshoot things.

Thank you.
I will continue troubleshooting this issue. I plan to find some open-source SSH software that can successfully connect, then debug and compare their hash verification data to see what differences exist. Alternatively, do you have any suggestions or insights you could share?

[fyac]

I have analyzed several sets of signature data provided by the Huawei switch by reading the R and S fields, and I may have identified the key issue: an extra 0 has been appended to each set of data.
I suspect the issue may stem from some older devices not strictly adhering to the mpint specification when encapsulating data in their engineering implementation.

data:

 READ Ecdsa R:  0001e5578093c4ecdf7462690....
 READ Ecdsa S:  0001e5578093c4ecdf7462690...

 READ Ecdsa R:  0000a42b6b9b1827937b62bd...
 READ Ecdsa S:  0000a42b6b9b1827937b62bd...
#
 READ Ecdsa R:  0000dedc6bba0e1e9e3fdd317...
 READ Ecdsa S:  0000dedc6bba0e1e9e3fdd317...

 READ Ecdsa R:  0000a7ed9e6f031a156ab8f05...
 READ Ecdsa S:  0000a7ed9e6f031a156ab8f05...

 READ Ecdsa R:  0063d9bcef6ee3dc33a76b9f...
 READ Ecdsa S:  0063d9bcef6ee3dc33a76b9f...

Perhaps we need to invoke an mpint conversion after reading the r and s values, which would make signature verification more robust.

After making the following code changes, the signature verification passed successfully and it did not affect other devices.
const r =utilBufferParser.readString(); --> const r = convertToMpint(utilBufferParser.readString());
const s =utilBufferParser.readString(); ---> const s = convertToMpint(utilBufferParser.readString());

function convertToMpint(buf) {
    let idx = 0;
    let length = buf.length;
    while (buf[idx] === 0x00) {
      ++idx;
      --length;
    }
    let newBuf;
    if (buf[idx] & 0x80) {
      newBuf = Buffer.allocUnsafe(1 + length);
      newBuf[0] = 0;
      buf.copy(newBuf, 1, idx);
      buf = newBuf;
    } else if (length !== buf.length) {
      newBuf = Buffer.allocUnsafe(length);
      buf.copy(newBuf, 0, idx);
      buf = newBuf;
    }
    return buf;
  }



sigSSHToASN1: (sig, type) => {
    switch (type) {
      case 'ssh-dss': {
        if (sig.length > 40)
          return sig;
        // Change bare signature r and s values to ASN.1 BER values for OpenSSL
        const asnWriter = new Ber.Writer();
        asnWriter.startSequence();
        let r = sig.slice(0, 20);
        let s = sig.slice(20);
        if (r[0] & 0x80) {
          const rNew = Buffer.allocUnsafe(21);
          rNew[0] = 0x00;
          r.copy(rNew, 1);
          r = rNew;
        } else if (r[0] === 0x00 && !(r[1] & 0x80)) {
          r = r.slice(1);
        }
        if (s[0] & 0x80) {
          const sNew = Buffer.allocUnsafe(21);
          sNew[0] = 0x00;
          s.copy(sNew, 1);
          s = sNew;
        } else if (s[0] === 0x00 && !(s[1] & 0x80)) {
          s = s.slice(1);
        }
        asnWriter.writeBuffer(r, Ber.Integer);
        asnWriter.writeBuffer(s, Ber.Integer);
        asnWriter.endSequence();
        return asnWriter.buffer;
      }
      case 'ecdsa-sha2-nistp256':
      case 'ecdsa-sha2-nistp384':
      case 'ecdsa-sha2-nistp521': {
        utilBufferParser.init(sig, 0);

         //old code
        // const r =utilBufferParser.readString()); 
        // const s =utilBufferParser.readString();
        // new code
        const r = convertToMpint(utilBufferParser.readString());
        const s = convertToMpint(utilBufferParser.readString());
        utilBufferParser.clear();
        if (r === undefined || s === undefined)
          return;

        const asnWriter = new Ber.Writer();
        asnWriter.startSequence();
        asnWriter.writeBuffer(r, Ber.Integer);
        asnWriter.writeBuffer(s, Ber.Integer);
        asnWriter.endSequence();
        return asnWriter.buffer;
      }
      default:
        return sig;
    }
  },