Possible issue with stdio forwarding

[Iain Morgan]

On Thu, Jan 28, 2010 at 20:01:08 -0600, Damien Miller wrote:
> On Thu, 28 Jan 2010, Iain Morgan wrote:
> 
> > Greetings,
> > 
> > I've been doing a little testing with the stdio forwarding support added
> > in recent snapshots and have encountered one possible issue. First, I
> > should say that this feature generally seems to work. However, I haven't
> > been able to get it to work when connecting to a server running
> > SSH.COM's product.
> > 
> > The config file I am using is fairly simple:
> > 
> > Host sfe1
> > 	LogLevel		debug3
> > 
> > Host cfe?
> > 	ProxyCommand		ssh -W %h:%p sfe1
> > 
> > Host *
> > 	HostbasedAuthentication	no
> > 
> > If I connect to the bastion, sfe1, and request TCP port forwarding a la
> > -L 2122:cfe1:22, I am able to successfully connect to cfe1 via the
> > forwarded port. However, if I use stdio forwarding as indicated in the
> > config file above, the connection fails.
> > 
> > Given that the server allows TCP forwarding of the desired port, I had
> > expected that stdio forwarding would likewise work. The stdio forwarding
> > apporach does work if the intermediate server is running OpenSSH, even a
> > somewhat dated version. So I'm suspecting it is a quirk with the SSH.COM
> > server.
> > 
> > Here's the debug3 output from the proxy command attempting to do the
> > stdio forwarding.
> ...
> > debug3: client_setup_stdio_fwd cfe1:22
> > debug1: channel_connect_stdio_fwd cfe1:22
> > debug1: channel 0: new [stdio-forward]
> > debug2: fd 4 setting O_NONBLOCK
> > debug2: fd 5 setting O_NONBLOCK
> > debug1: getpeername failed: Bad file descriptor
> > debug1: Entering interactive session.
> > debug3: Received SSH2_MSG_IGNORE
> > channel 0: open failed: connect failed: No description
> 
> I think this is the culprit. From session.c:
> 
>   1366  static void
>   1367  port_open_helper(Channel *c, char *rtype)
>   1368  {
>   1369          int direct;
>   1370          char buf[1024];
>   1371          char *remote_ipaddr = get_peer_ipaddr(c->sock);
>   1372          int remote_port = get_peer_port(c->sock);
> ...
>   1386                  packet_start(SSH2_MSG_CHANNEL_OPEN);
>   1387                  packet_put_cstring(rtype);
>   1388                  packet_put_int(c->self);
>   1389                  packet_put_int(c->local_window_max);
>   1390                  packet_put_int(c->local_maxpacket);
> ...
>   1400                  /* originator host and port */
>   1401                  packet_put_cstring(remote_ipaddr);
>   1402                  packet_put_int((u_int)remote_port);
>   1403                  packet_send();
> 
> get_peer_ipaddr() will return "UNKNOWN" for stdio connections and 
> get_peer_port() will return -1. OpenSSH just logs these values (they
> are client supplied, so untrustworthy for any serious use), but Tectia
> is probably sanity checking them. Could you try this diff?
> 
> Index: channels.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/ssh/channels.c,v
> retrieving revision 1.302
> diff -u -p -r1.302 channels.c
> --- channels.c	26 Jan 2010 01:28:35 -0000	1.302
> +++ channels.c	29 Jan 2010 01:59:34 -0000
> @@ -1371,6 +1371,13 @@ port_open_helper(Channel *c, char *rtype
>  	char *remote_ipaddr = get_peer_ipaddr(c->sock);
>  	int remote_port = get_peer_port(c->sock);
>  
> +	if (remote_port == -1) {
> +		/* Fake something */
> +		xfree(remote_ipaddr);
> +		remote_ipaddr = xstrdup("127.0.0.1");
> +		remote_port = 1;
> +	}
> +
>  	direct = (strcmp(rtype, "direct-tcpip") == 0);
>  
>  	snprintf(buf, sizeof buf,
> 
> I'm not sure this is the right solution. E.g. it doesn't try to match
> the AF of the target forward, but maybe it doesn't matter.
> 
> -d

I just tested it and it works. I'll do some further testing tomorrow.

Thanks

-- 
Iain Morgan