Bug 1232

Summary:

"LocalCommand" is executed before session is set up

Product:

Portable OpenSSH

Reporter:

h.goebel

Component:

ssh

Assignee:

Damien Miller <djm>

Status:

CLOSED FIXED

Severity:

normal

CC:

bjoern

Priority:

Version:

4.5p1

Hardware:

ix86

OS:

Linux

Bug Depends on:

Bug Blocks:

1289

Attachments:

Description	Flags
Request tunnel earlier	none

Description h.goebel 2006-09-18 22:17:54 AEST

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

Comment 1 BjÃ¶rn Jacke 2007-01-17 22:48:27 AEDT

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.

Comment 2 Damien Miller 2007-06-22 15:18:01 AEST

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

Comment 3 Damien Miller 2007-08-08 14:02:00 AEST

This patch has been applied and will be in the 4.7 release.

Comment 4 Damien Miller 2008-04-04 09:56:15 AEDT

Close resolved bugs after release.