Bug 354113 – net-misc/openssh-5.8_p1[hpn] freeze when using ControlMaster and huge output

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Diego Elio Pettenò (RETIRED) 2011-02-08 17:37:28 UTC]

I've been able to reproduce this multiple times so I think I can say that something is wrong, both with a real box and with a VM.

Setup:

 yamato -> headless box with sshd 5.8 running (doesn't matter whether this one is hpn or not)
 client -> box with ssh client 5.8 with hpn

Connection between the two boxes: local gigabit or virtio/tun over yamato's br0.

client's .ssh/config <<EOF

ControlPath ~/.ssh/master-%r@%h:%p
Compression yes

Host yamato
ControlMaster auto
ControlPersist yes
ForwardAgent yes

EOF

Open two ssh sessions from client→yamato; in the first run a long command, like emerge --sync, dmesg, or "dd if=/dev/zero count=10M | hexdump -v", try to use the second.

After no even a minute, both sessions are completely frozen client-side.

[Comment 1 Diego Elio Pettenò (RETIRED) 2011-02-08 17:39:28 UTC]

FWIW a "slow" amount of data doesn't cut it:

while true; do sleep 2; date; done

is running for over three minutes now.

[Comment 2 SpanKY 2011-02-10 02:01:00 UTC]

try the workaround in the older ebuilds:
    # The AES-CTR multithreaded variant is temporarily broken, and
    # causes random hangs when combined with the -f switch of ssh.
    # To avoid this, we change the internal table to use the non-multithread
    # version for the meantime.
    sed -i \
        -e '/aes...-ctr.*SSH_CIPHER_SSH2/s,evp_aes_ctr_mt,evp_aes_128_ctr,' \
        cipher.c || die

if that doesnt help, report the issue to the hpn peeps [e-mail] ... not like any of us have done development on the hpn code base ...

[Comment 3 Robin Johnson 2011-02-10 02:25:12 UTC]

Actually, I have done dev on the HPN codebase, that's why I support it.
Why was the AES-CTR sed removed? It is STILL needed. I'm going to restore it and revbump.

[Comment 4 Robin Johnson 2011-02-10 02:32:57 UTC]

5.8_p1-r1 bump in the tree with it.
Also in 5.7_p1-r1 and 5.8_p1.

[Comment 5 SpanKY 2011-02-10 02:44:10 UTC]

you need to put real details into the comment (upstream URLs, what is broken, how to test it is fixed, etc...).  using "temporarily broken" when the comment dates back literally years isnt going to fly, and neither is "Do NOT remove this in new versions".  the simple test you alluded to in there passes fine for me.

[Comment 6 Robin Johnson 2011-02-10 03:07:46 UTC]

Directly from the upstream page:
Additionally, the MT-AES-CTR mode cipher replaces the default ST-AES-CTR mode cipher. Be aware that if the client process is forked using the -f command line option the process will hang as the parent thread gets 'divorced' from the key generation threads. This issue will be resolved as soon as possible.

That paragraph has been in place for nearly 2 years now at upstream. I can still reproduce it with -f trivially. Here's your testcase:
SOMEHOST=...
# working ciphers
for cipher in 3des-cbc aes{128,192,256}-cbc arcfour{,128,256} blowfish-cbc cast128-cbc ; do
echo === $cipher ; ssh -c $cipher  -f $SOMEHOST 'dd if=/dev/zero bs=1M count=1' | dd of=/tmp/ssh-ciphertest-$cipher bs=1M 
done ;
# broken AES-CTR-MT
for cipher in aes{128,192,252}-ctr ; do
echo === $cipher ; ssh -c $cipher  -f $SOMEHOST 'dd if=/dev/zero bs=1M count=1' | dd of=/tmp/ssh-ciphertest-$cipher bs=1M 
done ;

[Comment 7 SpanKY 2011-02-10 03:13:05 UTC]

that is really only useful if the comment linked to your new information.  and i see now you've done just that.