Bug 762 - ssh does not exit if local port could not be bound with options -L and -N
Summary: ssh does not exit if local port could not be bound with options -L and -N
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 3.7.1p1
Hardware: ix86 Linux
: P2 enhancement
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks: V_4_4
  Show dependency treegraph
 
Reported: 2003-11-22 13:13 AEDT by Jeremy Peterson
Modified: 2006-09-28 19:25 AEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Peterson 2003-11-22 13:13:46 AEDT
When ssh is run to create an ssh tunnel and to do nothing else, it does not exit
if the local port is already in use. I tried a few different command lines to
make sure that ssh was aware that I was only trying to create a tunnel. I hoped
that if the tunnel could not be established completely, ssh would exit with an
error status. This is important to programs and scripts that use ssh to only
create tunnels.

I tried the following:

$ ./ssh -n -a -N -L 80:localhost:17 remote
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 80
Could not request local forwarding.

$ ./ssh -f -a -N -L 80:localhost:17 remote
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 80
Could not request local forwarding.
$ ps
jeremyp  25826  0.0  0.2  3112 1628 ?        S    15:08   0:00 ./ssh -f -a -N -L
80:localhost:17 remote

In the first example, I had to C-c out... in the second, the process still
appears in ps output.

I'm not sure whether this is a minor bug or an enhancement. It seems that ssh
should always exit if what it was able to setup cannot be used and it has
nothing else to do (I can't use the tunnel without a local port to connect to).
Comment 1 Damien Miller 2006-07-12 07:39:58 AEST
openssh-4.4 now supports an ExitOnForwardFailure option that does just this
Comment 2 Darren Tucker 2006-09-28 19:25:20 AEST
With the release of 4.4, we believe that this bug is now closed.  For information about the release please see http://www.openssh.com/txt/release-4.4 .