Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 345329 - Create RemoteTools connection over Proxy Server
Summary: Create RemoteTools connection over Proxy Server
Status: RESOLVED FIXED
Alias: None
Product: PTP
Classification: Tools
Component: Remote (show other bugs)
Version: 5.0   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 1.1   Edit
Assignee: Roland Schulz CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-10 15:52 EDT by Roland Schulz CLA
Modified: 2015-01-06 14:54 EST (History)
1 user (show)

See Also:


Attachments
Command Proxy (11.44 KB, application/x-zip-compressed)
2011-05-11 17:06 EDT, Roland Schulz CLA
no flags Details
Suggestion for Proxy (13.36 KB, image/png)
2011-05-11 21:59 EDT, Roland Schulz CLA
no flags Details
Screenshot of whole dialog (21.83 KB, image/png)
2011-05-12 05:57 EDT, Roland Schulz CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roland Schulz CLA 2011-05-10 15:52:02 EDT

    
Comment 1 Roland Schulz CLA 2011-05-10 17:59:43 EDT
Currently it is not possible to create a RemoteTools connection to a machine which is behind a firewall. As a workaround, it is possible to create a PortForwarding outside of Eclipse. But the IDE shouldn't force the user to do this outside.

I suggest we add a proxy option to the advanced settings part of the "Target Environment Configuration" dialog (the one shown when clicking on new connection). I see 3 options of how to support proxies. 

1) Port forwarding
2) ProxyCommand
3) Socks/HTTP Proxy

For port forwarding the dialog should allow to select a RemoteTools connection to the proxy(and create a new one). This connection would be created first and port forwarding set up to the final (/next hop). Than the connection to the final host could be established. Port forwarding might not be allowed in secure environments.

ProxyCommand would work as the same option of the command line ssh. Any command is possible. This allows tunneling through HTTP, Socks, ssh. But the user needs to know how to do it and has the proxy command installed. It is possible to implement this using the Jsch Proxy Interface.

Jsch has Proxy classes for HTTP and Socks. Thus all we would need to do is add this to the dialog.

Each has advantages and disadvantages:
Multi-Hop: Only 1+2
SSH Proxy: Only 1+2
Non-SSH Porxy: Only 2+3
Pure Java/No dependency: Only 1+3
User friendly: Only 1+3
Support for paranoid environments: Only 2

I vote for 2 because it supports all protocols and any weird combination (e.g. multi-hop with HTTP+ssh and no port-forwarding allowed). But since it is not user friendly I suggest we also support 1 and/or 3. 

If we can get this done quickly, could this still go into Indigo? This is high priority for us because direct SSH isn't allowed at ORNL anymore.
Comment 2 Roland Schulz CLA 2011-05-10 19:16:39 EDT
I just realized that SOCKS proxy is already supported by configuring it in "Network Connection". I suggest we add a "See 'Network configuration' to configure proxy support" to the "Target Environment Configuration" dialog. Do we also support HTTP Proxy when it is configured in 'Network configuration'? 

This would take care of option 3. I would still like to add Option2 (and possible 1) to the dialog. Because SOCKS proxy still requires to set up the proxy outside of eclipse in most cases.
Comment 3 Greg Watson CLA 2011-05-11 02:44:16 EDT
I've already started working on a new dialog to support option 1 since that seems the simplest to implement. I don't think there's a problem getting this into Indigo, its really a matter of getting time to work on it. If you can help out we might have a better chance of getting it ready in time.

I was planning to provide two sets of host/username/password(key) fields, one for the intermediate host, and one for the destination host. I was going to call this dialog org.eclipse.ptp.utils.ui.swt.MultiAuthenticationFrame (the current version is AuthenticationFrame). I was going to replace the local/remote radio button with single/multi host that would hide/show the second set of user information. It would also require changes to various parts of org.eclipse.ptp.remotetools.environment.generichost to add the extra configuration information and port forwarding.

