Community
Participate
Working Groups
I do not see anyway with RSE to specify custom ports to use. Also, there does not appear to use RSE in a port forwarding environment. I have a situation where the servers I need to access are not directly accessible. I must first connect via SSH to a central server and then use port forwarding to connect to the servers on its network. I have an Eclipse-based UI that is doing all this for me automagically and it all works great. If I need to make an SSH terminal connection to one of these systems, I typically have to do something like: ssh username@localhost:2222 I do not see anyway to direct RSE to use localhost and a custom port number for its SSH access. Is this possible and if not are there any plans to add this feature?
Custom SSH Ports are being addressed by bug #186761. After creating the SSH connection, select an SSH subsystem, right-click > Properties, "Subsystem" page, then change the Port number (by default it shows "0 (First-available)", this is being addressed by bug #195392 and bug #195399). Entering a nonstandard port right in the New Connection Wizard will be addressed by bug #195403. The problem with port forwarding is, that all your connections will have "localhost" as the host name (though with different ports). With File Subsystems, this leads to "merging" all your remote file systems under a single node in the RemoteSystemsTempFiles project; this problem is being tracked by bug #152992. We might want to add generic support for tunnelling to RSE, such that you can define your connection with the "real" hostname and RSE takes care of selecting the intermediate tunnelling server and port for you. This may be addressed in the future. We are very interested in the toolkit for managing SSH port forwardings that you mentioned. Do you think you could contribute this to Open Source?
This port forwarding toolkit is nothing special, and it is fairly tied to our backend product. We basically know whether or not port forwarding is needed, and we know the host it has to forward through. If you take an open such as Open SSH Terminal, we know that we have to create a tunnel and open the Terminal on localhost:localport. I am not sure it would be generally applicable.
A tunnelling framework would also fix bug #142971.
Note that there is a SourceForge project (JSshTunnel) that provides a UI for setting up tunnels with Eclipse/SWT and Jsch: http://sourceforge.net/projects/jsshtunnel/ It's listed as pre-alpha, single developer (Michael Cutler), under GPL, and was registered August 2005. There don't currently seem to be any transactions.
I have tried JSSHTunnel on my Mac OS X machine, and I am getting no where compiling it. When I try to run the jar file, I keep getting the following error... Exception in thread "main" java.lang.NoClassDefFoundError at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.<init>(TransformerFactoryImpl.java:219) at sun.reflect.GeneratedConstructorAccessor4.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at javax.xml.transform.FactoryFinder.newInstance(FactoryFinder.java:100) at javax.xml.transform.FactoryFinder.find(FactoryFinder.java:195) at javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:103) at com.lobstertechnology.jsshtunnel.Util.documentToString(Util.java:68) at com.lobstertechnology.jsshtunnel.Configuration.save(Configuration.java:85) at com.lobstertechnology.jsshtunnel.Configuration.<init>(Configuration.java:72) at com.lobstertechnology.jsshtunnel.Configuration.getInstance(Configuration.java:45) at com.lobstertechnology.jsshtunnel.JSSHTunnel.main(JSSHTunnel.java:64) I admit that I am not a professional at java, so it's entirely possible that I am simply not compiling this correctly, but I have tried it using both Eclipse and java -jar, and both produce exactly the same error. I anyone can shed some light on this, I'd appreciate it. I'd really like to be able to tunnel into my university to work on one of the machines using RSE, but I simply can't because there is no port forwarding in Eclipse via SSH. If anyone has a better idea of how I can make my Mac do the port forwarding without this program, I wouldn't mind that at all either. Thanks. Joshua Soles
If you can SSH into university, you can already use RSE with the "SSH Only" system type. No tunnel needed here, since your SSH connection is the tunnel. If you think you must use a tunnel for whatever reason, you can also set it up on the commandline. For details, see section "SSL Encryption and Firewalls" on http://dsdp.eclipse.org/help/latest/topic/org.eclipse.rse.doc.user/tasks/tbeginlinux.html
SSH port forwarding is useful in a number of usecases other than remote file system browsing and terminal access. One typical situation is remote access to a server (of any kind - http, cvs, svn, database, ...) which is only visible in a LAN. Assuming one has ssh account on a gateway machine for that LAN, it is possible to access internal to the LAN services from outside world by ssh port forwarding. I happen to do this all the time by tools external to Eclipse (ssh on Unix - likes and Putty on Windows). Having such capability in RSE though would be a considerable convenience. At first glance it should not be that difficult to find a way to integrate support for this usecase assuming you find it important enough.
If anybody wants to go ahead coding some port forwarding UI for TM / RSE, the JSch example code may be helpful. There is even an example program for X11 forwarding: http://www.jcraft.com/jsch/examples/X11Forwarding.java http://www.jcraft.com/jsch/examples/PortForwardingL.java http://www.jcraft.com/jsch/examples/PortForwardingR.java It should be quite straightforward to integrate this into RSE, given that any SSH Subsystem can get access to the JSch Session instance via its ConnectorService easily (note: ISshSessionProvider is not yet public API, it's experimental). The JSch mailing list may have more information in its archives: http://sourceforge.net/mailarchive/forum.php?forum_name=jsch-users
Created attachment 174473 [details] A patch to add X11 Portforwaring to the RSE's SSH connections
Hi, I've created a patch (and attached to this defect) as my company needed X11 forwarding in RSE. The patch adds a GUI to the X11 support which is already in the underlying library that handles SSH in RSE. My employer is OK with me submitting this patch and licensing it under EPL.
Hi John-Paul, the patch contains a few lines that are not actually changed, I guess there are spaces added/removed. It would be really great if meaningless changes are removed from the patch, it will make it way easier to read. (In reply to comment #10) > Hi, > > I've created a patch (and attached to this defect) as my company needed X11 > forwarding in RSE. The patch adds a GUI to the X11 support which is already in > the underlying library that handles SSH in RSE. > > My employer is OK with me submitting this patch and licensing it under EPL.
Created attachment 174478 [details] A patch to add X11 Portforwaring to the RSE's SSH connections Hi, just uploaded a new version of the patch which some clean up's as suggested. Cheers, John-Paul.
Hi, Any further comment on the submitted patch? Port forwarding is a very nice feature to have... Cheers,
There are still meaningless changes which I'd like to see removed from the patch. For instance, 1) SshConnectorResources. BUNDLE_NAME is not changed. Why is it in the patch? 2) SshConnectorResources. Empty string is added. 3) SshConnectorService. This string contains typos, should be fixed: * @throws SystemOperationFailedException Thronw if thier is a problem setting up X11 Forwarding 4) SshTerminalShell. private ISshSessionProvider fSessionProvider is removed and then added back with the wrong indentation. Why is that? 5) SshTerminalShell. In constructor we again have the string with fSessionProvider (fSessionProvider=...) removed and added. Same with the fChannel=... string. (In reply to comment #13) > Hi, > > Any further comment on the submitted patch? Port forwarding is a very nice > feature to have... > > Cheers,
Created attachment 176014 [details] A patch to add X11 Portforwaring to the RSE's SSH connections Tidied up the patch with regards to the comments it received.
Created attachment 176015 [details] A patch to add X11 Portforwaring to the RSE's SSH connections
Created attachment 176017 [details] A patch to add X11 Portforwaring to the RSE's SSH connections Fixed typo in patch.
(In reply to comment #17) > Created an attachment (id=176017) [details] > A patch to add X11 Portforwaring to the RSE's SSH connections > > Fixed typo in patch. How is this supposed to work? I created new Linux connection, launched terminal and run xterm in it. I've got the following message: xterm Xt error: Can't open display: xterm: DISPLAY is not set Seems like I am missing something...
So when you create a SSH connection, their should now be two new configuration items. Under the existing keepalive and timeout options, their is now "x-display-location" and "x-port-forwarding". Set x-port-forwarding to the value "true". "x-display-location" hopefully has a sensible default already, but mine is set to the my hostname and screen number. For example "myhost:0". If X is running locally on your machine, you should be able to start X term from a remote connection now. These settings can be entered at creation time of a SSH connection, or my editing a existing connection.
Can we probe whether an x server runs locally? Without an X Server, (e.g. on Windows), the feature won't make sense and should be disabled if possible. When there is a local X server, the feature could always be on by default (like with ssh commandline clients).
(In reply to comment #20) > Can we probe whether an x server runs locally? Without an X Server, (e.g. on > Windows), the feature won't make sense and should be disabled if possible. > > When there is a local X server, the feature could always be on by default (like > with ssh commandline clients). Their probably is away to probe for a X Server though I'm not sure this is something we would want todo. It's quite easy to start a X Server on windows as their are several free and chimerical ones available. I've used the free Xming X Server quite a bit. It's possible that at the time of creating the connection the X server won't be running as the user might start it later when connecting to the remote target. In this case probing for it would probably be the wrong thing todo. If the user does not have a X Server running then they will get a message from the X application to say that it's not running. So their should be some feedback to user of what went wrong.
Do you see any risk with having X forwarding always enabled ? Looks like in the worst case, I just cannot launch any X app on the remote (just like today).
(In reply to comment #22) > Do you see any risk with having X forwarding always enabled ? > > Looks like in the worst case, I just cannot launch any X app on the remote > (just like today). All the SSH clients I've used do disable this by default. Their are some risks, other than the normal of a bit of extra code to try handle the X session. I has someone I know who knows a lot more about this stuff and he sumarised it as the following: "bottom line is, there are lots of excitingly malicious things that could be done with a connection to your X server. Modern OpenSSH tries to mitigate this by default, by asking the X server to construct a special authorisation cookie with restricted powers (in particular, clients using that cookie can't interfere with other clients' windows at all) and then using that for connections forwarded from the SSH server, but this turns out not to work too well because vital things like the X selection mechanism actually _work by_ interfering with other clients' windows, so it's difficult to restrict bad behaviour without also breaking sensible stuff. In any case, that has to be done on purpose by the SSH client (there's a special xauth command line, I think)." So their are some risks that I think are best avoid by keeping it off by default. The patch I created does work with the cookies like modern SSH clients.
Just wondering if people are happy with the patch now? It's hopefully been tidied up quite a bit. Please let me know if their are still problems and I will fix them ASAP. Could the patch be applied now?
(In reply to comment #24) > Just wondering if people are happy with the patch now? It's hopefully been > tidied up quite a bit. Please let me know if their are still problems and I > will fix them ASAP. Could the patch be applied now? I personally cannot make it work. While ssh -Y works fine for me (can run xterm with no problems), I am still getting the error in RSE terminal: "xterm Xt error: Can't open display: localhost:11.0". Maybe I have a weird configuration, but I just cannot apply the patch that doesn't work for me. I am running OpenSuse 11.2 and the remote host I am using is running Ubuntu 9.10.
(In reply to comment #25) > (In reply to comment #24) > > Just wondering if people are happy with the patch now? It's hopefully been > > tidied up quite a bit. Please let me know if their are still problems and I > > will fix them ASAP. Could the patch be applied now? > > I personally cannot make it work. While ssh -Y works fine for me (can run xterm > with no problems), I am still getting the error in RSE terminal: "xterm Xt > error: Can't open display: localhost:11.0". Maybe I have a weird configuration, > but I just cannot apply the patch that doesn't work for me. I am running > OpenSuse 11.2 and the remote host I am using is running Ubuntu 9.10. It's strange that it's now working, I'm also running OpenSuSE 11.2 so we probably have pretty similar setup. I'll get some more testing from friends here and see if they can reproduce the problem. I'll get back to you when I know more....
Here is my test case: 1) Create a Linux connection with all ssh subsystems; 2) Enable X forwarding; 3) Connect; 4) Launch a new terminal using terminal subsystem; 5) Type "xterm" in this terminal.
(In reply to comment #27) > Here is my test case: > 1) Create a Linux connection with all ssh subsystems; > 2) Enable X forwarding; > 3) Connect; > 4) Launch a new terminal using terminal subsystem; > 5) Type "xterm" in this terminal. I've been looking into the problem your having and suspect I've found the cause. Their are two ways of connecting to the X server. Via TCP and local Unix sockets. By default TCP is turned off in OpenSuSE. This is the only supported method of connecting to the X server though. That's because the under laying library only seems to allow TCP connections (If I'm wrong about this, let me know). To enable to TCP in OpenSuSE, you have to edit the file /etc/sysconfig/displaymanager. Look for the setting DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN and set it to "yes". Now hopefully anfter resarting the X server you should be able to create remote SSH connections with X forwarding enabled.
Created attachment 177086 [details] A patch to add X11 Portforwaring to the RSE's SSH connections Fixed some issues with the last patch. 1) Now find the .Xauthority file on windows machines with a network home folder. 2) Better defaults for the display host.
Now I am getting adushist@sb-ubuntu-910:~$ xterm Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: localhost:10.0
(In reply to comment #30) > Now I am getting > adushist@sb-ubuntu-910:~$ xterm > Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: > localhost:10.0 Just out of interest, how many network interfaces do you have? Whats happening I think, is that it's trying to match up what is in the X11 host setting with the values that it finds in the .Xauthority file. That is where the correct cookie is found. Sounds like it's not finding it for some reason. Maybe the code that looks up the cookie still needs some work. You can list the cookies with the command "xauth list". In that list is a list of hostnames and cookies, you could try changing the setting to contain the hostname that is listed by xauth.
(In reply to comment #31) > Just out of interest, how many network interfaces do you have? On which machine? > Whats happening > I think, is that it's trying to match up what is in the X11 host setting with > the values that it finds in the .Xauthority file. That is where the correct > cookie is found. Sounds like it's not finding it for some reason. Maybe the > code that looks up the cookie still needs some work. You can list the cookies > with the command "xauth list". adushist@nik-ubuntu-910:~$ xauth list nik-ubuntu-910/unix:10 MIT-MAGIC-COOKIE-1 912f9a48920903325e02f158ca7b2efc adushist@nik-ubuntu-910:~$ xterm Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: localhost:10.0 adushist@nik-ubuntu-910:~$
Created attachment 178130 [details] A patch to add X11 Portforwaring to the RSE's SSH connections Several bug fixes: * Better default settings. * Works better on systems with multiple interfaces. * Works on windows X Servers such as Xming and cygwin.
(In reply to comment #32) > (In reply to comment #31) > > Just out of interest, how many network interfaces do you have? > > On which machine? > > > Whats happening > > I think, is that it's trying to match up what is in the X11 host setting with > > the values that it finds in the .Xauthority file. That is where the correct > > cookie is found. Sounds like it's not finding it for some reason. Maybe the > > code that looks up the cookie still needs some work. You can list the cookies > > with the command "xauth list". > > adushist@nik-ubuntu-910:~$ xauth list > nik-ubuntu-910/unix:10 MIT-MAGIC-COOKIE-1 912f9a48920903325e02f158ca7b2efc > adushist@nik-ubuntu-910:~$ xterm > Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: > localhost:10.0 > adushist@nik-ubuntu-910:~$ Can you give the latest version of the patch ago. I've fixed up a few things and I'm hopeful that it will work. I've tested a it on a number of different setups and they are now working. You will probably need to delete your previous connection as I've improved the default values.
Unfortunately the latest version of the patch gives me the same error. :(
(In reply to comment #35) > Unfortunately the latest version of the patch gives me the same error. :( This is a real shame as I'm not seeing any errors anymore. I might try put a video together and show it in action. Out of interest, how many network interfaces to you have? Are you using a shared home area (via NFS or something simlar)? What value do you have in the RSE's x-display-location for the ssh connection? and what is retuend my "echo $DISPLAY" on your local machine. So my machine is called "host1.somedomain.com" and my x-display-location is set to "host1:0". My display variable reads ":0.0". For some reason you don't seem to be able to find the cookie value in the .Xauthority file. These can be listed with "xhost lists" command. The x-display-location is used to reference the cookie value from that file.
(In reply to comment #36) > (In reply to comment #35) > > Unfortunately the latest version of the patch gives me the same error. :( > > This is a real shame as I'm not seeing any errors anymore. I might try put a > video together and show it in action. Out of interest, how many network > interfaces to you have? Just one. > Are you using a shared home area (via NFS or something > simlar)? No, I don't. > > What value do you have in the RSE's x-display-location for the ssh connection? linux-klr1:0 > and what is retuend my "echo $DISPLAY" on your local machine. :0 > So my machine is > called "host1.somedomain.com" and my x-display-location is set to "host1:0". My > display variable reads ":0.0". > > For some reason you don't seem to be able to find the cookie value in the > .Xauthority file. These can be listed with "xhost lists" command. The > x-display-location is used to reference the cookie value from that file. I just have no problems with ssh -X/Y which means my setup is not completely broken/weird.
I finally got to trying the patch on our RHEL4 (update 8) system, trying to connect to a local RHEL5.5 system. Patch was applied on top of TM 3.2.1. I was logged in through VNC on "szg-qa-lx1:6.0" and this is where RSE ran on. Trying to connect to szg-qa-lx2. After setting up X port forwarding and connecting, I got this exception: ------------- !ENTRY org.eclipse.rse.ui 4 0 2010-11-16 18:36:15.933 !MESSAGE Unable to parse the X display szg-qa-lx1.wrs.com:6.0 !STACK 0 org.eclipse.rse.services.clientserver.messages.SystemOperationFailedException: Unable to parse the X display szg-qa-lx1.wrs.com:6.0 at org.eclipse.rse.internal.connectorservice.ssh.SshConnectorService.setupX11Display(SshConnectorService.java:210) at org.eclipse.rse.internal.connectorservice.ssh.SshConnectorService.createSession(SshConnectorService.java:152) ------------- Although doing this manually on the commandline worked fine: [mober@szg-qa-lx2-64 ~]$ setenv DISPLAY szg-qa-lx1.wrs.com:6.0 [mober@szg-qa-lx2-64 ~]$ xterm & I'd really like to get this patch integrated for TM 3.3, but it looks like the patch needs just a bit more polishing. Like - couldn't RSE find out automatically that my current DISPLAY is :6.0 and that's likely the display I want the remote to use too? - I'd also expect the patch to work on SSH shells as well, and not only SSH Terminals. - Doing "Launch Terminal" instead of "connect" just prints the errormessage to stdout rather than showing an error dialog.
I'd also like to mention that the original request of this bug was port forwarding in the sense of tunnelling to a remote host through a firewall, which is a different thing than X port forwarding. I have created bug 330385 to track X port forwarding, please make future contributions and comments on that bug. For tunnelling, see the rencent forum discussion on http://www.eclipse.org/forums/index.php?t=msg&th=183904 you can setup an SSH tunnel through your bastion to the remote, using the following ssh commandline command: ssh -l bastionuser bastion -L27120:remote:22 Now, create an RSE SSH-Only connection to host "Localhost" but name it "Remote-through-bastion". Right click on the "Sftp Files" subsystem, and open Properties. On the Subsystem Properties page, change port to 27120. Connect, entering your remote username --> you will get full SSH and File Subsystems to your remote, since the remote will think that the SSH connection has been initiated at the bastion. I tested this on a Linux host and it worked fine - though OpenSSH or Cygwin SSH should also support this on Windows.
I was able to get the patch working using SUSE Linux Enterprise Server 11 as my client machine. In my case, I had to modify XAuthReader.readEntry() to do an extra readString() before getting the port since the following line was returning the local IP instead of a port: String port = readString(in);
(In reply to comment #40) > I was able to get the patch working using SUSE Linux Enterprise Server 11 as my > client machine. In my case, I had to modify XAuthReader.readEntry() to do an > extra readString() before getting the port since the following line was > returning the local IP instead of a port: > > String port = readString(in); Actually, it still isn't working for me as I get "xterm Xt error: Can't open display: localhost:10.0" when I try to open xterm from the terminal.
Thanks Dave for your experiment. Can we continue the X port forwarding discussion on bug 330385? I'd like to re-focus this bug on tunneling. Thanks!
I was asked to add the following use case to this bug: Node Gateway IP-Address remote-port local-port ====== ======= =========== =========== ======= node_a g1 172.16.5.17 110000 11001 node_b g1 172.16.6.17 110000 11002 Eclipse shows the first column in a separate window, and when you double click on a row like node_a, Eclipse opens the port on the host to the target by a simple ssh command, something like this: ssh g1 -L11001:172.16.5.17:11000
Hi There! Local Terminal (plugin from incubation) can handle X since it is local i guess. the problem is that both plugin can not be installed. Why RSE still does not support X11 forfarding - to able to use as a local terminal?
