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.
Created attachment 3355 [details] abort connection for tunnel forward failures when ExitOnForwardFailure is set Please try this patch
If you're able to test this quickly there is a chance it will make the 8.2 release, due in a few weeks.
Tested, now it fails like it should. Thanks
Ping on this bug. The patch seems to work fine, is there anything else that prevents it from being applied upstream?
This has been committed and will be in OpenSSH 8.3 - thanks
close bugs that were resolved in OpenSSH 8.5 release cycle
[spam removed]