I am trying to create a tunnel via ssh from cygwin to solaris. Normally
I would do something like this (cygwin is my windows box having cygwin
installed and solaris is a solaris based server):

cygwin$ ssh -L5900:localhost:5900 solaris

My problem is that the destination port is unknown at the time I create
the ssh call. Only once I have logged in on solaris can I determine the
destination port. So I was thinking why not use the "~" escape code to
create a tunnel on the fly. The ssh connection is created in a shell
and therefore not used interactively.

So I would do something like this:

(send_commands) | ssh -t -t solaris | (parse_output)

Two problems arise now:

1) Using "-t -t" to force tty allocation prevents anything sent to
stdout/stderr on solaris to be trasmitted to my cygwin box.

2) Sending the escape code "~C" somehow makes ssh grab keyboard input
even though it is placed after a pipe (|), i.e. stdin was supposed to
come from send_commands yet ssh managed to grab keyboard input. I was
quite surprised that this was possible and have still not solved that
puzzle.

Of course, both problems are a showstopper. I dont know why ssh stops
listening to stdin once an escape command is requested "~C" and I am
also at a loss as to why solaris refuses to send any tty output back
via the ssh connection.

Does anyone out there have a suggestion/solution?

galmok@gmail.com writes:
> I am trying to create a tunnel via ssh from cygwin to solaris. Normally
> I would do something like this (cygwin is my windows box having cygwin
> installed and solaris is a solaris based server):
>
> cygwin$ ssh -L5900:localhost:5900 solaris
>
> My problem is that the destination port is unknown at the time I create
> the ssh call. Only once I have logged in on solaris can I determine the
> destination port.

Why is that? What is it you're forwarding? Perhaps there's another
way to go about it.

> Does anyone out there have a suggestion/solution?

The easiest way of course would be

ssh solaris "command to figure out what port you want"
ssh -L5900:localhost:thatport solaris

If typing the password becomes a chore, switch to public key auth and
use ssh-agent first to load your key into memory. After that, ssh
commands to solaris would pop through without a password prompt which
is kinda fun.

Best Regards,
--
Todd H.
http://www.toddh.net/

Todd H. skrev:
> galmok@gmail.com writes:
> > I am trying to create a tunnel via ssh from cygwin to solaris. Normally
> > I would do something like this (cygwin is my windows box having cygwin
> > installed and solaris is a solaris based server):
> >
> > cygwin$ ssh -L5900:localhost:5900 solaris
> >
> > My problem is that the destination port is unknown at the time I create
> > the ssh call. Only once I have logged in on solaris can I determine the
> > destination port.
>
> Why is that? What is it you're forwarding? Perhaps there's another
> way to go about it.

A VNC connection. Considering the user doesn't always know in advance
which port their vnc connection runs on, a script to find their display
has been created. And since it is possible to create port forwarding
dynamically using the escape commands, I wanted to create a
user-friendly way for users to launch a viewer to their vnc session.
Sequence of actions: Double-click icon, enter ssh password, enter vnc
password, ready to use.

> > Does anyone out there have a suggestion/solution?
>
> The easiest way of course would be
>
> ssh solaris "command to figure out what port you want"
> ssh -L5900:localhost:thatport solaris
>
> If typing the password becomes a chore, switch to public key auth and
> use ssh-agent first to load your key into memory. After that, ssh
> commands to solaris would pop through without a password prompt which
> is kinda fun.

Yes, I have setup such a system (ssh-agent) for myself but can't expect
my users to do the same. Also, we have no control over the password (if
any) they chose to put on their local key. If they loose their laptop,
an intruder would have an easy time logging on to our system. And the
user would probably not inform us about the loss of their laptop and if
they ssh key was without a password.

But solaris prevents any stdout being sent back when a tty allocation
is forced. That is a huge showstopper. Also, the local cygwin openssh
client manages to redirect stdin from the pipe to the keyboard when
"~C" is sent via the pipe to ssh, making it difficult to enter
information to create the pipe.

I guess I may be able to use forward a fixed port for a particular user
(making sure each user has their own remote port) and have them make a
tunnel on the remote host to the desired port. Problem is that it
requires double the ports on the server and an tunnel program. It would
be nicer if dynamic port allocation could be programmatically achived
(contrary to interactive only as it is now).

Hi,

if you can get this to work:
> >
> > ssh solaris "command to figure out what port you want"
> > ssh -L5900:localhost:thatport solaris
> >
then perhaps you could prepare a file like this, and give it
execution permissions:

------------------------------------------------------------
#!/bin/bash
port=$( ssh solaris "command to print out the port number (and nothing
else)" )
ssh -L 5900:localhost:$port solaris
------------------------------------------------------------

This would require the user to login twice with his shell user and
pass, and then with his VNC pass, but with a bit more of work you might
turn it into a script that asks for the user and pass and uses them
twice.

Hope it s:

Wences



