"LocalCommand" is documented as being executed _after_ the local machine after successfully connecting to the server. But as it's implemented now, this is done _before_ "Tunnel" is set up. Thus the tunnel device is not present at the time when "LocalCommand" is executed. Thus "LocalCommand" can not be used to configure the tunnel device. Here is some debugging output debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] Device tap7 does not seem to be present, delaying initialization. debug1: Entering interactive session. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Requesting tun. debug1: sys_tun_open: tap7 mode 2 fd 7 debug1: channel 1: new [tun] The "Device tap7 does not seem ..." message is from the LocalCommand.
I see the same problem here with openssh 4.5p1. I run "exim -qff" to forcably flush the mail queue (which should be done via a forwarded port) but it hangs. Running "netstat -an" as LocalCommand shows that the local portforwardings are listening but there is no connection established, which is why my LocalCommand hangs. The man page just says "command to execute on the local machine after successfully connecting the server" which does not say if connection setup is ready and tunnel/portforwardings are established. But IMHO only that would make sense.
Created attachment 1310 [details] Request tunnel earlier This patch causes tunnel forwarding to be requested before local_command is executed. Can you please give it a try? Please note that because the tunnel open is processed asynchronously by the server, its end may not be open (indeed, it may never open if the server denies the request). The client end, where local_command is run, will be open. This patch will also make tunnel forwarding honour ExitOnForwardFailure for local errors (but not remote).
This patch has been applied and will be in the 4.7 release.
Close resolved bugs after release.