openssh bugs - Jan 2020 - [Bug 3116] New: ExitOnForwardFailure=yes does not cause connection to die when server fails to open tunnel

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

            Bug ID: 3116
           Summary: ExitOnForwardFailure=yes does not cause connection to
                    die when server fails to open tunnel
           Product: Portable OpenSSH
           Version: 8.1p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: anton at khirnov.net

I am using ssh to create a tap tunnel between two mashines. The client
commandline looks roughly like this:
ssh -f -N -y -v -o Tunnel=ethernet -o ServerAliveInterval=30 -o
ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -w 0:0 user at server

If the server fails to open the tunnel device on its end (e.g. because
some other process is still holding on to it), I get the following in
the client's log:

debug1: Requesting tun unit 0 in mode 2
debug1: sys_tun_open: tap0 mode 2 fd 4
debug1: Tunnel forwarding using interface tap0
debug1: channel 0: new [tun]
debug1: Requesting no-more-sessions at openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00 at openssh.com
want_reply 0
debug1: Remote: /var/local/yharnam/.ssh/authorized_keys:1: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /var/local/yharnam/.ssh/authorized_keys:1: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: Failed to open the tunnel device.
channel 0: open failed: connect failed: open failed
debug1: channel 0: free: tun, nchannels 1

but the connection does not terminate. Since ExitOnForwardFailure
documentation indicates it should terminate if tunnel setup fails, this
would seem to be a bug.

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

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

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Created attachment 3355
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3355&action=edit
abort connection for tunnel forward failures when ExitOnForwardFailure
is set

Please try this patch

-- 
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=3116

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
If you're able to test this quickly there is a chance it will make the
8.2 release, due in a few weeks.

-- 
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=3116

--- Comment #3 from Anton Khirnov <anton at khirnov.net> ---
Tested, now it fails like it should. Thanks

-- 
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=3116

--- Comment #4 from Anton Khirnov <anton at khirnov.net> ---
Ping on this bug. The patch seems to work fine, is there anything else
that prevents it from being applied upstream?

-- 
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=3116

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Blocks|                            |3117
             Status|NEW                         |RESOLVED

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
This has been committed and will be in OpenSSH 8.3 - thanks


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3117
[Bug 3117] Tracking bug for 8.3 release
-- 
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=3116

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
close bugs that were resolved in OpenSSH 8.5 release cycle

-- 
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=3116

Ahmed Sayeed <ahmedsayeed1982 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahmedsayeed1982 at yahoo.com

--- Comment #7 from Ahmed Sayeed <ahmedsayeed1982 at yahoo.com> ---
Minimal testcase: http://www.compilatori.com/category/computers/
        .align  8
        .globl main http://www.acpirateradio.co.uk/category/property/
        .globl insn
        .type  main, @function
http://www.logoarts.co.uk/category/services/
        .type  insn, @function
        # This should return 0 on success.
http://www.slipstone.co.uk/tech/nvidia-and-samsung/
main:
        basr    %r1, %r0
insn:   bc      15, win-insn(0,%r1)
http://embermanchester.uk/category/technology/
        lghi    %r2,1
win:    lghi    %r2,0
        br      %r14
http://connstr.net/category/tech/
Assemble and link the above.

Turn on displaced stepping, set a breakpoint on `insn`, run, then try
to step over the breakpoint with stepi.
http://joerg.li/computers/latest-car-deals/
(gdb) set displaced-stepping on
(gdb) b insn http://www.jopspeech.com/services/surface-duo/
(gdb) r
(gdb) stepi http://www.wearelondonmade.com/tech/nvidia-and-samsung/

instead of branching to `win`, gdb will branch to an apparently random
nearby address, and the inferior will generally crash. This problem is
present in all versions of GDB I've tested.
https://waytowhatsnext.com/computers/what-is-ssl-certificate/
When trying to step over a breakpoint set on a BC (branch on condition)
    instruction with displaced stepping on IBM Z, gdb would incorrectly
    adjust the pc regardless of whether or not the branch was taken.
Since
http://www.iu-bloomington.com/technology/advantages-of-online-banks/
    the branch target is an absolute address, this would cause the
inferior
    to jump around wildly whenever the branch was taken, either
crashing it https://komiya-dental.com/sports/telegram/
    or causing it to behave unpredicta
When trying to step over a breakpoint set on a BC (branch on condition)
http://www-look-4.com/property/houses-in-france/
    instruction with displaced stepping on IBM Z, gdb would incorrectly
    adjust the pc regardless of whether or not the branch was taken.
Since
    the branch target is an absolute address,
https://www.webb-dev.co.uk/sports/sports-and-health/ this would cause
the inferior
    to jump around wildly whenever the branch was taken, either
crashing it
    or causing it to behave unpredicta

-- 
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.