galmok@gmail.com wrote:
> Todd H. skrev:
> > galmok@gmail.com writes:
> > > I am trying to create a tunnel via ssh from cygwin to solaris. Normally
> > > I would do something like this (cygwin is my windows box having cygwin
> > > installed and solaris is a solaris based server):
> > >
> > > cygwin$ ssh -L5900:localhost:5900 solaris
> > >
> > > My problem is that the destination port is unknown at the time I create
> > > the ssh call. Only once I have logged in on solaris can I determine the
> > > destination port.
> >
> > Why is that? What is it you're forwarding? Perhaps there's another
> > way to go about it.
>
> A VNC connection. Considering the user doesn't always know in advance
> which port their vnc connection runs on, a script to find their display
> has been created. And since it is possible to create port forwarding
> dynamically using the escape commands, I wanted to create a
> user-friendly way for users to launch a viewer to their vnc session.
> Sequence of actions: Double-click icon, enter ssh password, enter vnc
> password, ready to use.
>
> > > Does anyone out there have a suggestion/solution?
> >
> > The easiest way of course would be
> >
> > ssh solaris "command to figure out what port you want"
> > ssh -L5900:localhost:thatport solaris
> >
> > If typing the password becomes a chore, switch to public key auth and
> > use ssh-agent first to load your key into memory. After that, ssh
> > commands to solaris would pop through without a password prompt which
> > is kinda fun.
>
> Yes, I have setup such a system (ssh-agent) for myself but can't expect
> my users to do the same. Also, we have no control over the password (if
> any) they chose to put on their local key. If they loose their laptop,
> an intruder would have an easy time logging on to our system. And the
> user would probably not inform us about the loss of their laptop and if
> they ssh key was without a password.
>
> But solaris prevents any stdout being sent back when a tty allocation
> is forced. That is a huge showstopper. Also, the local cygwin openssh
> client manages to redirect stdin from the pipe to the keyboard when
> "~C" is sent via the pipe to ssh, making it difficult to enter
> information to create the pipe.
>
> I guess I may be able to use forward a fixed port for a particular user
> (making sure each user has their own remote port) and have them make a
> tunnel on the remote host to the desired port. Problem is that it
> requires double the ports on the server and an tunnel program. It would
> be nicer if dynamic port allocation could be programmatically achived
> (contrary to interactive only as it is now).

Wences wrote:
> Hi,
>
> if you can get this to work:
> > >
> > > ssh solaris "command to figure out what port you want"
> > > ssh -L5900:localhost:thatport solaris
> > >
> then perhaps you could prepare a file like this, and give it
> execution permissions:
>
> ------------------------------------------------------------
> #!/bin/bash
> port=$( ssh solaris "command to print out the port number (and nothing
> else)" )
> ssh -L 5900:localhost:$port solaris
> ------------------------------------------------------------
>
> This would require the user to login twice with his shell user and
> pass, and then with his VNC pass, but with a bit more of work you might
> turn it into a script that asks for the user and pass and uses them
> twice.

It is not a great solution, but so far this is one of my only options.

I am considering using vncconnect instead and simply let the vncserver
connect to a listening vncviewer. This can be accomplished using only 1
login (which can be ssh or whatever). Downside is that the traffic is
unencrypted but the vncpassword is not required (and hence not
transmitted) so the danger may not be so great.

Or if I could find a vncviewer that supported socks proxy I could
simply use the socks proxy feature of the ssh client to create the
tunnels dynamically. Tightvnc however does not support socks proxy. I
am considering using SocksCap32 but that requires the user to install
additional software.

Maybe putty is easier to work with... I'll have to check.

galmok@gmail.com wrote:
> I am trying to create a tunnel via ssh from cygwin to solaris. Normally
> I would do something like this (cygwin is my windows box having cygwin
> installed and solaris is a solaris based server):
>
> cygwin$ ssh -L5900:localhost:5900 solaris
>
> My problem is that the destination port is unknown at the time I create
> the ssh call. Only once I have logged in on solaris can I determine the
> destination port. So I was thinking why not use the "~" escape code to
> create a tunnel on the fly. The ssh connection is created in a shell
> and therefore not used interactively.
>
> So I would do something like this:
>
> (send_commands) | ssh -t -t solaris | (parse_output)
>
> Two problems arise now:
>
> 1) Using "-t -t" to force tty allocation prevents anything sent to
> stdout/stderr on solaris to be trasmitted to my cygwin box.
>
> 2) Sending the escape code "~C" somehow makes ssh grab keyboard input
> even though it is placed after a pipe (|), i.e. stdin was supposed to
> come from send_commands yet ssh managed to grab keyboard input. I was
> quite surprised that this was possible and have still not solved that
> puzzle.
>
> Of course, both problems are a showstopper. I dont know why ssh stops
> listening to stdin once an escape command is requested "~C" and I am
> also at a loss as to why solaris refuses to send any tty output back
> via the ssh connection.
>
> Does anyone out there have a suggestion/solution?
>

Not sure I see what the problem here is or why it needs to be
complicated. I use ssh to forward VNC connections all the time. I just
forward port 590x to the remote server same port and connect the viewer
to the localhost port. It's that simple. The only other thing you may
need to do is enable the option on the server that allows connections
from localhost.

galmok@gmail.com writes:

> A VNC connection. Considering the user doesn't always know in advance
> which port their vnc connection runs on

Why not? Aren't they starting it with vncserver :blah ?

Then the port number it 590blah ?


--
Todd H.
http://www.toddh.net/

Todd H. wrote:
> galmok@gmail.com writes:
>
> > A VNC connection. Considering the user doesn't always know in advance
> > which port their vnc connection runs on
>
> Why not? Aren't they starting it with vncserver :blah ?
>
> Then the port number it 590blah ?

Yes, that is so, but for reduced -support it is MUCH to prefer that
a script handles it all. Also, it would make it more reliable for the
user. Even more, the simpler it is, the more they are going to use it.
Me, being a knowledged user, have no problem getting my vnc connection
to run, but the less technology knowing users stall easily and I want
to prevent that.

Also, we had to move the ports to 6300 and up (display :400 and up) as
we were running out of display numbers on the server (it is serving a
large number of sunray sessions besides vnc sessions). This also means
the users can't use default port/display numbers as they are referenced
in documents found via google. But basically we want to make it simple,
both for the users and for the supporters.