x/crypto/ssh: bad kexinit during handshake #18711

Closed
vito opened this Issue Jan 18, 2017 · 21 comments

Comments

Projects
None yet
8 participants
@vito

vito commented Jan 18, 2017

What version of Go are you using (go version)?

1.7.x

What operating system and processor architecture are you using (go env)?

Linux, amd64

What operating system and processor architecture are you using (go env)?

What did you do?

Initiate a SSH connection.

What did you expect to see?

Successful handshake and healthy connection.

What did you see instead?

After upgrading x/crypto/ssh to golang/crypto@2e74c77 to fix #18439 I'm seeing handshakes fail occasionally with the following message coming from the ssh client:

input_userauth_error: bad message during authentication: type 20

Type 20 being SSH_MSG_KEXINIT. Maybe that's firing concurrently with the handshake or something? It appears to be flaky.

/cc @hanwen

@vito

This comment has been minimized.

Show comment
Hide comment
@vito

vito Jan 18, 2017

Here's ssh -vvv, if it helps:

[d][tsa] spawned /tmp/gexec_artifacts525385636/g608192691/tsa (pid: 31372)
[o][tsa] {"timestamp":"1484772013.263648510","source":"tsa","message":"tsa.listening","log_level":1,"data":{}}
[e][ssh] OpenSSH_7.4p1 Debian-5, OpenSSL 1.0.2j  26 Sep 2016
[e][ssh] debug1: Reading configuration data /etc/ssh/ssh_config
[e][ssh] debug1: /etc/ssh/ssh_config line 19: Applying options for *
[e][ssh] debug2: resolving "127.0.0.1" port 9801
[e][ssh] debug2: ssh_connect_direct: needpriv 0
[e][ssh] debug1: Connecting to 127.0.0.1 [127.0.0.1] port 9801.
[e][ssh] debug1: Connection established.
[e][ssh] debug1: identity file /tmp/tsa-key613344226/id_rsa type 1
[e][ssh] debug1: key_load_public: No such file or directory
[e][ssh] debug1: identity file /tmp/tsa-key613344226/id_rsa-cert type -1
[e][ssh] debug1: Enabling compatibility mode for protocol 2.0
[e][ssh] debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-5
[e][ssh] debug1: Remote protocol version 2.0, remote software version Go
[e][ssh] debug1: no match: Go
[e][ssh] debug2: fd 3 setting O_NONBLOCK
[e][ssh] debug1: Authenticating to 127.0.0.1:9801 as 'alex'
[e][ssh] debug3: put_host_port: [127.0.0.1]:9801
[e][ssh] debug3: hostkeys_foreach: reading file "/tmp/known-hosts154180302"
[e][ssh] debug3: record_hostkey: found key type RSA in file /tmp/known-hosts154180302:1
[e][ssh] debug3: load_hostkeys: loaded 1 keys from [127.0.0.1]:9801
[e][ssh] debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
[e][ssh] debug3: send packet: type 20
[e][ssh] debug1: SSH2_MSG_KEXINIT sent
[e][ssh] debug3: receive packet: type 20
[e][ssh] debug1: SSH2_MSG_KEXINIT received
[e][ssh] debug2: local client KEXINIT proposal
[e][ssh] 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
[e][ssh] debug2: host key algorithms: ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
[e][ssh] debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
[e][ssh] debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
[e][ssh] 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
[e][ssh] 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
[e][ssh] debug2: compression ctos: none,zlib@openssh.com,zlib
[e][ssh] debug2: compression stoc: none,zlib@openssh.com,zlib
[e][ssh] debug2: languages ctos:
[e][ssh] debug2: languages stoc:
[e][ssh] debug2: first_kex_follows 0
[e][ssh] debug2: reserved 0
[e][ssh] debug2: peer server KEXINIT proposal
[e][ssh] debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
[e][ssh] debug2: host key algorithms: ssh-rsa
[e][ssh] debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,arcfour256,arcfour128
[e][ssh] debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,arcfour256,arcfour128
[e][ssh] debug2: MACs ctos: hmac-sha2-256,hmac-sha1,hmac-sha1-96
[e][ssh] debug2: MACs stoc: hmac-sha2-256,hmac-sha1,hmac-sha1-96
[e][ssh] debug2: compression ctos: none
[e][ssh] debug2: compression stoc: none
[e][ssh] debug2: languages ctos:
[e][ssh] debug2: languages stoc:
[e][ssh] debug2: first_kex_follows 0
[e][ssh] debug2: reserved 0
[e][ssh] debug1: kex: algorithm: curve25519-sha256@libssh.org
[e][ssh] debug1: kex: host key algorithm: ssh-rsa
[e][ssh] debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
[e][ssh] debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
[e][ssh] debug3: send packet: type 30
[e][ssh] debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
[e][ssh] debug3: receive packet: type 31
[e][ssh] debug1: Server host key: ssh-rsa SHA256:QA5i5Qh2CpcrRbwiqYu+KIa66313opd5+KB9EFeqL9s
[e][ssh] debug3: put_host_port: [127.0.0.1]:9801
[e][ssh] debug3: put_host_port: [127.0.0.1]:9801
[e][ssh] debug3: hostkeys_foreach: reading file "/tmp/known-hosts154180302"
[e][ssh] debug3: record_hostkey: found key type RSA in file /tmp/known-hosts154180302:1
[e][ssh] debug3: load_hostkeys: loaded 1 keys from [127.0.0.1]:9801
[e][ssh] debug1: Host '[127.0.0.1]:9801' is known and matches the RSA host key.
[e][ssh] debug1: Found key in /tmp/known-hosts154180302:1
[e][ssh] debug3: send packet: type 21
[e][ssh] debug2: set_newkeys: mode 1
[e][ssh] debug1: rekey after 4294967296 blocks
[e][ssh] debug1: SSH2_MSG_NEWKEYS sent
[e][ssh] debug1: expecting SSH2_MSG_NEWKEYS
[e][ssh] debug3: receive packet: type 21
[e][ssh] debug1: SSH2_MSG_NEWKEYS received
[e][ssh] debug2: set_newkeys: mode 0
[e][ssh] debug1: rekey after 4294967296 blocks
[e][ssh] debug2: key: alex@think (0x55784ec7f910), agent
[e][ssh] debug2: key: /tmp/tsa-key613344226/id_rsa (0x55784ec70020), explicit
[e][ssh] debug3: send packet: type 5
[o][tsa] {"timestamp":"1484772013.293787241","source":"tsa","message":"tsa.connection.handshake-failed","log_level":1,"data":{"error":"EOF","remote":"127.0.0.1:42512","session":"1"}}
[e][ssh] debug3: receive packet: type 20
[e][ssh] input_userauth_error: bad message during authentication: type 20

