Feature Request: SSH support

[GoogleCodeExporter]

An option to establish an SSH connection, with associated parameters, could
be very useful.  For instance if the support provider is behind a firewall
themselves, an SSH reverse forward can be used to open a listener on the
firewall and redirect connections to the providers actual system.

Original issue reported on code.google.com by jamin.co...@gmail.com on 27 Oct 2008 at 4:27

[GoogleCodeExporter]

Part of that would be accomplished with the new command options that have been 
added
(committed in svn). I'm glad that the the features we've been working on will be
appreciated! Here are the options we have added:
    * --dev (sets paths if you run gitso from the source tree)
    * --listen (starts gitso and starts listening)
    * --connect IP (starts gitso and connects to IP)
    * --list list_file (adds entries to the drop down menu, the file can be a remote
file on a website)
    * --help (displays these options)

Is that indeed what you are asking about? AKA: Did I understand you correctly?

Original comment by gerbe...@gmail.com on 29 Oct 2008 at 5:52

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

*gerberad*: Doesn't look like that to me. I think he wants the same as I do, 
this:

(I didn't find a forum/and-or wiki for gitso.)

I've got a load of servers that I can do whatever with, however, I'm always 
traveling
and need to help people nonetheless; so I'll be in all kind of strange places 
not
being able to open up ports or whatever.

I know it is possible to tunnel all of this through another server (with SSH), 
but
when will it be possible in gitso? The commands for doing this should be 
documented
somewhere, so it's easy to remember and do when you're on the run and still 
need to
give support ;-)

So.   Server setup with SSH-tunnel, Helper connect to Server, Need-supporter 
connect
to Server. Niceness!

Then the data stream is like this:     Need-supporter -> Server -> Helper, 
instead of
directly.

Original comment by odin.om...@gmail.com on 16 Feb 2009 at 11:02

[GoogleCodeExporter]

That is precisely what I had in mind.  I have a static IP for my home network 
but
frequently travel.  With SSH I'm able to connect to my router and open a 
reverse port
forward for VNC reverse connections.  Then those needing assistance connect to 
the
static IP of my router (via convenient name resolution) and regardless of where 
I am,
I get their display.

For now I simply use the following shell script:

#!/bin/bash
CON_PORT=5500

HOST=$1

# kick off the viewer in the background in listen mode
xvncviewer -listen ${CON_PORT} > /dev/null 2>&1 &

# we'll need the viewer's PID for later to clean up
VNCPID=$!

# hook up the forward
ssh ${HOST} -R ${CON_PORT}:127.0.0.1:${CON_PORT}

# kill the viewer
kill ${VNCPID}

Original comment by jamin.co...@gmail.com on 16 Feb 2009 at 12:26

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Neither #7 or #30 are duplicates of this request.  Though, they do appear to be 
duplicates of one another.

This request would encrypt part of the communication (from the firewall to the 
viewer/helper) but only part of the communication.  Having SSL support would 
still be beneficial.

Original comment by jamin.co...@gmail.com on 22 Feb 2010 at 5:33

[GoogleCodeExporter]

Indeed. Thanks for the clarification. I removed the other two.

Original comment by gerbe...@gmail.com on 22 Feb 2010 at 5:47