Red Hat Bugzilla – Bug 19837
logout w/ openssh and background job locks up
Last modified: 2008-05-01 11:37:59 EDT
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
This evens happens with X forwarding turned off and with backgrounded jobs run
Here are few links which may be useful in debugging this problem.
The base link to the archives for the OpenSSH developer mailing list:
A thread within this archive that somewhat mentions this very problem (from Sept
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
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 email@example.com 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
There are, of course, other issues fixed.. :-)
FWIW, OpenSSH-2.3.0p1 was released today.
http://OpenSSH Security Advisory
oops, that URL was supposed to be:
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...
OK; marking RESOLVED/ERRATA
include this bug ID as fixed?