Re: Dynamically allocated port on reverse forward

On Tuesday 17 August 2010 21:49:52 Males, Jess wrote:
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Joke de Buhr Sent: Tuesday, August 17, 2010 2:03 PM
> To: [email protected]
> 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:..."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQG7BAABAwAlBQJMavfHHhhoa3A6Ly9wb29sLnNrcy1rZXlzZXJ2ZXJzLm5ldAAK
CRCWUloJhwFWxnfNC/9rQxpCcwaw5zaJ44lshNT9EkYrBT1Os0w1lmGLD4YgAe0U
rl8gM/qR5utlaGgBy8G/F0NTMskwiJprFR2AT4UgWhbjChdLQvSWNpngbUxMt0mH
GtmbVBEQ+QSrkp3G8Q2+g4WmLtZBh84+8t28KBTVzFx4474WRUMBuJ5cFTRuSwtd
0NyRWBpPSDwPwkAV2N/MWPPimbOOFqKTtffqXfrKCHQS9G993VIQS8Q0t9rhgLd9
HBtA2aRyKzTCsneO3GHwwIcaaRfjxdDynYAvYQWKFAFMc45V6uWSzqy4lTmURu0C
SU0HOGJ0iIblxNmBbhIoTY3UiDpnRLdODqhZIs3T37t+Pcs6Uwc4bo4NEEr57aEN
wSuDvl8a/dLHd4s0mcsXZ7c5G74b53aqiITJtXLgFkgA3kuW4cCj4FYHA+ojFmX4
nP2RWLxSSilNGKSq7K+gmoPR/xWDSqfVVQNcm46krBS39+jOf1mhQhsY02jjkBEQ
UpFM40aLxsKhbnaqidI=
=6ecU
-----END PGP SIGNATURE-----