openssh bugs - May 2019 - [Bug 3017] New: ExitOnForwardFailure=yes doesn't work for local forwards (-L)

https://bugzilla.mindrot.org/show_bug.cgi?id=3017

            Bug ID: 3017
           Summary: ExitOnForwardFailure=yes doesn't work for local
                    forwards (-L)
           Product: Portable OpenSSH
           Version: 7.6p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: wiebe at halfgaar.net

Logging in from an Ubuntu 18.04 machine, OpenSSH 7.6p1-4ubuntu0.3, the
option ExitOnForwardFailure doesn't seem to work. I says 'bind: Address
already in use' and I get a shell:

======halfgaar@<localmachine>: ~
$ ssh -L 8080:localhost:22 -o ExitOnForwardFailure=yes root at server.com
bind: Address already in use
Linux <remoteserver> 4.9.0-8-686-pae #1 SMP Debian 4.9.144-3
(2019-02-02) i686

The programs included with the Debian GNU/Linux system are free
software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri May 31 12:39:27 2019 from 84.22.107.110
root@<remoteserver>: ~
#
======
Using -f also just makes it fork.

It does work properly with reverse tunnels (-R).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3017

--- Comment #1 from Wiebe Cazemier <wiebe at halfgaar.net> ---
It does work properly from Ubuntu 16.04, Openssh 7.2p2-4ubuntu2.8:


ssh -L 22022:localhost:22 -o ExitOnForwardFailure=yes root at server.com
-p 22022
bind: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 22022          
Could not request local forwarding.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3017

--- Comment #2 from Wiebe Cazemier <wiebe at halfgaar.net> ---
Another interesting result: it started happening randomly. Apparently,
it switched between ipv4 and ipv6. With -4, it works properly and fails
consistently.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3017

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
Could you please attach a debug trace from a failing instance? "ssh
-vvv ..."

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3017

--- Comment #4 from Wiebe Cazemier <wiebe at halfgaar.net> ---
Created attachment 3435
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3435&action=edit
ssh -vvv output

Debug trace with ExitOnForwardFailure=yes that still logs in.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3017

Pavel Sidlo <pavel.sidlo at linuxbox.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pavel.sidlo at linuxbox.cz

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3017

--- Comment #5 from Pavel Sidlo <pavel.sidlo at linuxbox.cz> ---
I've faced probably the same behavior for RemoteForward.

I seems sshd by default allocates both tcp and tcp6 sockets.
ExitOnForwardFailure fails to reject connection if tcp is already in
use but tcp6 is not (and vice versa).

Workaround for me is to split RemoteForward to separate tcp and tcp6.

Previous problematic settings:
-o "ExitOnForwardFailure yes" -R 56984:localhost:22

New reliable settings:
-o "ExitOnForwardFailure yes" -R [::1]:56984:[::1]:22 -R
127.0.0.1:56984:127.0.0.1:22

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3017

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #6 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Wiebe Cazemier from comment #4)
> Created attachment 3435 [details]
> ssh -vvv output
> 
> Debug trace with ExitOnForwardFailure=yes that still logs in.
What's happening is that ssh is successfully listening on either the v4
or v6 address for localhost.  Since it did in fact successfully listen
it considers it to have succeeded.  I can reproduce the same behaviour
by deliberately busying out one or the other:

$ nc -4 -l 1234 &
$ ssh -vvv -o exitonforwardfailure=yes -L 1234:127.0.0.1:1234 localhost

$ sudo lsof -n -i :1234
COMMAND    PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
nc      465379 dtucker    3u  IPv4 4443587      0t0  TCP *:1234
(LISTEN)
ssh     465656 dtucker    4u  IPv6 4470895      0t0  TCP [::1]:1234
(LISTEN)

If you specify the address it'll only try that one and fail if it's
busy:

$ ssh -vvv -o exitonforwardfailure=yes -L 127.0.0.1:1234:127.0.0.1:1234
localhost
[...]
bind [127.0.0.1]:1234: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 1234
Could not request local forwarding

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3017

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WORKSFORME
             Status|NEW                         |RESOLVED

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
closing for lack of followup

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3017

--- Comment #8 from Wiebe Cazemier <wiebe at halfgaar.net> ---
What exactly is the lack of follow-up? I thought the cause was clear?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.