Mailing List Archive

Hi,

> If I invoke ssh this way:
> ssh -R 0:localhost:22 remote_ssh_server
> ssh prints a debug message like:
> Allocated port 40454 for remote forward ....
> before it drops to the shell.
>
> Is there a way of querying the allocated port on the remote site to
> make it usable within scripts? For example to execute a command via
> ssh on the origin site in this case.

If you could determine the ancestry of the script process, back to the
sshd driving it and then look up the pid in lsof or netstat output,
you could probably do it.

That or if the script had access to logs and the logging level were
high enough.

On Tuesday 17 August 2010 06:59:33 ADFHAU wrote:
> Hi,
>
> > If I invoke ssh this way:
> > ssh -R 0:localhost:22 remote_ssh_server
> >
> > ssh prints a debug message like:
> > Allocated port 40454 for remote forward ....
> >
> > before it drops to the shell.
> >
> > Is there a way of querying the allocated port on the remote site to
> > make it usable within scripts? For example to execute a command via
> > ssh on the origin site in this case.
>
> If you could determine the ancestry of the script process, back to the
> sshd driving it and then look up the pid in lsof or netstat output,
> you could probably do it.
>
> That or if the script had access to logs and the logging level were
> high enough.

Determine the sshd process can be done via $PPID from thin the login shell:
echo "shell pid: $$, sshd pid: $PPID"

Unfortunately using lsof -p $PPID (or /proc/$PPID) doesn't work in this case
because the login user doesn't have read permissions to query the sshd process
(not the sshd daemon). Unless lsof is executed as root this doesn't work.

-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On Behalf Of Joke de Buhr
Sent: Tuesday, August 17, 2010 2:03 PM
To: secureshell@securityfocus.com
Subject: Re: Dynamically allocated port on reverse forward

On Tuesday 17 August 2010 06:59:33 ADFHAU wrote:
> Hi,
>
> > If I invoke ssh this way:
> > ssh -R 0:localhost:22 remote_ssh_server
> >
> > ssh prints a debug message like:
> > Allocated port 40454 for remote forward ....
> >
> > before it drops to the shell.
> >
> > Is there a way of querying the allocated port on the remote site to
> > make it usable within scripts? For example to execute a command via
> > ssh on the origin site in this case.
>
> If you could determine the ancestry of the script process, back to the
> sshd driving it and then look up the pid in lsof or netstat output,
> you could probably do it.
>
> That or if the script had access to logs and the logging level were
> high enough.

Determine the sshd process can be done via $PPID from thin the login shell:
echo "shell pid: $$, sshd pid: $PPID"

Unfortunately using lsof -p $PPID (or /proc/$PPID) doesn't work in this case because the login user doesn't have read permissions to query the sshd process (not the sshd daemon). Unless lsof is executed as root this doesn't work.

----

You probably know this, but to dismiss the simplest stuff first: You can specify a port, rather than relying on dynamic allocation. Just use a number instead of 0. If you pick under 1024 you'll have to be logging in as root on the remote side as those numbers are reserved.

FAILED IDEA: A nifty trick for local forwards to different machines is to bind them to alternate local interfaces.
Example:
/etc/hosts
127.0.0.2 local2
127.0.0.3 local3

ssh user@remote -L local2:22:host2:22 -L local3:22:host3:22
ssh user@local2 # goes to host2 tunneled via initial ssh connection
ssh user@local3 # goes to host3 tunneled via initial ssh connection

Alas, when I tested remote forwards to alternate interfaces on the remote machine, the resolution failed.

ssh user@remote -R 0:local2:22 -R 0:local3:22
netstat -tl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:55313 *:* LISTEN
tcp 0 0 localhost:42267 *:* LISTEN

The hope was that you'd be able to see:
netstat -tl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 local3:55313 *:* LISTEN
tcp 0 0 local2:42267 *:* LISTEN

You could, of course, just alias 10.0.0.0/8 ip addresses to a local interface, but that's probably a bit much work.

As a side note, it seems a major disappointment that there's no escape sequence to list these. On my Ubuntu 10.4 test machines ~# failed to list remote forwards.

Also, if you dynamically forward multiple ports, how do you tell which dynamically assigned remote port maps to each local port?

On Tuesday 17 August 2010 21:49:52 Males, Jess wrote:
> -----Original Message-----
> From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On
> Behalf Of Joke de Buhr Sent: Tuesday, August 17, 2010 2:03 PM
> To: secureshell@securityfocus.com
> Subject: Re: Dynamically allocated port on reverse forward
>
> On Tuesday 17 August 2010 06:59:33 ADFHAU wrote:
> > Hi,
> >
> > > If I invoke ssh this way:
> > > ssh -R 0:localhost:22 remote_ssh_server
> > >
> > > ssh prints a debug message like:
> > > Allocated port 40454 for remote forward ....
> > >
> > > before it drops to the shell.
> > >
> > > Is there a way of querying the allocated port on the remote site to
> > > make it usable within scripts? For example to execute a command via
> > > ssh on the origin site in this case.
> >
> > If you could determine the ancestry of the script process, back to the
> > sshd driving it and then look up the pid in lsof or netstat output,
> > you could probably do it.
> >
> > That or if the script had access to logs and the logging level were
> > high enough.
>
> Determine the sshd process can be done via $PPID from thin the login shell:
> echo "shell pid: $$, sshd pid: $PPID"
>
> Unfortunately using lsof -p $PPID (or /proc/$PPID) doesn't work in this
> case because the login user doesn't have read permissions to query the
> sshd process (not the sshd daemon). Unless lsof is executed as root this
> doesn't work.
>
> ----
>
> You probably know this, but to dismiss the simplest stuff first: You can
> specify a port, rather than relying on dynamic allocation. Just use a
> number instead of 0. If you pick under 1024 you'll have to be logging in
> as root on the remote side as those numbers are reserved.

Of cause I could use a constant port number. But some of the remote servers
are public servers and sometimes I ran into port collisions with other people
using the server. That's why a dynamically allocated port would be preferable.

It would be nice if ssh would export the allocated port the environment, a
query program maybe or something like that. Any way to query the allocated
port.

> FAILED IDEA: A nifty trick for local forwards to different machines is to
> bind them to alternate local interfaces. Example:
> /etc/hosts
> 127.0.0.2 local2
> 127.0.0.3 local3
>
> ssh user@remote -L local2:22:host2:22 -L local3:22:host3:22
> ssh user@local2 # goes to host2 tunneled via initial ssh connection
> ssh user@local3 # goes to host3 tunneled via initial ssh connection
>
> Alas, when I tested remote forwards to alternate interfaces on the remote
> machine, the resolution failed.
>
> ssh user@remote -R 0:local2:22 -R 0:local3:22
> netstat -tl
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 localhost:55313 *:* LISTEN
> tcp 0 0 localhost:42267 *:* LISTEN
>
> The hope was that you'd be able to see:
> netstat -tl
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 local3:55313 *:* LISTEN
> tcp 0 0 local2:42267 *:* LISTEN
>
> You could, of course, just alias 10.0.0.0/8 ip addresses to a local
> interface, but that's probably a bit much work.
>
> As a side note, it seems a major disappointment that there's no escape
> sequence to list these. On my Ubuntu 10.4 test machines ~# failed to list
> remote forwards.
>
> Also, if you dynamically forward multiple ports, how do you tell which
> dynamically assigned remote port maps to each local port?

Maybe ssh could export an environment variable like:
SSH_FORWARDED_PORTS="bind_address:port:host:hostport;bind_address:..."