vito commented Jan 18, 2017

Here's ssh -vvv, if it helps:

[d][tsa] spawned /tmp/gexec_artifacts525385636/g608192691/tsa (pid: 31372)
[o][tsa] {"timestamp":"1484772013.263648510","source":"tsa","message":"tsa.listening","log_level":1,"data":{}}
[e][ssh] OpenSSH_7.4p1 Debian-5, OpenSSL 1.0.2j  26 Sep 2016
[e][ssh] debug1: Reading configuration data /etc/ssh/ssh_config
[e][ssh] debug1: /etc/ssh/ssh_config line 19: Applying options for *
[e][ssh] debug2: resolving "127.0.0.1" port 9801
[e][ssh] debug2: ssh_connect_direct: needpriv 0
[e][ssh] debug1: Connecting to 127.0.0.1 [127.0.0.1] port 9801.
[e][ssh] debug1: Connection established.
[e][ssh] debug1: identity file /tmp/tsa-key613344226/id_rsa type 1
[e][ssh] debug1: key_load_public: No such file or directory
[e][ssh] debug1: identity file /tmp/tsa-key613344226/id_rsa-cert type -1
[e][ssh] debug1: Enabling compatibility mode for protocol 2.0
[e][ssh] debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-5
[e][ssh] debug1: Remote protocol version 2.0, remote software version Go
[e][ssh] debug1: no match: Go
[e][ssh] debug2: fd 3 setting O_NONBLOCK
[e][ssh] debug1: Authenticating to 127.0.0.1:9801 as 'alex'
[e][ssh] debug3: put_host_port: [127.0.0.1]:9801
[e][ssh] debug3: hostkeys_foreach: reading file "/tmp/known-hosts154180302"
[e][ssh] debug3: record_hostkey: found key type RSA in file /tmp/known-hosts154180302:1
[e][ssh] debug3: load_hostkeys: loaded 1 keys from [127.0.0.1]:9801
[e][ssh] debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
[e][ssh] debug3: send packet: type 20
[e][ssh] debug1: SSH2_MSG_KEXINIT sent
[e][ssh] debug3: receive packet: type 20
[e][ssh] debug1: SSH2_MSG_KEXINIT received
[e][ssh] debug2: local client KEXINIT proposal
[e][ssh] 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
[e][ssh] debug2: host key algorithms: ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
[e][ssh] debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
[e][ssh] debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
[e][ssh] 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
[e][ssh] 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
[e][ssh] debug2: compression ctos: none,zlib@openssh.com,zlib
[e][ssh] debug2: compression stoc: none,zlib@openssh.com,zlib
[e][ssh] debug2: languages ctos:
[e][ssh] debug2: languages stoc:
[e][ssh] debug2: first_kex_follows 0
[e][ssh] debug2: reserved 0
[e][ssh] debug2: peer server KEXINIT proposal
[e][ssh] debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
[e][ssh] debug2: host key algorithms: ssh-rsa
[e][ssh] debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,arcfour256,arcfour128
[e][ssh] debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,arcfour256,arcfour128
[e][ssh] debug2: MACs ctos: hmac-sha2-256,hmac-sha1,hmac-sha1-96
[e][ssh] debug2: MACs stoc: hmac-sha2-256,hmac-sha1,hmac-sha1-96
[e][ssh] debug2: compression ctos: none
[e][ssh] debug2: compression stoc: none
[e][ssh] debug2: languages ctos:
[e][ssh] debug2: languages stoc:
[e][ssh] debug2: first_kex_follows 0
[e][ssh] debug2: reserved 0
[e][ssh] debug1: kex: algorithm: curve25519-sha256@libssh.org
[e][ssh] debug1: kex: host key algorithm: ssh-rsa
[e][ssh] debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
[e][ssh] debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
[e][ssh] debug3: send packet: type 30
[e][ssh] debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
[e][ssh] debug3: receive packet: type 31
[e][ssh] debug1: Server host key: ssh-rsa SHA256:QA5i5Qh2CpcrRbwiqYu+KIa66313opd5+KB9EFeqL9s
[e][ssh] debug3: put_host_port: [127.0.0.1]:9801
[e][ssh] debug3: put_host_port: [127.0.0.1]:9801
[e][ssh] debug3: hostkeys_foreach: reading file "/tmp/known-hosts154180302"
[e][ssh] debug3: record_hostkey: found key type RSA in file /tmp/known-hosts154180302:1
[e][ssh] debug3: load_hostkeys: loaded 1 keys from [127.0.0.1]:9801
[e][ssh] debug1: Host '[127.0.0.1]:9801' is known and matches the RSA host key.
[e][ssh] debug1: Found key in /tmp/known-hosts154180302:1
[e][ssh] debug3: send packet: type 21
[e][ssh] debug2: set_newkeys: mode 1
[e][ssh] debug1: rekey after 4294967296 blocks
[e][ssh] debug1: SSH2_MSG_NEWKEYS sent
[e][ssh] debug1: expecting SSH2_MSG_NEWKEYS
[e][ssh] debug3: receive packet: type 21
[e][ssh] debug1: SSH2_MSG_NEWKEYS received
[e][ssh] debug2: set_newkeys: mode 0
[e][ssh] debug1: rekey after 4294967296 blocks
[e][ssh] debug2: key: alex@think (0x55784ec7f910), agent
[e][ssh] debug2: key: /tmp/tsa-key613344226/id_rsa (0x55784ec70020), explicit
[e][ssh] debug3: send packet: type 5
[o][tsa] {"timestamp":"1484772013.293787241","source":"tsa","message":"tsa.connection.handshake-failed","log_level":1,"data":{"error":"EOF","remote":"127.0.0.1:42512","session":"1"}}
[e][ssh] debug3: receive packet: type 20
[e][ssh] input_userauth_error: bad message during authentication: type 20

