Bug 3116

Summary:

ExitOnForwardFailure=yes does not cause connection to die when server fails to open tunnel

Product:

Portable OpenSSH

Reporter:

Anton Khirnov <anton>

Component:

ssh

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED FIXED

Severity:

normal

CC:

ahmedsayeed1982, djm

Priority:

Version:

8.1p1

Hardware:

amd64

OS:

Linux

Bug Depends on:

Bug Blocks:

3117

Attachments:

Description	Flags
abort connection for tunnel forward failures when ExitOnForwardFailure is set	none

Description Anton Khirnov 2020-01-29 21:40:59 AEDT

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@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@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@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.

Comment 1 Damien Miller 2020-01-31 16:20:26 AEDT

Created attachment 3355 [details]
abort connection for tunnel forward failures when ExitOnForwardFailure is set

Please try this patch

Comment 2 Damien Miller 2020-02-01 09:32:25 AEDT

If you're able to test this quickly there is a chance it will make the 8.2 release, due in a few weeks.

Comment 3 Anton Khirnov 2020-02-01 23:54:17 AEDT

Tested, now it fails like it should. Thanks

Comment 4 Anton Khirnov 2020-03-13 21:40:35 AEDT

Ping on this bug. The patch seems to work fine, is there anything else that prevents it from being applied upstream?

Comment 5 Damien Miller 2020-04-03 13:40:53 AEDT

This has been committed and will be in OpenSSH 8.3 - thanks

Comment 6 Damien Miller 2021-03-04 09:54:04 AEDT

close bugs that were resolved in OpenSSH 8.5 release cycle

Comment 7 Ahmed Sayeed 2021-10-14 01:41:25 AEDT

[spam removed]