Connection breaks on non-encrypted large transfers
robdewit opened this issue · 3 comments
Hi,
I've tried the new commit for 7.2p2 (6c21335), but the ssh connection breaks when the connection is rekeyed. Apparently after 1GB of data there is a rekey event and the client structure with available methods is corrupted.
Reproduceable:
`pwd`/sshd -p 2022 -ddddd > sshd.out 2>&1 &
dd if=/dev/zero bs=1M count=2048 | ssh -oNoneEnabled=yes -oNoneSwitch=yes -vvvvv -p 2022 0 "cat >/dev/null" > ssh.out 2>&1
==== output ssh:
debug2: channel 0: rcvd adjust 114688
debug2: tcpwinsz: 1061808 for connection: 3
debug2: tcpwinsz: 1061808 for connection: 3
debug2: tcpwinsz: 1061808 for connection: 3
debug3: ssh_packet_send2: rekex triggered
debug1: enqueue packet: 94
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug1: rekeying in progress
debug2: channel 0: rcvd adjust 114688
debug1: rekeying in progress
debug2: channel 0: rcvd adjust 114688
debug1: rekeying in progress
debug2: channel 0: rcvd adjust 114688
debug1: rekeying in progress
debug2: channel 0: rcvd adjust 114688
debug1: rekeying in progress
debug2: channel 0: rcvd adjust 114688
debug1: rekeying in progress
debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug3: fd 2 is not O_NONBLOCK
Connection to 0 closed by remote host.
Transferred: sent 1073877680, received 192228 bytes, in 20.7 seconds
Bytes per second: sent 51905161.8, received 9291.2
debug1: Exit status -1
==== end
==== output sshd.out
debug2: tcpwinsz: 1135260 for connection: 3
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug1: AUTH STATE IS 1
debug2: local server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,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,none,none
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,none,none
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
debug2: peer client KEXINIT proposal
debug2: KEX algorithms:
debug2: host key algorithms:
debug2: ciphers ctos: none
debug2: ciphers stoc: none
debug2: MACs ctos:
debug2: MACs stoc:
debug2: compression ctos:
debug2: compression stoc:
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: (no match)
Unable to negotiate with 127.0.0.1 port 45626: no matching key exchange method found. Their offer:
debug1: do_cleanup
==== end
I've got another report on this as well. I'll be looking into this as
soon as possible. There was a pretty big shift in the code from 7.1 to
7.2. What I think is happening is that the proposals are reset to some
sort of default when rekeying happens and this overrides the explicit
definition that we use for the none cipher switch. The dirty way to do
it would just be squelch rekeying if the none cipher is set (as rekeying
to none is pointless). However, I'd like to understand this in the
context of the changes made to the code base.
As a note, this commit probably shouldn't have happened. I didn't have
the time to fully vet it.
On 5/25/16 8:00 AM, Rob de Wit wrote:
Hi,
I've tried the new commit for 7.2p2 (6c21335
6c21335),
but the ssh connection breaks when the connection is rekeyed. Apparently
after 1GB of data there is a rekey event and the client structure with
available methods is corrupted.Reproduceable:
|
pwd/sshd -p 2022 -ddddd > sshd.out 2>&1 & dd if=/dev/zero bs=1M
count=2048 | ssh -oNoneEnabled=yes -oNoneSwitch=yes -vvvvv -p 2022 0
"cat >/dev/null" > ssh.out 2>&1 |==== output ssh:
|debug2: channel 0: rcvd adjust 114688 debug2: tcpwinsz: 1061808 for
connection: 3 debug2: tcpwinsz: 1061808 for connection: 3 debug2:
tcpwinsz: 1061808 for connection: 3 debug3: ssh_packet_send2: rekex
triggered debug1: enqueue packet: 94 debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent debug1: rekeying in progress debug2:
channel 0: rcvd adjust 114688 debug1: rekeying in progress debug2:
channel 0: rcvd adjust 114688 debug1: rekeying in progress debug2:
channel 0: rcvd adjust 114688 debug1: rekeying in progress debug2:
channel 0: rcvd adjust 114688 debug1: rekeying in progress debug2:
channel 0: rcvd adjust 114688 debug1: rekeying in progress debug3: send
packet: type 1 debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open: #0
client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1) debug1: fd 0 clearing
O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK debug3: fd 2 is not
O_NONBLOCK Connection to 0 closed by remote host. Transferred: sent
1073877680, received 192228 bytes, in 20.7 seconds Bytes per second:
sent 51905161.8, received 9291.2 debug1: Exit status -1 |==== end
==== output sshd.out
|debug2: tcpwinsz: 1135260 for connection: 3 debug3: receive packet: type
20 debug1: SSH2_MSG_KEXINIT received debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent debug1: AUTH STATE IS 1 debug2: local
server KEXINIT proposal debug2: KEX algorithms:
curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms:
ssh-rsa,rsa-sha2-512,rsa-sha2-256,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,none,none
debug2: ciphers stoc:
chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,none,none
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 debug2: peer client
KEXINIT proposal debug2: KEX algorithms: debug2: host key algorithms:
debug2: ciphers ctos: none debug2: ciphers stoc: none debug2: MACs ctos:
debug2: MACs stoc: debug2: compression ctos: debug2: compression stoc:
debug2: languages ctos: debug2: languages stoc: debug2:
first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: (no
match) Unable to negotiate with 127.0.0.1 port 45626: no matching key
exchange method found. Their offer: debug1: do_cleanup |==== end
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#5
Thanks for your reply, if I can be of any help, please let me know.
This issue has been corrected. The problem was a change in the way that the myproposal array was being populated and preserved by OpenSSH. It used to be maintained from one rekex to another. However, they now clear the array and repopulated it from myproposal_default. So I needed to memcpy myproposal_default to myproposal before forcing the none cipher rekeying.