@bradfitz bradfitz added this to the Unreleased milestone Jan 19, 2017

@hanwen

This comment has been minimized.

Show comment
Hide comment
@hanwen

hanwen Jan 19, 2017

Contributor

Looks like some flavor of #15066 reappearing (sigh)
curious; you'd think the user-auth code in SSH would be able a kex during auth.

Contributor

hanwen commented Jan 19, 2017

Looks like some flavor of #15066 reappearing (sigh)
curious; you'd think the user-auth code in SSH would be able a kex during auth.

@databus23

This comment has been minimized.

Show comment
Hide comment
@databus23

databus23 Jan 24, 2017

@hanwen I'm curious, is the information provided in this issue sufficient or is more information needed to assess the bug and ultimately fix it? I don't feel capable of fixing the problem on my own but I'm happy to provide more information/investigate if necessary.

@hanwen I'm curious, is the information provided in this issue sufficient or is more information needed to assess the bug and ultimately fix it? I don't feel capable of fixing the problem on my own but I'm happy to provide more information/investigate if necessary.

@hanwen

This comment has been minimized.

Show comment
Hide comment
@hanwen

hanwen Jan 24, 2017

Contributor

your info is not sufficient to be sure, but I suspect you could repro by adding sleep statements in the right places (see #15066). if you could that would be helpful.

I'm a bit swamped with normal work, but I'll try to have a look tonight.

Contributor

hanwen commented Jan 24, 2017

your info is not sufficient to be sure, but I suspect you could repro by adding sleep statements in the right places (see #15066). if you could that would be helpful.

I'm a bit swamped with normal work, but I'll try to have a look tonight.

@databus23

This comment has been minimized.

Show comment
Hide comment
@databus23

databus23 Jan 25, 2017

I tried creating a repro by sprinkling the handshake part of the golang ssh crypto lib with some sleeps but was not able make it work.

I'm also tried reproducing the original error that led to this issue being raised without luck so far.

Is my understanding of this issue correct that this is probaply caused because the openssh client receives a KEXINIT at a later stage in the handshake where the initial key exchange already took place?
And this is probably caused because both ends start the initial key exchange simultaneously and there is a race which one actually succeeds?

I tried creating a repro by sprinkling the handshake part of the golang ssh crypto lib with some sleeps but was not able make it work.

I'm also tried reproducing the original error that led to this issue being raised without luck so far.

Is my understanding of this issue correct that this is probaply caused because the openssh client receives a KEXINIT at a later stage in the handshake where the initial key exchange already took place?
And this is probably caused because both ends start the initial key exchange simultaneously and there is a race which one actually succeeds?

@hanwen

This comment has been minimized.

Show comment
Hide comment
@hanwen

hanwen Jan 25, 2017

Contributor

almost:

the first kex is special because it is mandatory, and I think the Go code has a race where the remote request for the first kex is somehow interpreted as a second kex, which then fires during the user authentication stage. (the word "handshake" is a bit overloaded here: there is the kex which has the dual purpose of setting up the secure channel and verifying the server identity, and there is authentication which verifies the user identity)

technically, OpenSSH is not following the spec, since it should be legal to request a kex during user authentication, but in practice it doesn't make sense, and is apparently not implemented. It suggests that OpenSSH doesn't have proper layering in their code (something which you can also tell from the zlib@openssh.org compression method, which switches on compression after the user auth succeeded).

Contributor

hanwen commented Jan 25, 2017

almost:

the first kex is special because it is mandatory, and I think the Go code has a race where the remote request for the first kex is somehow interpreted as a second kex, which then fires during the user authentication stage. (the word "handshake" is a bit overloaded here: there is the kex which has the dual purpose of setting up the secure channel and verifying the server identity, and there is authentication which verifies the user identity)

technically, OpenSSH is not following the spec, since it should be legal to request a kex during user authentication, but in practice it doesn't make sense, and is apparently not implemented. It suggests that OpenSSH doesn't have proper layering in their code (something which you can also tell from the zlib@openssh.org compression method, which switches on compression after the user auth succeeded).

@databus23

This comment has been minimized.

Show comment
Hide comment
@databus23

databus23 Jan 25, 2017

I'm still failing at creating a somewhat reliable repro here.

I managed to hit that bug once with ssh -v on the client side and golang.org/x/crypto/ssh.debugHandshake=true:

[e][ssh] OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
[e][ssh] debug1: Reading configuration data /etc/ssh/ssh_config
[e][ssh] debug1: /etc/ssh/ssh_config line 19: Applying options for *
[e][ssh] debug1: Connecting to 127.0.0.1 [127.0.0.1] port 9801.
[e][ssh] debug1: Connection established.
[e][ssh] debug1: permanently_set_uid: 0/0
[e][ssh] debug1: identity file /tmp/tsa-key684306212/id_rsa type 1
[e][ssh] debug1: key_load_public: No such file or directory
[e][ssh] debug1: identity file /tmp/tsa-key684306212/id_rsa-cert type -1
[e][ssh] debug1: Enabling compatibility mode for protocol 2.0
[e][ssh] debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
[e][ssh] debug1: Remote protocol version 2.0, remote software version Go
[e][ssh] debug1: no match: Go
[e][ssh] debug1: Authenticating to 127.0.0.1:9801 as 'root'
[e][ssh] debug1: SSH2_MSG_KEXINIT sent
[e][tsa] 2017/01/25 15:54:08 server got *ssh.kexInitMsg &{[197 213 16 41 48 24 167 162 134 173 18 2 28 114 65 78] [curve25519-sha256@libssh.org ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group-exchange-sha256 diffie-hellman-group-exchange-sha1 diffie-hellman-group14-sha1 ext-info-c] [ssh-rsa-cert-v01@openssh.com rsa-sha2-512 rsa-sha2-256 ssh-rsa ecdsa-sha2-nistp256-cert-v01@openssh.com ecdsa-sha2-nistp384-cert-v01@openssh.com ecdsa-sha2-nistp521-cert-v01@openssh.com ssh-ed25519-cert-v01@openssh.com ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-ed25519] [chacha20-poly1305@openssh.com aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com aes256-gcm@openssh.com aes128-cbc aes192-cbc aes256-cbc 3des-cbc] [chacha20-poly1305@openssh.com aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com aes256-gcm@openssh.com aes128-cbc aes192-cbc aes256-cbc 3des-cbc] [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] [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] [none zlib@openssh.com zlib] [none zlib@openssh.com zlib] [] [] false 0} (<nil>)
[e][tsa] 2017/01/25 15:54:08 server sent *ssh.kexInitMsg &{[41 82 56 208 44 141 156 205 128 122 190 155 141 74 50 84] [curve25519-sha256@libssh.org ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group14-sha1 diffie-hellman-group1-sha1] [ssh-rsa] [aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com arcfour256 arcfour128] [aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com arcfour256 arcfour128] [hmac-sha2-256 hmac-sha1 hmac-sha1-96] [hmac-sha2-256 hmac-sha1 hmac-sha1-96] [none] [none] [] [] false 0} (<nil>)
[e][tsa] 2017/01/25 15:54:08 server entered key exchange
[e][ssh] debug1: SSH2_MSG_KEXINIT received
[e][ssh] debug1: kex: algorithm: curve25519-sha256@libssh.org
[e][ssh] debug1: kex: host key algorithm: ssh-rsa
[e][ssh] debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
[e][ssh] debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
[e][ssh] debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
[e][ssh] debug1: Server host key: ssh-rsa SHA256:yFsvolxTqYqUVEZeWPO7/8WxXT/L+cNHhH2xtYFf8JE
[e][ssh] debug1: Host '[127.0.0.1]:9801' is known and matches the RSA host key.
[e][ssh] debug1: Found key in /tmp/known-hosts569235609:1
[e][ssh] debug1: rekey after 4294967296 blocks
[e][ssh] debug1: SSH2_MSG_NEWKEYS sent
[e][ssh] debug1: expecting SSH2_MSG_NEWKEYS
[e][tsa] 2017/01/25 15:54:08 server sent *ssh.kexInitMsg &{[218 164 69 121 146 194 66 107 252 76 130 170 132 29 4 127] [curve25519-sha256@libssh.org ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group14-sha1 diffie-hellman-group1-sha1] [ssh-rsa] [aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com arcfour256 arcfour128] [aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com arcfour256 arcfour128] [hmac-sha2-256 hmac-sha1 hmac-sha1-96] [hmac-sha2-256 hmac-sha1 hmac-sha1-96] [none] [none] [] [] false 0} (<nil>)
[e][tsa] 2017/01/25 15:54:08 server exited key exchange (first true), err <nil>
[e][ssh] debug1: rekey after 4294967296 blocks
[e][ssh] debug1: SSH2_MSG_NEWKEYS received
[e][tsa] 2017/01/25 15:54:08 server got *ssh.serviceRequestMsg &{ssh-userauth} (<nil>)
[e][ssh] input_userauth_error: bad message during authentication: type 20

databus23 commented Jan 25, 2017

I'm still failing at creating a somewhat reliable repro here.

I managed to hit that bug once with ssh -v on the client side and golang.org/x/crypto/ssh.debugHandshake=true:

[e][ssh] OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
[e][ssh] debug1: Reading configuration data /etc/ssh/ssh_config
[e][ssh] debug1: /etc/ssh/ssh_config line 19: Applying options for *
[e][ssh] debug1: Connecting to 127.0.0.1 [127.0.0.1] port 9801.
[e][ssh] debug1: Connection established.
[e][ssh] debug1: permanently_set_uid: 0/0
[e][ssh] debug1: identity file /tmp/tsa-key684306212/id_rsa type 1
[e][ssh] debug1: key_load_public: No such file or directory
[e][ssh] debug1: identity file /tmp/tsa-key684306212/id_rsa-cert type -1
[e][ssh] debug1: Enabling compatibility mode for protocol 2.0
[e][ssh] debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
[e][ssh] debug1: Remote protocol version 2.0, remote software version Go
[e][ssh] debug1: no match: Go
[e][ssh] debug1: Authenticating to 127.0.0.1:9801 as 'root'
[e][ssh] debug1: SSH2_MSG_KEXINIT sent
[e][tsa] 2017/01/25 15:54:08 server got *ssh.kexInitMsg &{[197 213 16 41 48 24 167 162 134 173 18 2 28 114 65 78] [curve25519-sha256@libssh.org ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group-exchange-sha256 diffie-hellman-group-exchange-sha1 diffie-hellman-group14-sha1 ext-info-c] [ssh-rsa-cert-v01@openssh.com rsa-sha2-512 rsa-sha2-256 ssh-rsa ecdsa-sha2-nistp256-cert-v01@openssh.com ecdsa-sha2-nistp384-cert-v01@openssh.com ecdsa-sha2-nistp521-cert-v01@openssh.com ssh-ed25519-cert-v01@openssh.com ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-ed25519] [chacha20-poly1305@openssh.com aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com aes256-gcm@openssh.com aes128-cbc aes192-cbc aes256-cbc 3des-cbc] [chacha20-poly1305@openssh.com aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com aes256-gcm@openssh.com aes128-cbc aes192-cbc aes256-cbc 3des-cbc] [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] [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] [none zlib@openssh.com zlib] [none zlib@openssh.com zlib] [] [] false 0} (<nil>)
[e][tsa] 2017/01/25 15:54:08 server sent *ssh.kexInitMsg &{[41 82 56 208 44 141 156 205 128 122 190 155 141 74 50 84] [curve25519-sha256@libssh.org ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group14-sha1 diffie-hellman-group1-sha1] [ssh-rsa] [aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com arcfour256 arcfour128] [aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com arcfour256 arcfour128] [hmac-sha2-256 hmac-sha1 hmac-sha1-96] [hmac-sha2-256 hmac-sha1 hmac-sha1-96] [none] [none] [] [] false 0} (<nil>)
[e][tsa] 2017/01/25 15:54:08 server entered key exchange
[e][ssh] debug1: SSH2_MSG_KEXINIT received
[e][ssh] debug1: kex: algorithm: curve25519-sha256@libssh.org
[e][ssh] debug1: kex: host key algorithm: ssh-rsa
[e][ssh] debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
[e][ssh] debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
[e][ssh] debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
[e][ssh] debug1: Server host key: ssh-rsa SHA256:yFsvolxTqYqUVEZeWPO7/8WxXT/L+cNHhH2xtYFf8JE
[e][ssh] debug1: Host '[127.0.0.1]:9801' is known and matches the RSA host key.
[e][ssh] debug1: Found key in /tmp/known-hosts569235609:1
[e][ssh] debug1: rekey after 4294967296 blocks
[e][ssh] debug1: SSH2_MSG_NEWKEYS sent
[e][ssh] debug1: expecting SSH2_MSG_NEWKEYS
[e][tsa] 2017/01/25 15:54:08 server sent *ssh.kexInitMsg &{[218 164 69 121 146 194 66 107 252 76 130 170 132 29 4 127] [curve25519-sha256@libssh.org ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group14-sha1 diffie-hellman-group1-sha1] [ssh-rsa] [aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com arcfour256 arcfour128] [aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com arcfour256 arcfour128] [hmac-sha2-256 hmac-sha1 hmac-sha1-96] [hmac-sha2-256 hmac-sha1 hmac-sha1-96] [none] [none] [] [] false 0} (<nil>)
[e][tsa] 2017/01/25 15:54:08 server exited key exchange (first true), err <nil>
[e][ssh] debug1: rekey after 4294967296 blocks
[e][ssh] debug1: SSH2_MSG_NEWKEYS received
[e][tsa] 2017/01/25 15:54:08 server got *ssh.serviceRequestMsg &{ssh-userauth} (<nil>)
[e][ssh] input_userauth_error: bad message during authentication: type 20
@databus23

This comment has been minimized.

Show comment
Hide comment
@databus23

databus23 Jan 26, 2017

@hanwen I created a repro for this error: https://github.com/databus23/golang-issue-18711

Unfortunately I wasn't able to trigger this bug in a single run by adding sleep statements in the right places but instead went for a test case the loops until the error occurs.

At least on my computer this usually triggers the error with 30 seconds.

Some observations I made in the process:

  • it does not seem to happen with the OpenSSH client on macOS Sierra (OpenSSH_7.3p1)
  • I hit the error on debian jessie and ubuntu 16.04 (OpenSSH_6.7p1 & OpenSSH_7.2p2) and from the above comment by @vito it seems at least OpenSSH_7.4p1 is affected as well
  • Its quite time sensitive, adding -v's to the ssh client invocation already seems to reduce the chances of triggering the bug. I assume thats because the client spends some time printing the debug statements.

databus23 commented Jan 26, 2017

@hanwen I created a repro for this error: https://github.com/databus23/golang-issue-18711

Unfortunately I wasn't able to trigger this bug in a single run by adding sleep statements in the right places but instead went for a test case the loops until the error occurs.

At least on my computer this usually triggers the error with 30 seconds.

Some observations I made in the process:

  • it does not seem to happen with the OpenSSH client on macOS Sierra (OpenSSH_7.3p1)
  • I hit the error on debian jessie and ubuntu 16.04 (OpenSSH_6.7p1 & OpenSSH_7.2p2) and from the above comment by @vito it seems at least OpenSSH_7.4p1 is affected as well
  • Its quite time sensitive, adding -v's to the ssh client invocation already seems to reduce the chances of triggering the bug. I assume thats because the client spends some time printing the debug statements.
@databus23

This comment has been minimized.

Show comment
Hide comment
@databus23

databus23 Jan 26, 2017

Reverting golang.org/x/crypto to before golang/crypto@2e74c77 seems to make the problem go away. At least the repro doesn't trigger it anymore.

Reverting golang.org/x/crypto to before golang/crypto@2e74c77 seems to make the problem go away. At least the repro doesn't trigger it anymore.

@belak

This comment has been minimized.

Show comment
Hide comment
@belak

belak Jan 28, 2017

We've also run into a different issue during the kex/handshake.

panic: ssh: no key material for msgNewKeys
goroutine 31868301 [running]:
panic(0x7ce020, 0xc42414c260)
/usr/local/go/src/runtime/panic.go:500 +0x1a1
bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh.(*connectionState).writePacket(0xc422774068, 0xc4218a8480, 0xa90080, 0xc42000c2d0, 0xc420010790, 0x9, 0x9, 0x0, 0x0)
/go/src/bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh/transport.go:163 +0x226
bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh.(*transport).writePacket(0xc422774000, 0xc420010790, 0x9, 0x9, 0x0, 0x0)
/go/src/bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh/transport.go:144 +0x77
bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh.(*handshakeTransport).pushPacket(0xc422326140, 0xc420010790, 0x9, 0x9, 0x0, 0x0)
/go/src/bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh/handshake.go:211 +0x51
bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh.(*handshakeTransport).kexLoop(0xc422326140)
/go/src/bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh/handshake.go:291 +0x303
created by bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh.newServerTransport
/go/src/bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh/handshake.go:126 +0x227

This is on a server running on golang/crypto@41d678d

We were previously running golang/crypto@ca7e7f1

belak commented Jan 28, 2017

We've also run into a different issue during the kex/handshake.

panic: ssh: no key material for msgNewKeys
goroutine 31868301 [running]:
panic(0x7ce020, 0xc42414c260)
/usr/local/go/src/runtime/panic.go:500 +0x1a1
bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh.(*connectionState).writePacket(0xc422774068, 0xc4218a8480, 0xa90080, 0xc42000c2d0, 0xc420010790, 0x9, 0x9, 0x0, 0x0)
/go/src/bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh/transport.go:163 +0x226
bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh.(*transport).writePacket(0xc422774000, 0xc420010790, 0x9, 0x9, 0x0, 0x0)
/go/src/bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh/transport.go:144 +0x77
bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh.(*handshakeTransport).pushPacket(0xc422326140, 0xc420010790, 0x9, 0x9, 0x0, 0x0)
/go/src/bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh/handshake.go:211 +0x51
bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh.(*handshakeTransport).kexLoop(0xc422326140)
/go/src/bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh/handshake.go:291 +0x303
created by bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh.newServerTransport
/go/src/bitbucket.org/bitbucket/conker/vendor/golang.org/x/crypto/ssh/handshake.go:126 +0x227

This is on a server running on golang/crypto@41d678d

We were previously running golang/crypto@ca7e7f1

@databus23

This comment has been minimized.

Show comment
Hide comment
@databus23

databus23 Jan 30, 2017

@belak While your problem also happens at the handshake phase it seems unrelated to the issue described here. This issue has been handled in https://go-review.googlesource.com/#/c/35851/ and was merged as golang/crypto@6fb0668.
If you problem persists I suggest you open a new issue for it.

@belak While your problem also happens at the handshake phase it seems unrelated to the issue described here. This issue has been handled in https://go-review.googlesource.com/#/c/35851/ and was merged as golang/crypto@6fb0668.
If you problem persists I suggest you open a new issue for it.

@databus23

This comment has been minimized.

Show comment
Hide comment
@databus23

databus23 Jan 30, 2017

@hanwen Thanks again for taking this. I can confirm that with the merged fix, I can't reproduce the issue anymore.

@hanwen Thanks again for taking this. I can confirm that with the merged fix, I can't reproduce the issue anymore.

@databus23 databus23 referenced this issue in concourse/concourse Jan 30, 2017

Merged

Bump golang.org/x/crypto to fix ssh deadlock #900

@hanwen

This comment has been minimized.

Show comment
Hide comment
@hanwen

hanwen Jan 30, 2017

Contributor

opened issue 18850 for the msgNewKeys problem.

Contributor

hanwen commented Jan 30, 2017

opened issue 18850 for the msgNewKeys problem.

@hanwen

This comment has been minimized.

Show comment
Hide comment
@hanwen

hanwen Jan 30, 2017

Contributor

issue #18850 , that is.

Contributor

hanwen commented Jan 30, 2017

issue #18850 , that is.

@hanwen hanwen closed this Jan 30, 2017

@vito

This comment has been minimized.

Show comment
Hide comment
@vito

vito Jan 30, 2017

Looking good so far in my pipeline, thanks again!

vito commented Jan 30, 2017

Looking good so far in my pipeline, thanks again!

@immesys

This comment has been minimized.

Show comment
Hide comment
@immesys

immesys Feb 2, 2017

Hi, I am still hitting this issue, even though I have the golang/x/crypto commit mentioned above in my code. (I am at dc137beb6cce2043e). OpenSSH fails to connect with:

... snip ...
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/immesys/.ssh/id_rsa (0x56917eb1c120), agent
debug2: key: /home/immesys/.ssh/id_dsa ((nil))
debug2: key: /home/immesys/.ssh/id_ecdsa ((nil))
debug2: key: /home/immesys/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 20
input_userauth_error: bad message during authentication: type 20

immesys commented Feb 2, 2017

Hi, I am still hitting this issue, even though I have the golang/x/crypto commit mentioned above in my code. (I am at dc137beb6cce2043e). OpenSSH fails to connect with:

... snip ...
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/immesys/.ssh/id_rsa (0x56917eb1c120), agent
debug2: key: /home/immesys/.ssh/id_dsa ((nil))
debug2: key: /home/immesys/.ssh/id_ecdsa ((nil))
debug2: key: /home/immesys/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 20
input_userauth_error: bad message during authentication: type 20

@carazzim0 carazzim0 referenced this issue in gogs/gogs Feb 4, 2017

Closed

ssh_exchange_identification: read: Connection reset by peer #4081

2 of 6 tasks complete
@dgellow

This comment has been minimized.

Show comment
Hide comment
@dgellow

dgellow Feb 5, 2017

Same as @immesys.

When it fails

...
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /Users/sam/.ssh/id_rsa (0x7fd295d15f30)
debug2: key: /Users/sam/.ssh/id_dsa (0x0)
debug2: key: /Users/sam/.ssh/id_ecdsa (0x0)
debug2: key: /Users/sam/.ssh/id_ed25519 (0x0)
debug3: send packet: type 5
debug3: receive packet: type 20
input_userauth_error: bad message during authentication: type 20

When it works

...
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /Users/sam/.ssh/id_rsa (0x7fa7b360f510)
debug2: key: /Users/sam/.ssh/id_dsa (0x0)
debug2: key: /Users/sam/.ssh/id_ecdsa (0x0)
debug2: key: /Users/sam/.ssh/id_ed25519 (0x0)
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received

dgellow commented Feb 5, 2017

Same as @immesys.

When it fails

...
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /Users/sam/.ssh/id_rsa (0x7fd295d15f30)
debug2: key: /Users/sam/.ssh/id_dsa (0x0)
debug2: key: /Users/sam/.ssh/id_ecdsa (0x0)
debug2: key: /Users/sam/.ssh/id_ed25519 (0x0)
debug3: send packet: type 5
debug3: receive packet: type 20
input_userauth_error: bad message during authentication: type 20

When it works

...
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /Users/sam/.ssh/id_rsa (0x7fa7b360f510)
debug2: key: /Users/sam/.ssh/id_dsa (0x0)
debug2: key: /Users/sam/.ssh/id_ecdsa (0x0)
debug2: key: /Users/sam/.ssh/id_ed25519 (0x0)
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
@immesys

This comment has been minimized.

Show comment
Hide comment
@immesys

immesys Feb 17, 2017

Can we get this issue reopened? @hanwen I believe is the maintainer of this part of the code.

immesys commented Feb 17, 2017

Can we get this issue reopened? @hanwen I believe is the maintainer of this part of the code.

@bradfitz

This comment has been minimized.

Show comment
Hide comment
@bradfitz

bradfitz Feb 18, 2017

Member

Sure. Reopening for @hanwen.

Member

bradfitz commented Feb 18, 2017

Sure. Reopening for @hanwen.

@immesys

This comment has been minimized.

Show comment
Hide comment
@immesys

immesys Feb 18, 2017

Although I will say that with 641ab6b32 I have not seen this again. If someone can confirm that in the ~10 commits that have happened in the past two weeks that one of those could plausibly have fixed this problem (with 641ab6b32 being the one that looks most likely) then I am happy to leave this closed.

immesys commented Feb 18, 2017

Although I will say that with 641ab6b32 I have not seen this again. If someone can confirm that in the ~10 commits that have happened in the past two weeks that one of those could plausibly have fixed this problem (with 641ab6b32 being the one that looks most likely) then I am happy to leave this closed.

@dgellow

This comment has been minimized.

Show comment
Hide comment
@dgellow

dgellow Feb 18, 2017

I cannot reproduce after an update 👍

dgellow commented Feb 18, 2017

I cannot reproduce after an update 👍

@bradfitz bradfitz closed this Feb 18, 2017

@keymon keymon referenced this issue in cloudfoundry/diego-ssh Mar 17, 2017

Closed

Not possible to transfer more than ~1GB with sshd #31

@golang golang locked and limited conversation to collaborators Feb 18, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.