Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512) when key registered with ssh-agent #1551

Closed
stephencalvert2 opened this issue Feb 12, 2020 · 52 comments

Comments

@stephencalvert2
Copy link

Couldn't find a solution so opened opened a new issue:
trying to ssh to Pi 3b+ from Powershell in windows vs code using key authentication.
Works as expected if the public key file is in user/ .ssh and not registered with the agent using with ssh-add. If the key is registered the error: warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512) is generated and the remote system logon password is requested. Removing the key from the agent (ssh-add -d) and putting the .pub file in .ssh enables it to work as expected. Same error is encountered from a powershell window opened as administrator.

Client : Windows 10pro 10.0.18363
Key generated with 10.0.18363 ssh-keygen
Server : Raspberry Pi running Raspbian Buster with desktop
system updated with latest software versions

@stephencalvert2
Copy link
Author

Sorry i mean the private key in user.ssh or registered with the agent

@TravisDean
Copy link

Similar problem here. I've gotten the "different signature" line before, and here's some logs.

I have added id_rsa via ssh-add, both with forward and backward slashes on different attempts.

The only thing that sometimes works is deleting my identities from ssh-agent

> cat .ssh\config
Host 10.0.0.2
        User root
        IdentityFile C:\Users\tjose\.ssh\id_rsa


C:\Users\USERNAME>ssh 10.0.0.2 -vvv
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
debug1: Reading configuration data C:\\Users\\USERNAME/.ssh/config
debug1: C:\\Users\\USERNAME/.ssh/config line 5: Applying options for 10.0.0.2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_config error:2
debug2: resolve_canonicalize: hostname 10.0.0.2 is address
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.0.2 [10.0.0.2] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\USERNAME\\.ssh\\id_rsa type 0
debug3: Failed to open file:C:/Users/USERNAME/.ssh/id_rsa-cert error:2
debug3: Failed to open file:C:/Users/USERNAME/.ssh/id_rsa-cert.pub error:2
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\USERNAME\\.ssh\\id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9 FreeBSD-openssh-portable-7.9.p1_1,1
debug1: match: OpenSSH_7.9 FreeBSD-openssh-portable-7.9.p1_1,1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.0.2:22 as 'root'
debug3: hostkeys_foreach: reading file "C:\\Users\\USERNAME/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file C:\\Users\\USERNAME/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 10.0.0.2
debug3: Failed to open file:C:/Users/USERNAME/.ssh/known_hosts2 error:2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_known_hosts error:2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_known_hosts2 error:2
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@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-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none
debug2: compression stoc: none
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-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@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:Al8A0aiS6IEGANe11wUjwCByd7fWrf/mXvUjaRUusjI
debug3: hostkeys_foreach: reading file "C:\\Users\\USERNAME/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file C:\\Users\\USERNAME/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 10.0.0.2
debug3: Failed to open file:C:/Users/USERNAME/.ssh/known_hosts2 error:2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_known_hosts error:2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_known_hosts2 error:2
debug1: Host '10.0.0.2' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\USERNAME/.ssh/known_hosts:1
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
debug2: key: C:\\Users\\USERNAME\\.ssh\\id_rsa (0000014D101B9580), explicit, agent
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,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred 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: RSA SHA256:0DrTQAevLBKWbYALJXaffj8wElEAgb9o3jHoPJ7Eo7c C:\\Users\\USERNAME\\.ssh\\id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 535
debug2: input_userauth_pk_ok: fp SHA256:0DrTQAevLBKWbYALJXaffj8wElEAgb9o3jHoPJ7Eo7c
debug3: sign_and_send_pubkey: RSA SHA256:0DrTQAevLBKWbYALJXaffj8wElEAgb9o3jHoPJ7Eo7c
warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512)
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
debug3: failed to open file:C:/dev/tty error:3
debug1: read_passphrase: can't open /dev/tty: No such file or directory
Password for root@OPNsense.krakenlocal:
debug3: send packet: type 61
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
debug3: failed to open file:C:/dev/tty error:3
debug1: read_passphrase: can't open /dev/tty: No such file or directory
<Password prompt>

