More options for SSH connection

[pmarek]

I need to use a machine as gateway; currently this is done via a

ProxyCommand ssh user@host netcat %h %p

in my ~/.ssh/config.
This works fine for openssh and xpra, but winswitch doesn't use this information (yet).

A similar mechanism would be nice; or, at least, some kind of (pre-)connect command that can build the first hop.

Furthermore, I currently use a TCP remote-port forwarding to get some actions tunneled back; it would be nice if either this, or some other notification mechanism (sending strings) could be done over the same channel.

[Antoine Martin]

Before I get started and write some code, can you confirm that it is ok for this pre-connect command not to contain anything dynamic at all?
ie: no %h or %p in it.
The code can wait for this command to return, or shall it just start it and forget about it?

As for the second part (the back channel), I have working code here that allows the user to choose where URLs are opened: in the existing session (will fire up a new browser or re-use an existing one if one exists), create a new session for it, or forward it back to the client (which is what you asked for).

[pmarek]

Yes - I'd just need a tunnel to a host, with the xpra session tunneled via another SSH session within that one.

Well ... it should start it, wait for it when the connection is broken, and start anew as necessary ...

Well, how would the URLs be forwarded back? Can I configure a local command to be started (on the xpra client side), and how do remote applications know that the URL has to be passed along the xpra side?

I guess a nice feature would be some in-line forward feature - ie. do "xpra in-line :7 open-url ​http://winswitch.org" on the remote side, and have that passed along to the viewing side, where some script (shell, perl, python, whatever) gets started with these parameters ("open-url", "​http://winswitch.org") - that would allow to pass arbitrary other data along as needed, too.

(And, as no DBUS is needed, this is a bit easier for scripting, too).

[Antoine Martin]

Hmmm, that does not answer the question about waiting for the command to return or spawning it in the background.. which one is it? What would your example command be?
As for re-starting it, re-connecting to a server after the connection is lost will cause it to be re-started. (and if we choose the "spawning" approach, the previous instance can also be stopped prior to re-connecting)

URL handling

(this needs to go in a separate ticket)
The command used for opening URLs on the client side is whatever your system default defines it to be - and if you choose to do so, you can use your own scripts there. I would be reluctant to add yet-another-customization option here, since there is little reason for overriding the default system behaviour.

Applications on the remote side have no idea about what happens to the URL they requested to open, we just override the default system behaviour to pass it back to the client.

As for the "xpra-in-line" feature, I don't see any immediate need for it since you can just do:

DISPLAY=:7 xdg-open http://winswitch.org/

to achieve exactly what you requested, in a more generic way.

One would have to be very careful in extending this to allow a remote request to execute scripted commands on the client side.

[pmarek]

Antoine -- I can't give an example command if I don't know whether some TCP port or STDIN/STDOUT gets used for forwarding.

I just need a way to call some commandline before the SSH connection gets built - whether the connection uses STDIN/STDOUT (and so the command is something like "ssh user1@host1 netcat host2 22") or whether some local TCP port is used (so I'd use "ssh user1@host1 sleep 60 -L 7771:host2:22") I don't care about.

Whatever is easier for you.

I think it should be running in the background ... then we can later see that it's aborted and re-start it, if necessary.

URL handling

The URL currently doesn't get used via default desktop mechanisms. I guess I could (re)define the standard-browser ... and yes, that might solve all other data passing issues as well.

I see a (small) disadvantage in that it wouldn't be possible to define different handlers for different remote servers - ie. if clicking on an URL in a program running on one xpra session I might want to start konqueror, but from another xpra session firefox should run - and perhaps chromium for URLs from a third.

That's easily done with a per-connection callback script ... but not for this mechanism.

[Antoine Martin]

"The URL currently doesn't get used via default desktop mechanisms."
I don't understand what that means! Anyway, this feature request has been moved to #170

As for the original purpose of this bug:

• "ssh user1@host1 netcat host2 22" this would allow us to connect to the ssh server on host2 via stdin/stdout of the process, effectively replacing the normal tcp connection with a pipe. I'm pretty sure python-twisted can handle this, but this would require a bit of work and a fair amount of testing (for which I have neither the time nor the setup...)
• "ssh user1@host1 sleep 60 -L 7771:host2:22": this would allow us to point winswitch to localhost:7771 and be done with it. Can you confirm that this works for you?

The first solution is much more elegant and also much safer (host2's ssh is not exposted to anyone outside the process on the local box), but it is also more difficult to implement..

[Antoine Martin]

Will go with option one: I was wrong, this can easily be tested even with localhost and no ssh by using netcat as the interface to the server socket.