Hide Forgot
[root@turmoil /root]# dd if=/dev/zero bs=1k count=100 | wc 100+0 records in 100+0 records out 0 0 102400 [root@turmoil /root]# ssh localhost dd if=/dev/zero bs=1k count=100 | wc Password: 0 0 65536 Um.. (this was from a tip-off on linux-kernel)
Oh yeah, this is with: openssh-2.3.0p1-10 openssh-server-2.3.0p1-10 openssh-clients-2.3.0p1-10
This defect is considered MUST-FIX for Florence Gold release
This is caused by the same thing as #21607. This can be solved by reverting a fix or upgrading to latest snapshots, but the other problem with hanging connections (#19837) (sleep10& exit; service httpd restart, etc.) will then come up. It's one or the other, unless someone figures a way to fix this properly :-(. There's info about these issues in the reports I think, as well as current OpenSSH CVS TODO list.
*** Bug 24691 has been marked as a duplicate of this bug. ***
Note: there's a workaround for bash by Damien Miller for #19837: shopt -s huponexit
In addition to the above, I'm getting the following output with openssh-2.3.0p1-14 (logged in as user test across the network): [test@localhost test]$ ssh localhost dd if=/dev/zero bs=1k count=100 | wc Password: select: Bad file descriptor 0 0 0 The complaint about select isn't listed above
Brock, do you have a funky .bashrc or .bash_profile which prints out stuff when you log in? Or anything that'd generate output in stderr?
2.5.1p1 should show up in Raw Hide soon.
No, the user test doesn't have anything unusual in .bashrc, .bash_profile, or any similar startup files. In fact, they're unmodified from a stock install, so they should be identical to the copies in /etc/skel (the user test was created after system installation of the beta. Double-checking the .bashrc and other files (by sourcing them as the logged-in user) didn't reveal any output to stderr. I'm going to begin re-testing with the latest tree (qa0221.0) today, which includes the new openssh-2.5.1p1-1.
I highly suspect login scriptlet wackiness is to blame here. The closing-too-soon problem in 2.3.0p1 is correctly reverted in 2.5.1p1, but we get the hang-on-exit (which affects rsh, too) when we do that.
I'm beginning to suspect that this is endemic to the rsh and friends work, because the hang appears both on an OpenBSD server running OpenSSH 2.5.1, and on a Linux box using regular unencrypted rsh.
*** Bug 32808 has been marked as a duplicate of this bug. ***
This is fixed as the patch that caused this regression was removed long ago.