I can commit what I've done so far (not much) if you'd like.
Comment 4 Roland Schulz CLA 2011-05-11 12:30:26 EDT
(In reply to comment #3)
> I've already started working on a new dialog to support option 1 since that
> seems the simplest to implement. 
We need option 2. So I'm mostly interested to help adding that. I think both option 1 and 2 should be relative quick to implement. So I hope I can help with both.

> I was planning to provide two sets of host/username/password(key) fields, one
> for the intermediate host, and one for the destination host. I was going to
> call this dialog org.eclipse.ptp.utils.ui.swt.MultiAuthenticationFrame (the
> current version is AuthenticationFrame). 
Would the AuthenticationFrame keep existing?

> I was going to replace the
> local/remote radio button with single/multi host that would hide/show the
> second set of user information. 
What is the advantage of this over a "Connection" drop-down + a new connection button?

I suggest to add the following:
Add a radio button group called "Proxy" with three options:
* No Proxy (default)
* Proxy Connection : drop-down, new-button
* Proxy Command: Text box

It probably would be nice to also add a link to 'Network configuration' for setting up a socks proxy. I'm not sure whether it is better to add this on the "Simplified" or only on the "Advanced" frame.

BTW: What is the reason for the localhost radio button? I see how this is convenient for testing, but I doubt that the user wants to use it. I think this should be removed (at least when not in debug mode) to simplify the frame.


> It would also require changes to various parts
> of org.eclipse.ptp.remotetools.environment.generichost to add the extra
> configuration information and port forwarding.
> 
> I can commit what I've done so far (not much) if you'd like.
Yes I'll take a look. Patch might be better (since it is not ready).
Comment 5 Roland Schulz CLA 2011-05-11 17:06:46 EDT
Created attachment 195436 [details]
Command Proxy

The implementation for the Command Proxy

The attached proxy contains:
  - The Command Proxy itself
  - A test class (copied from jsch example ViaHTTP)
  - StreamCopyThread copied from Jgit

The implementation is complete. Missing is the UI.
Thus as soon as we agree on how the UI should look like it can be added.

StreamCopyThread: The package where the proxy is going shouldn't have a dependency on jgit. Is it OK to copy this class? (I asked you basically the same question regarding the Egit class a few minutes ago per mail) I think it is very useful utility class. Or do we already have some StreamCopyThread class?
Comment 6 Roland Schulz CLA 2011-05-11 21:59:01 EDT
Created attachment 195452 [details]
Suggestion for Proxy

Suggestion how the proxy group in the dialog could look like
Comment 7 Greg Watson CLA 2011-05-12 04:02:05 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > I've already started working on a new dialog to support option 1 since that
> > seems the simplest to implement. 
> We need option 2. So I'm mostly interested to help adding that. I think both
> option 1 and 2 should be relative quick to implement. So I hope I can help with
> both.
> 
> > I was planning to provide two sets of host/username/password(key) fields, one
> > for the intermediate host, and one for the destination host. I was going to
> > call this dialog org.eclipse.ptp.utils.ui.swt.MultiAuthenticationFrame (the
> > current version is AuthenticationFrame). 
> Would the AuthenticationFrame keep existing?

I was going to keep AuthenticationFrame. It sounds like the new fame should be called ProxyAuthenticationFrame rather than Multi...

> 
> > I was going to replace the
> > local/remote radio button with single/multi host that would hide/show the
> > second set of user information. 
> What is the advantage of this over a "Connection" drop-down + a new connection
> button?

What "connections" would be displayed in this drop down? Would these be remote tools connections? 
What dialog would be shown when the user selects "new connection"? 
Where would this proxy information be displayed on the frame? In an "advanced" section?

> 
> I suggest to add the following:
> Add a radio button group called "Proxy" with three options:
> * No Proxy (default)
> * Proxy Connection : drop-down, new-button
> * Proxy Command: Text box
> 
> It probably would be nice to also add a link to 'Network configuration' for
> setting up a socks proxy. I'm not sure whether it is better to add this on the
> "Simplified" or only on the "Advanced" frame.
> 
> BTW: What is the reason for the localhost radio button? I see how this is
> convenient for testing, but I doubt that the user wants to use it. I think this
> should be removed (at least when not in debug mode) to simplify the frame.

I agree. I'm not sure why it's there other than to make it simpler to select the localhost. I thought I had already removed it, but I must have been dreaming. :-)
Comment 8 Roland Schulz CLA 2011-05-12 05:01:45 EDT
(In reply to comment #7)
> (In reply to comment #4)
> > (In reply to comment #3)

> > > I was going to replace the
> > > local/remote radio button with single/multi host that would hide/show the
> > > second set of user information. 
> > What is the advantage of this over a "Connection" drop-down + a new connection
> > button?
> 
> What "connections" would be displayed in this drop down? Would these be remote
> tools connections? 
yes
> What dialog would be shown when the user selects "new connection"? 
I intended to open another ProxyAuthenticationFrame. This assumes it is possible to open more than one at a time (haven't tested it).
Comment 9 Roland Schulz CLA 2011-05-12 05:57:05 EDT
Created attachment 195481 [details]
Screenshot of whole dialog

Maybe we can clean up the dialog a bit while we are working at it. The Authentication text fields are not very well aligned in the current dialog. 

I redesigned it in WindowBuilder. What is the resason to use org.eclipse.ptp.utils.ui.swt.Frame for this dialog?
Comment 10 Greg Watson CLA 2011-05-12 08:17:02 EDT
(In reply to comment #9)
> Created attachment 195481 [details]
> Screenshot of whole dialog

Looks good.

> 
> Maybe we can clean up the dialog a bit while we are working at it. The
> Authentication text fields are not very well aligned in the current dialog.
> 
> I redesigned it in WindowBuilder. What is the resason to use
> org.eclipse.ptp.utils.ui.swt.Frame for this dialog?

Looks like it's just a base class, but there's no requirement to use it if it's not needed.
Comment 11 Roland Schulz CLA 2011-11-09 20:32:05 EST
I just realized that we actually already also support HTTPS proxy. So we should have a link to the network properties with an explanation that both HTTPS and SOCKS work for SSH.
Comment 12 Roland Schulz CLA 2014-09-30 00:39:14 EDT
Uploaded a patch: https://git.eclipse.org/r/34086
Comment 13 Greg Watson CLA 2015-01-06 14:54:22 EST
Changed component and version to fit final patch.