C:\Users\USERNAME>ssh-add -D
All identities removed.

C:\Users\USERNAME>ssh 10.0.0.2 -vvv
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
debug1: Reading configuration data C:\\Users\\USERNAME/.ssh/config
debug1: C:\\Users\\USERNAME/.ssh/config line 5: Applying options for 10.0.0.2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_config error:2
debug2: resolve_canonicalize: hostname 10.0.0.2 is address
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.0.2 [10.0.0.2] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\USERNAME\\.ssh\\id_rsa type 0
debug3: Failed to open file:C:/Users/USERNAME/.ssh/id_rsa-cert error:2
debug3: Failed to open file:C:/Users/USERNAME/.ssh/id_rsa-cert.pub error:2
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\USERNAME\\.ssh\\id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9 FreeBSD-openssh-portable-7.9.p1_1,1
debug1: match: OpenSSH_7.9 FreeBSD-openssh-portable-7.9.p1_1,1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.0.2:22 as 'root'
debug3: hostkeys_foreach: reading file "C:\\Users\\USERNAME/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file C:\\Users\\USERNAME/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 10.0.0.2
debug3: Failed to open file:C:/Users/USERNAME/.ssh/known_hosts2 error:2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_known_hosts error:2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_known_hosts2 error:2
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@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-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none
debug2: compression stoc: none
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-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@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:Al8A0aiS6IEGANe11wUjwCByd7fWrf/mXvUjaRUusjI
debug3: hostkeys_foreach: reading file "C:\\Users\\USERNAME/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file C:\\Users\\USERNAME/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 10.0.0.2
debug3: Failed to open file:C:/Users/USERNAME/.ssh/known_hosts2 error:2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_known_hosts error:2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_known_hosts2 error:2
debug1: Host '10.0.0.2' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\USERNAME/.ssh/known_hosts:1
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
debug2: key: C:\\Users\\USERNAME\\.ssh\\id_rsa (000002B9E0F79A10), explicit
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,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred 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: RSA SHA256:0DrTQAevLBKWbYALJXaffj8wElEAgb9o3jHoPJ7Eo7c C:\\Users\\USERNAME\\.ssh\\id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 535
debug2: input_userauth_pk_ok: fp SHA256:0DrTQAevLBKWbYALJXaffj8wElEAgb9o3jHoPJ7Eo7c
debug3: sign_and_send_pubkey: RSA SHA256:0DrTQAevLBKWbYALJXaffj8wElEAgb9o3jHoPJ7Eo7c
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to 10.0.0.2 ([10.0.0.2]: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
debug1: console supports the ansi parsing
debug3: Successfully set console output code page from:437 to 65001
debug3: Successfully set console input code page from:437 to 65001
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: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /root/.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
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
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
Last login: Sat Mar 14 00:29:35 2020 from 10.0.0.187


This doesn't seem to work consistently though, so I'm not sure how to continue debugging here.

@RaptahJezus
Copy link

This problem came up in October 2018, and the fix still has not been shipped out with Windows. The open ssh client needs to have an updated version of ssh-agent. Please see #1263 for a few workarounds, including manually updating the ssh-agent executable #1263 (comment)

I'm hopeful that after 1.5 years this will eventually be released officially.

@bagajjal
Copy link
Collaborator

@RaptahJezus - fyi, We are updating the windows inbox version of openssh with V8.1.0.0. This will be available during fall time.

@BichengWang
Copy link

BichengWang commented Apr 26, 2020

already 2020 Apr. but windows exist this issue.

@bagajjal
Copy link
Collaborator

@BichengWang - The fix will be part of next windows release which will be available during fall time (sometime in June / july)

@BichengWang
Copy link

@BichengWang - The fix will be part of next windows release which will be available during fall time (sometime in June / july)

Thank for the update.

@wallacms
Copy link

wallacms commented May 7, 2020

So just to be clear - is there any way to work around this issue, or is the current SSH agent just completely unusable when connecting to newer SSH servers?

@stephencalvert2
Copy link
Author

stephencalvert2 commented May 7, 2020 via email

@wallacms
Copy link

wallacms commented May 8, 2020

Works fine as long as you don't register the private key with the registry

If I don't register the private key with the registry then what is SSH agent doing?

To be clear, I have a file .ssh/id_rsa that is setup in the authorized_keys file on the remote host. If I do not run ssh-add and then SSH to the remote host, I'm prompted for my passphrase, I enter it and everything works (which is exactly what happens if I'm not using SSH agent at all).

