Community
Participate
Working Groups
RSE should provide services for secure shell (ssh) communications to remote hosts: * ssh remote shell * ssh remote commands * ssh file service (sftp, scp) For providing these services, it should use the com.jcraft.jsch plugin that already comes with Eclipse Platform CVS Team Support.
Created attachment 39404 [details] RSE ssh service (remote shell only) Readme for RSE ssh service 0.2 ------------------------------ The RSE ssh plugin allows to connect the RSE Remote Command View to a remote host through the secure shell (ssh) protocol. This plugin is meant as a proof-of-concept. The code does not have product quality yet, and there are lots of open issues (marked as TODO in the code). But it is functional for setting up an ssh shell connection. __Requirements:__ The ssh service plugin has been tested with RSE M1 candidate (CVS HEAD as of April 25, 2006) and Eclipse 3.2 RC1. The Eclipse Platform Team / CVS feature is needed for the com.jcraft.jsh plugin and the org.eclipse.team.cvs.ui plugin. __Installation:__ You need an Eclipse PDE Workspace with RSE. Then, choose File > Import > Existing Projects > Archive File, to import the ssh service archive. __Usage:__ * Start RSE, create a new system of type "SSH Only". * Select the "Shells" node and choose Contextmenu > Launch Shell. * Enter your username on the remote system. For the password, just enter anything (this is not checked, since ssh has its own method of acquiring password information). * When asked to accept remote host authenticity, press OK. * Enter the correct password for ssh on the remote system. __Known Issues:__ * Entering Password twice should not be required. * Preferences should be used to specify .ssh home directory for storing known hosts and key rings. * After some time, the connection may freeze and need to be disconnected. * command service and file service should be provided in addition to the remote shell service. * Extremely long remote command output may lead to an Exception due to memory exhaustion (ArrayIndexOutOfBoundsException) * "Break" can not be sent to the remote system in order to cancel extremely long-running jobs. * The plugin currently uses some "internal" classes from the org.eclipse.team.cvs.ui plugin. This needs to be cleaned up. * For other internal coding issues, see TODO items in the code.
Thanks. I will try to fit this into M2.
Created attachment 40739 [details] RSE SSH Service 0.2 (includes sftp) SSH Service 0.2 version. Much improved and extended over previous version: * Update to RSE M2 candidate sources (CVS HEAD as of May 9, 2006). * Add sftp files subsystem. * Re-use Team/CVS/ssh2 preferences for ssh2 home and private keys specification Allows to do the ssh login without password if private/public key are set up. * Key management from Team/CVS/ssh2 Preferences can also be used. * Fix status after disconnect operation. * Update about.html.
(In reply to comment #3) This version still does not support ssh commands (interactive shell only). The files subsystem implementation is pretty complete (much more than FTP), and works fine with your private key setup already in use for Team/CVS. If you store your ssh private keys in a non-standard place, use Window > Preferences > Team > CVS > SSh2 Connection Method > General to set the ssh home directory, and private key types to be used.
Note that v0.2 REQUIRES Eclipse-3.2rc3 because only this contains an updated com.jcraft.jsch plugin which supports SftpATTR.isLink().
I've integrated the ssh services plugin into CVS under the following plugins: org.eclipse.rse.connectorservices.ssh org.eclipse.rse.servcies.ssh org.eclipse.rse.subsystems.files.ssh org.eclipse.rse.subsystems.shells.ssh Please let me know if you see any issues with that.
What is the value of splitting the ssh service up into 4 plugins? - it's harder to understand when splitted up - where does the readme.txt belong? - it's taking longer to load on Eclipse startup - you might run into race conditions with plugin activation - when you put the systemTypes extension point into the connectorservice plugin, the icons/ directory must go there too When we think about separation of non-UI components from the UI components, we'd need a non-UI extension point for registering the non-UI services. Currently, services can be instanciated only via the UI-based extension point subsystemConfiguration. Because of that, when the ssh extension gets activated due to connecting an ssh connection, the ssh.subsystems.files and ssh.subsystems.shell plugins are loaded first (both at the same time). They, int turn, activate the connectorservice and services.ssh plugins (both at the same time). Since all services are activated at the same time anyway, it appears to me that they could also all reside in the same plugin. Until we have support for separating UI from non-UI code in a cleaner manner. But then the Manifest.mf in the connectorservice and services.ssh plugins should also avoid any dependencies to Eclipse UI plugins.
The rse.services layer is intended to be modular and provide a minimal API layer below that of subsystems and other more heavy-weight RSE constructs. In the past, I've found that some IBM teams have wanted to exploit the minimal services without having to bring in the rest of RSE. These teams would ideally like to use headless Eclipse and services plugins without any extra overhead. Services lend themselves to being used programmatically and with very little overhead. In addition, the independent services layer allows us to make changes to the higher-level RSE constructs without having to make big adjustments to the services. The connector service exists separately from the services because it involves and depends on higher-level RSE constructs, such as subsystems and hosts. The purpose of the connector service is to connect to some host, whether there is a specific service involved or not. The means of connecting is not always tied to one particular service so there are times when a connector service may make sense to be separate from the associated subsystem configurations. For service-specific protocols like FTP, there doesn't seem to be much use in having a separate connector service since the socket is tightly coupled with the service (files). Other more generic protcols like dstore and ssh can be used for a variety of purposes and as such new services (and corresponding subsystem configurations) can be introduced over time that exploit and reuse the common logic for connecting that comes from the connector service. Suppose a new service could be introduced via ssh for monitoring processes on a host - all one needs to do is add an ssh processes service, it's corresponding subsystem configuration and then the existing connector service could be reused. Please let me know any concerns you have about this organization. I wasn't really thinking about plugin activation when splitting things up this way but rather the reasons mentioned in the previous paragraphs. I hadn't considered race conditions and such so I'd like to hear about the problems that we might encounter with this (for example, you were saying it takes longer to load). The subsystemConfiguration will become non-UI hopefully soon (there's refactoring work underway to do this) so this part should be cleaner but the choice of separating the services from the subsystem configurations was really made to separate the RSE from non-RSE. Regarding the ssh system type, I wasn't sure if you added that just for testing purposes or whether you think that should exist long term. We will need to come up with a way (via preferences, service detection or something else) to decide on which services should be enabled by default - that would provide a way to default the services to be the ssh ones.
Checked in and operational.
ssh is part of RSE SDK now. Plugin splitting discussion is continued in bug 142475 now. Setting bug closed.
[target cleanup] 1.0 M2 was the original target milestone for this bug
