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

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

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

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

vito opened this issue Jan 18, 2017 · 21 comments
Assignees
Milestone

Comments

@vito
Copy link

@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
Copy link
Author

@vito 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
Copy link
Contributor

@hanwen 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
Copy link

@databus23 databus23 commented 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
Copy link
Contributor

@hanwen 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
Copy link

@databus23 databus23 commented 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?

@hanwen
Copy link
Contributor

@hanwen 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
Copy link

@databus23 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
Copy link

@databus23 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
Copy link

@databus23 databus23 commented 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.

@belak
Copy link

@belak 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
Copy link

@databus23 databus23 commented 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.

@databus23
Copy link

@databus23 databus23 commented 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
Copy link
Contributor

@hanwen hanwen commented Jan 30, 2017

opened issue 18850 for the msgNewKeys problem.

@hanwen
Copy link
Contributor

@hanwen hanwen commented Jan 30, 2017

issue #18850 , that is.

@hanwen hanwen closed this Jan 30, 2017
@vito
Copy link
Author

@vito vito commented Jan 30, 2017

Looking good so far in my pipeline, thanks again!

@immesys
Copy link

@immesys 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 dc137be). 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
@dgellow
Copy link

@dgellow 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
Copy link

@immesys immesys commented Feb 17, 2017

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

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Feb 18, 2017

Sure. Reopening for @hanwen.

@immesys
Copy link

@immesys immesys commented Feb 18, 2017

Although I will say that with 641ab6b 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 641ab6b being the one that looks most likely) then I am happy to leave this closed.

@dgellow
Copy link

@dgellow dgellow commented Feb 18, 2017

I cannot reproduce after an update 👍

@bradfitz bradfitz closed this Feb 18, 2017
@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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.