If I do run ssh-add, my key gets added to the agent and everything appears to work. Then when I SSH to the remote host, I get:
warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512)
and then I'm prompted for my password (not the key passphrase) and I can login to the remote host.

@stephencalvert2
Copy link
Author

stephencalvert2 commented May 8, 2020 via email

@silentflight
Copy link

@BichengWang - The fix will be part of next windows release which will be available during fall time (sometime in June / july)

Are you referring to the May Update (2004)? I just updated and I'm still noticing this issue.

ssh -V is also still:

OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

@bagajjal
Copy link
Collaborator

bagajjal commented May 28, 2020

@silentflight15 - May update (2004) doesn't have the fix.
It will be part of next release that's likely available for public during fall time.

@AndrewSav
Copy link

@bagajjal

The fix will be part of next windows release which will be available during fall time (sometime in June / july)

Which year?

@bagajjal
Copy link
Collaborator

The next windows update will be available on 10/20/2020.

@CyanBook
Copy link

CyanBook commented Aug 2, 2020

The next windows update will be available on 10/20/2020.

what can I do to fix the error until that date?

@jatbains
Copy link

jatbains commented Aug 2, 2020

Wow! this needs to be fixed. Either through Windows Update or a downloadable patch.

@CyanBook
Copy link

CyanBook commented Aug 2, 2020

Wow! this needs to be fixed. Either through Windows Update or a downloadable patch.

i worked around using this comment: #1263 (comment)

@branhill
Copy link

The next windows update will be available on 10/20/2020.

I've installed Windows 10 20H2 19042.546 (Insider beta channel), but it's still OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5. I even tried to uninstall and reinstall it in optional features.

@RukaZhop
Copy link

Windows 10 20H2 RTM also contains 'OpenSSH_7.7p1 for Windows' (file version 7.7.2.1).
Waiting for the summer...

@Achsion
Copy link

Achsion commented Oct 25, 2020

Ye, still waiting for the "update"...

@mwtrigg
Copy link

mwtrigg commented Oct 25, 2020

This is deplorable.

Honestly, the solution is to decouple from the in-box version and keep up to date with the latest version yourself.

@MorphBonehunter
Copy link

@bagajjal

@silentflight15 - May update (2004) doesn't have the fix.
It will be part of next release that's likely available for public during fall time.

The next windows update will be available on 10/20/2020.

this isn't the case:
Windows: Version 20H2 (Build 19042.630)
SSH: OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

can you make some statement why this wasn't included in the 20H2 Update?

@AndrewSav
Copy link

@bagajjal On 29th of May, which was about 5 month ago, you said that this will be include in October update. Note, that the code changes were ready back then, it was just the matter of including them. We have patiently waited for this for 5 months.

Remember me asking above "which year?" Well, it looks like contrary to what you said, may be not this one.

Could you please explain what happened? Was 5 month not enough time to include already released code into the update? Why not, is it very laborious process? Did something went wrong?

@bagajjal
Copy link
Collaborator

bagajjal commented Nov 16, 2020

Here's what happened.

