Hide Forgot
OpenSSH cannot return to the local shell if running a background job on the remote machine. This problem is very easy to reproduce. Between 2 RH7 machines, login via OpenSSH. Type "sleep 30 &" and logout. Your shell on the local machine will not appear until the 30s has transpired. Now, you can imagine how annoying this is when running a 2 day calculation! PS: another issue I've noticed with OpenSSH on RH7 is that it appears the "KeepAlive" directive is not being honored. I keep getting openssh sessions cut short by my firewall's timeout period, this never happened with other OpenSSH's I've installed. Okay, should I enter this as a seperate bug?
This evens happens with X forwarding turned off and with backgrounded jobs run through nohup.
Here are few links which may be useful in debugging this problem. The base link to the archives for the OpenSSH developer mailing list: http://marc.theaimsgroup.com/?l=openssh-unix-dev&r=1&w=2 A thread within this archive that somewhat mentions this very problem (from Sept 27): http://marc.theaimsgroup.com/?t=97007746200005&w=2&r=1 A quick summary of the above thread is: 1) it appears it only appears when using ssh protocol 2 2) this bug also appeared for someone using the ssh client from ssh.com to an openssh server. So, it appears to not be client related...? 3) this bug appears not to be linux related b/c it has affected someone connecting between Solaris and IRIX.
This has been fixed in the latest OpenSSH snapshots. OpenSSH 2.3.0p1 should be out soonish (<week), but I'm not sure if this warrants an errata release.
Thanks for the update, it is great to hear that this has been fixed by the openssh people. Now, as for whether or not this is worthy of an errata update, I would argue that it is. I (and many others) do most of my (their) remote administration tasks via ssh, and I am constantly having to kill shell processes b/c of this bug. For example, starting a /etc/rc.d/init.d process triggers this bug, such as starting apache or the ftp daemon. How is RH7 supposed to be taken seriously for a "remotely administrat-able" server environment with this bug? Now, one other point to ponder. What happens to intermediate shells when you piggy-back through computers using ssh and this bug triggers? For instance, while on computer #1, I ssh to computer #2, then ssh from #2 to computer #3. While logging out of #3 my shell locks up. What happens to the shell on computer #2? This is a very common situation with through-firewall system admin. What a nightmare! Now, imagine you have many, many machines.... (this is my situation). Clearly, regardless of what RH decides to do, I will be upgrading to 2.3.0p1 when it comes out. Thanks again pekkas for the news.
I also strongly second the request for an errata update, as there are some more outstanding bugfixes with different severity/impact are pending. I specially recall problems with UseLogin.
All known problems with UseLogin I'm aware of should have been fixed in OpenSSH 2.2.0p1 errata release already. There are, of course, other issues fixed.. :-)
FWIW, OpenSSH-2.3.0p1 was released today.
http://OpenSSH Security Advisory linuxtoday.com/news_story.php3?ltsn=2000-11-13-024-04-SC
oops, that URL was supposed to be: http://linuxtoday.com/news_story.php3?ltsn=2000-11-13-024-04-SC
This vulnerability has it's own Bug ID #20805 :-]
This bug can be marked resolved, as the recent update, openssh-2.2.0p1-5.i386.rpm, solves the problem. I seem to not have the ability to do this myself, or I would.
...oops again, the openssh update that solves this bug was v2.3.0, not v2.2.0... sorry...
OK; marking RESOLVED/ERRATA
BTW... shouldn't http://www.redhat.com/support/errata/RHSA-2000-111.html include this bug ID as fixed?