"returned incorrect signature type" using SecureCRT agent

[Gilles]

Hello.
I upgraded one of my VM to Debian 10. It uses openSSH 7.9 and openSSL:

openssl version
OpenSSL 1.1.1c 28 May 2019

When I connect to this host from another machine, using the SSH agent built in secureCRT, the distant machine issues this:
"agent key RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx returned incorrect signature type"

This does not happen when I use an ssh ssh agent from Linux (with the same private key). I also only happens on recent openSSL version.

The connection succeeds, but it show the warning everytime.

ssh -vvv distant_host

OpenSSH_7.9p1 Debian-10, OpenSSL 1.1.1c 28 May 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "XXX" port 22
debug2: ssh_connect_direct
debug1: Connecting to XXX [1.2.3.4] port 22.
debug1: Connection established.
debug1: identity file /home/XXUSERXX/.ssh/id_rsa type -1
debug1: identity file /home/XXUSERXX/.ssh/id_rsa-cert type -1
debug1: identity file /home/XXUSERXX/.ssh/id_dsa type -1
debug1: identity file /home/XXUSERXX/.ssh/id_dsa-cert type -1
debug1: identity file /home/XXUSERXX/.ssh/id_ecdsa type -1
debug1: identity file /home/XXUSERXX/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/XXUSERXX/.ssh/id_ed25519 type -1
debug1: identity file /home/XXUSERXX/.ssh/id_ed25519-cert type -1
debug1: identity file /home/XXUSERXX/.ssh/id_xmss type -1
debug1: identity file /home/XXUSERXX/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10
debug1: match: OpenSSH_7.9p1 Debian-10 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to XXX:22 as 'XXUSERXX'
debug3: hostkeys_foreach: reading file "/home/XXUSERXX/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/XXUSERXX/.ssh/known_hosts:34
debug3: load_hostkeys: loaded 1 keys from XXX
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh...01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh...01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128...cm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128...cm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm...28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm...28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128...cm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128...cm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm...28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm...28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:qMRLJcKegcc0wjCDIzXNyJ72B+drrlqXPZPg7kLMxZo
debug3: hostkeys_foreach: reading file "/home/XXUSERXX/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/XXUSERXX/.ssh/known_hosts:34
debug3: load_hostkeys: loaded 1 keys from XXX
debug3: hostkeys_foreach: reading file "/home/XXUSERXX/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/XXUSERXX/.ssh/known_hosts:35
debug3: load_hostkeys: loaded 1 keys from 1.2.3.4
debug1: Host 'XXX' is known and matches the ECDSA host key.
debug1: Found key in /home/XXUSERXX/.ssh/known_hosts:34
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: Will attempt key: gbo3 RSA SHA256:Nmq4JpXgT2RvGpu1w8Pof2GBxMJ0oaLr3mDEIDQeOLc agent
debug1: Will attempt key: /home/XXUSERXX/.ssh/id_rsa
debug1: Will attempt key: /home/XXUSERXX/.ssh/id_dsa
debug1: Will attempt key: /home/XXUSERXX/.ssh/id_ecdsa
debug1: Will attempt key: /home/XXUSERXX/.ssh/id_ed25519
debug1: Will attempt key: /home/XXUSERXX/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: gbo3 RSA SHA256:Nmq4JpXgT2RvGpu1w8Pof2GBxMJ0oaLr3mDEIDQeOLc agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: gbo3 RSA SHA256:Nmq4JpXgT2RvGpu1w8Pof2GBxMJ0oaLr3mDEIDQeOLc agent
debug3: sign_and_send_pubkey: RSA SHA256:Nmq4JpXgT2RvGpu1w8Pof2GBxMJ0oaLr3mDEIDQeOLc
debug3: sign_and_send_pubkey: signing using rsa-sha2-512
agent key RSA SHA256:Nmq4JpXgT2RvGpu1w8Pof2GBxMJ0oaLr3mDEIDQeOLc returned incorrect signature type
debug3: sign_and_send_pubkey: signing using ssh-rsa
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to XXX ([1.2.3.4]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 4
debug1: Remote: /home/XXUSERXX/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /home/XXUSERXX/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env HISTCONTROL
debug3: Ignored env TMUX
debug3: Ignored env LANGUAGE
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env EDITOR
debug3: Ignored env PWD
debug3: Ignored env LOGNAME
debug3: Ignored env XDG_SESSION_TYPE
debug3: Ignored env MC_TMPDIR
debug3: Ignored env LS_OPTIONS
debug3: Ignored env MC_SID
debug3: Ignored env HOME
debug1: Sending env LANG = en_US.UTF8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env LS_COLORS
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env XDG_SESSION_CLASS
debug3: Ignored env TERM
debug3: Ignored env USER
debug3: Ignored env TMUX_PANE
debug3: Ignored env SHLVL
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env NODE_PATH
debug3: Ignored env SSH_CLIENT
debug3: Ignored env PATH
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env HISTCONTROL
debug3: Ignored env TMUX
debug3: Ignored env LANGUAGE
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env EDITOR
debug3: Ignored env PWD
debug3: Ignored env LOGNAME
debug3: Ignored env XDG_SESSION_TYPE
debug3: Ignored env MC_TMPDIR
debug3: Ignored env LS_OPTIONS
debug3: Ignored env MC_SID
debug3: Ignored env HOME
debug1: Sending env LANG = en_US.UTF8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env LS_COLORS
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env XDG_SESSION_CLASS
debug3: Ignored env TERM
debug3: Ignored env USER
debug3: Ignored env TMUX_PANE
debug3: Ignored env SHLVL
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env NODE_PATH
debug3: Ignored env SSH_CLIENT
debug3: Ignored env PATH
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env MAIL
debug3: Ignored env SSH_TTY
debug3: Ignored env OLDPWD
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Linux XXX 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Sep 2 09:22:25 2019 from 123.123.123.123
09:22:32 XXUSERXX(1.22.57.8)@XXX(123.123.123.123)
~$ debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug3: send packet: type 98

[ashiosee]

For those who might be experiencing this same issue, SecureCRT's agent support currently does not implement the rsa-sha2-256 and rsa-sha2-512 signature algorithms that are possible with newer versions of OpenSSH.

A feature request has been recorded, and we will post here should a version of SecureCRT become available with this functionality.

[Maureen]

Thanks for following up. Our resources have been a bit limited, unfortunately.

This is on the product roadmap and we hope to implement it in the next version of SecureCRT. We'll post here when it's available to try.

Maureen

[renep]

I just wanted to record that I'm experiencing the same issue, when using Debian 10.5 (buster).

[jdev]

Originally Posted by renep

I just wanted to record that I'm experiencing the same issue, when using Debian 10.5 (buster).

Thanks for recording your experience.

--Jake

[renep]

I want to add to this feature request that this limitation is also annoying when using git over ssh in SecureCRT. As more of my servers are upgraded to Debian buster, I see this message appearing more and more:

$ git pull
agent key RSA SHA256:E/Ns8NzYScq9B5hGqGFi7qm3vnHELgBvbYJ1KCEru6E returned incorrect signature type
Already up to date.

$ git push
agent key RSA SHA256:E/Ns8NzYScq9B5hGqGFi7qm3vnHELgBvbYJ1KCEru6E returned incorrect signature type
Everything up-to-date

[jdev]

René,

Thanks for the additional information on how this is adversely affecting you. I'm sorry it's so annoying for you as more and more of your servers are updated.

This is on the product roadmap and we hope to implement it in the next version of SecureCRT. We'll post here when it's available to try.

--Jake

[renep]

Originally Posted by jdev

we hope to implement it in the next version of SecureCRT.

Unfortunately, I still see the same error message with SecureCRT Version 9.0.0 (x64 build 2315) - Beta Release - 24 september 2020

[jdev]

Originally Posted by renep

Unfortunately, I still see the same error message with SecureCRT Version 9.0.0 (x64 build 2315) - Beta Release - 24 september 2020

Dear renep,

Sorry it's still not working in the 9.0.0 B1 version!

It looks like we'll need some more detailed information about your specific scenario.

You've already provided info about the secondary host to which you're connecting (the Debian 10 machine), but there's still some details missing, so...

Would you be so kind as to send email to support@vandyke.com with a subject of "ATTN: Forum thread 13896 - Debian 10 agent support for rsa-sha2-512" ?

In the body of your email message to support@vandyke.com, would you please include the following details?

1. The type of key (algorithm name) that you have in SecureCRT's agent (Tools > Manage Agent Keys)
2. The operating system type and version of the primary host to which you're connected with SecureCRT.
3. The SSH2 server implementation and version that's running on the primary host to which you're connected with SecureCRT.
4. A trace options debug log showing the SecureCRT connection up to the point that the ssh connection to the secondary host has been established. In other words, configure trace options debug logging as per the video and then connect to the primary host; once connected to the primary host, run the ssh command to get to your secondary host; once connected to the secondary host, turn off logging and attach that log file to your email.

--Jake

[renep]

Originally Posted by jdev

Would you be so kind as to send email to support@vandyke.com with a subject of "ATTN: Forum thread 13896 - Debian 10 agent support for rsa-sha2-512" ?

Sure, I just did that. Let me know if there's more I can do to help squash this little bug.

[jdev]

Originally Posted by renep

Sure, I just did that. Let me know if there's more I can do to help squash this little bug.

Thanks for the info you sent via email. As per my email reply, I've assigned the issue to the SecureCRT product director for further assessment.

As news of a fix becomes available, we'll post here and we'll follow up with you via email.

--Jake

[renep]

Originally Posted by jdev

As news of a fix becomes available, we'll post here and we'll follow up with you via email.

Okay, thank you.

[tbaetzler]

Hi,

Originally Posted by jdev

Thanks for the info you sent via email. As per my email reply, I've assigned the issue to the SecureCRT product director for further assessment.

As news of a fix becomes available, we'll post here and we'll follow up with you via email.

--Jake

I'd be interested in this fix, too.

[jdev]

Originally Posted by tbaetzler

I'd be interested in this fix, too.

Glad to hear it!

You can monitor this forum thread for news of a fix, or if you want email notification, please send email:

• To: support@vandyke.com
  
• Subject: "ATTN: Please notify re Agent sha2-256 signature fix (Forum thread 13896)"
• In the body of your message, please indicate the email address of your VanDyke Software download account.

If others in the forum community would like email notification of this fix, please follow the same process as described above.

Thank you!
--Jake

[renep]

I just tested with 9.0 beta 5 and unfortunately the warning is still there.

Is this affecting all users who connect to a modern OpenSSH? If that's the case I'd expect it to be fixed in 9.0

If it's only affecting some, do we know why? Can we get rid of the problem by changing a configuration of SecureCRT/FX or OpenSSH?