I checkin the changes to the destined branch in Jan 2020. It's released to insider fast ring (first party customers who have early access). Please see this issue. In the very end, windows decided to use a different branch. We were not informed of this change. Just like our OpenSSH community, I got surprised.
I'm working with windows team to get the changes through windows update (instead of waiting for next major windows release). There is no ETA as of now.

@altano
Copy link

altano commented Nov 16, 2020

According to #1263, @bagajjal, the fix for this was supposedly committed in Jan 2019, not Jan 2020, (after the issue was reported in Oct 2018).

@bagajjal
Copy link
Collaborator

@altano - #1263 is fixed on Jan 2019. It's part of V7.9 release on Jun 23 2019. This is a github release. The windows release is planned as part of V8.1 which I checkin in Jan 2020.

@altano
Copy link

altano commented Nov 16, 2020

@bagajjal you must be looking at the wrong issue and not #1263. The fix for that did NOT ship in June of 2019. Look at your own comment in June 2020:

As mentioned earlier, the next windows release which is available in fall time will have the fix.

That issue is NOT fixed. You've never released the fix. The thread is nothing but dozens of people saying they are still having it and absolutely no one has confirmed a fix. You must have been looking at a different issue?

@altano
Copy link

altano commented Nov 16, 2020

Also, if you read the title and description of this issue and #1263 they sound like the same issue to me, but I'm no expert so I'll have to defer to you.

@altano
Copy link

altano commented Nov 16, 2020

Lastly, and this is the thing that really confuses me, the version of OpenSSH that ships with Windows 20H2 is still 7.7.1.1, so I don't see what you mean by 7.9 shipping in June 23 2019?
image

@bagajjal
Copy link
Collaborator

@altano - We have two different releases.

  1. Github releases. Here.
    Github release is supported on Win7 and above.
    We encourage OpenSSH community to try the latest and greatest Github release.
    If this issue is a blocker, I recommend upgrading to Github release V8.1. Please follow manual instructions here.
  2. Windows releases. This comes by default with the windows 10 OS and windows server 2019.
    V7.7.2.x is shipped into windows 10 OS couple of years back.

This issue is fixed as part of Github release (NOT windows release) in v7.9.0.0p1-Beta.
image

We didn't have a windows release from v7.7 which is couple of years old. I agree it's too old, it happened because of several reasons (dev resource change, change in project priorities, misalignment of windows release dates, etc.).

I upgraded the windows release to V8.1 in Jan 2020. Unfortunately this couldn't make it to latest windows update because of reasons mentioned earlier.

@altano
Copy link

altano commented Nov 16, 2020

I think I'm missing something about the relevancy of that. Here's what I'm understanding:

Is any of that wrong?

@kensel
Copy link

kensel commented Dec 1, 2020

Why isn't this part of the normal windows update as it is a critical\breaking bugfix and potential security risk? Why is it only update in the latest windows version if we also have LTS versions?

@CCorrado
Copy link

CCorrado commented Dec 1, 2020

I think this list of pre-8.x OpenSSH vulnerabilities speaks for itself...I can't believe its taken over a year to create a Windows update that includes a fixed OpenSSH version compatible with the latest Linux distros.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh

@hiepxanh
Copy link

hiepxanh commented Jan 9, 2021

relax bro, I think they will fix it before Feb 12 2021, until now, it still less a year.
BTW, it really frustrated, I have enough problem with serrver, bug, hacker trying to jump in my server. and it really annoying haha

@kaytwo
Copy link

kaytwo commented Jan 12, 2021

For those generating new keys, joe-p's workaround posted in the other issue about this problem is helpful. TLDR: if you generate a modern ssh key using Curve25519, the agent doesn't sign the key with the wrong hash function, so a workaround is to use keys generated via:

ssh-keygen -t ed25519 -a 100
ssh-add [path-to-id_ed25519.pub]

Note that very old OSes may not accept ed25519 keys, and you can use ecdsa instead if necessary but it is considered less secure (but not less secure than SHA1 afaik).

@bb1
Copy link

bb1 commented Feb 9, 2021

For those generating new keys, joe-p's workaround posted in the other issue about this problem is helpful. TLDR: if you generate a modern ssh key using Curve25519, the agent doesn't sign the key with the wrong hash function, so a workaround is to use keys generated via:

ssh-keygen -t ed25519 -a 100
ssh-add [path-to-id_ed25519.pub]

This helped a LOT! Thanks!

@robie2011
Copy link

I had same issue. Re-Installing OpenSSH through windows feature solved for me.

@philBrown
Copy link

ssh-add [path-to-id_ed25519.pub]

FYI, that should be

ssh-add [path/to/id_ed25519]

You add the private key to your agent, not the public key

@Jeej
Copy link

Jeej commented Feb 23, 2021

@bagajjal A couple of days ago Windows 10 version 21H1 was announced. In the notes I don't see anything about SSH, so probably the fix is also not in this version?

It has been a year since this issue is created, there is a fix available, but the deployment is hard. Is it, for instance, a possibility to talk to other teams within Microsoft how they deploy fixes and use that information to get this fix out there? Since December last year .NET Core updates are distributed via Windows Update, maybe talk to them how to get the fix distributed?

@bagajjal
Copy link
Collaborator

@Jeej , OpenSSH v8.1 will be released as April windows update.

@mvadu
Copy link

mvadu commented Mar 7, 2021

For those generating new keys, joe-p's workaround posted in the other issue about this problem is helpful. TLDR: if you generate a modern ssh key using Curve25519, the agent doesn't sign the key with the wrong hash function, so a workaround is to use keys generated via:

ssh-keygen -t ed25519 -a 100
ssh-add [path-to-id_ed25519.pub]

This helped a LOT! Thanks!

I had to remove the rsa key first (ssh-add -d %userprofile%\.ssh\id_rsa) and add only the ed25519 identity (ssh-add %userprofile%\.ssh\id_ed25519) to get key based auth working again without the warning.

@talormanda
Copy link

For those generating new keys, joe-p's workaround posted in the other issue about this problem is helpful. TLDR: if you generate a modern ssh key using Curve25519, the agent doesn't sign the key with the wrong hash function, so a workaround is to use keys generated via:

ssh-keygen -t ed25519 -a 100
ssh-add [path-to-id_ed25519.pub]

This helped a LOT! Thanks!

This worked for me, but, I am not too technically versed in ssh. Can you tell me why the command "-t ed25519 -a 100" works and what it does?

@jcappe
Copy link

jcappe commented Apr 15, 2021

ssh-keygen -t ed25519 -a 100

Worked like magic,
here's how I fixed mine, along with some extra details that may be helpful for people.

I left the generated private key location as the default,
C:\Users\[USERNAME]\.ssh

and just scp'ed the public key over to linux:
scp C:\Users\[USERNAME]\.ssh\[keyname].pub [linuxuser]@[linuxIPaddress]:/home/[linuxuser]/.ssh

then on linux side (could do this via ssh...)
cat [keyname].pub >> authorized_keys

make sure to set permissions for .ssh folder and authorized_keys in linux!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
You have to do this part!
if you dont have the right permissions, Windows will not ssh into Linux without a password

cd /home/[linuxuser]
directory where .ssh is
can use
ls -a
to make sure seeing .ssh, its a hidden folder!

chmod 700 .ssh
that sets the permissions to read write execute, for only the current user, I think, you should check on this, or I will soon and will edit.
folder need to be able to be executed to open them?...

cd .ssh
chmod 640 authorized_keys

THEN IT SHOULD JUST WORK LIKE MAGIC!
ssh from Windows 10 into CentOS 8 without a password
Whooooo!

@JulioAviles
Copy link

JulioAviles commented Apr 15, 2021

Hi, guy...I find a better way to fix it.
PowerShells (Admin)

Uninstall the OpenSSH Client

Remove-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

  • restart Windows
    and then ...

Install the OpenSSH Client

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

-No restart needed

ENJOY

@johannesboon
Copy link

Thank you @JulioAviles for your suggestions:

Hi, guy...I find a better way to fix it.
PowerShells (Admin)

Uninstall the OpenSSH Client

Remove-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

  • restart Windows
    and then ...

Install the OpenSSH Client

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

But I tried it and it did not change anything on my system, it just reinstalls the same old C:\Windows\System32\OpenSSH\ssh.exe version 7.7.2.1 from 2019.

Maybe for example you installed a newer version of OpenSSH with Git for Windows? Could you provide the output of the following cmd.exe commands?:

where ssh (Should show C:\Windows\System32\OpenSSH\ssh.exe as first result)
ssh -V (On my system: OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5 )

and maybe winver ?

I'm still on Windows 20h2 (According to: winver )

@JulioAviles
Copy link

Thank you @JulioAviles for your suggestions:

Hi, guy...I find a better way to fix it.
PowerShells (Admin)

Uninstall the OpenSSH Client

Remove-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

  • restart Windows
    and then ...

Install the OpenSSH Client

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

But I tried it and it did not change anything on my system, it just reinstalls the same old C:\Windows\System32\OpenSSH\ssh.exe version 7.7.2.1 from 2019.

Maybe for example you installed a newer version of OpenSSH with Git for Windows? Could you provide the output of the following cmd.exe commands?:

where ssh (Should show C:\Windows\System32\OpenSSH\ssh.exe as first result)
ssh -V (On my system: OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5 )

and maybe winver ?

I'm still on Windows 20h2 (According to: winver )

Shure @johannesbone , all step in PowerShell (no any Git), just I want to let you know that was working well in 2 server, (1 Windows 10 Pro, 1 Ubuntu 20.04), and today stop working in Ubuntu, why? I dont know, I coundn't find the problem !! (warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512) came back. :(
I think Microsoft still need to work some bugs

winver = Win10Pro 20H2 (OS Built 19042.928)
cmd.exe = Microsoft Windows [Version 10.0.19042.928]
ssh -V = OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
ssh path = C:\Windows\System32\OpenSSH\ssh.exe (same)

@JulioAviles
Copy link

For those generating new keys, joe-p's workaround posted in the other issue about this problem is helpful. TLDR: if you generate a modern ssh key using Curve25519, the agent doesn't sign the key with the wrong hash function, so a workaround is to use keys generated via:

ssh-keygen -t ed25519 -a 100
ssh-add [path-to-id_ed25519.pub]

This helped a LOT! Thanks!

This worked for me, but, I am not too technically versed in ssh. Can you tell me why the command "-t ed25519 -a 100" works and what it does?

I can help a little but I have a doubt too !!
-t ed25519 ( type of algorithm based (EdDSA)) search wiki for details
-a 100 ( I do not know ) Help please !!

@oxc
Copy link

oxc commented Apr 19, 2021

Just check any of the man pages (like this one):

     -a rounds
             When saving a private key, this option specifies the number of KDF (key derivation function) rounds used.  Higher numbers result in slower
             passphrase verification and increased resistance to brute-force password cracking (should the keys be stolen).

@L-B
Copy link

L-B commented May 31, 2021

FWIW, the recent upgrade of Windows 10 OpenSSH to 8,1p1 by KB5003173 fixed the issue for me.

@kakash1hatake
Copy link

Using ssh included in Git for windows bundle worked to solve the problem for me.
It has OpenSSH_8.4p1, OpenSSL 1.1.1h

And my windows has pre-installed too old version:
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

@bagajjal
Copy link
Collaborator

Closing this issue as it's fixed in Win32-openssh V8.1+

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests