Community
Participate
Working Groups
The last update to jsch was 0.1.54 in September 2016. There have been no bug fixes or other activity on this project since then. It is also not clear if there is anyone maintaining it. Matthias Sohn points out [1] that "there seems to be no known public source code repository containing the project's real source code history including tests. - There are a couple of public jsch repositories [2] but they all seem to contain just snapshots of source archives downloaded from Maven central. None of these repositories contain any jsch tests. - There are the source archives available on Maven Central [3] - and zip archives uploaded on sourceforge [4]." There are a number of other projects that require SSH support, including EGit, PTP, TM, CDT, and others, and we often get questions about bugs and other compatibility issues. There are new ciphers being supported by SSH, but these are not being implemented by jsch. JGit have also been working on supporting Apache Mina [5]. It seems like the time has come to take a hard look at how this is going to be addressed for the platform as a whole. [1] https://www.eclipse.org/lists/cross-project-issues-dev/msg16172.html [2] https://github.com/is/jsch [3] https://search.maven.org/search?q=g:com.jcraft%20AND%20a:jsch&core=gav [4] https://sourceforge.net/projects/jsch/files/jsch/ [5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=520927
See also bug 540728.
A first implementation for EGit/JGit is now available via the EGit nightly update site: http://download.eclipse.org/egit/updates-nightly . (It's opt-in for now; for details see the jgit-dev mailing list thread starting at https://www.eclipse.org/lists/jgit-dev/msg03709.html .) If we want to replace JSch in Platform/Team, we'll need to phase out org.eclipse.jsch. I would think most of the code done for JGit/EGit could be copied and re-used as a starting point. (JGit will need it's own implementation also in the future since it may be used outside of the Eclipse platform; EGit could eventually migrate to whatever Platform/Team provides once we're there.) I think this needs some design thought: org.eclipse.jsch exposes JSch. In JGit I was careful not to expose any upstream interfaces. Upstream sshd evolves whereas JSch was rather static. Exposing upstream interfaces means we'd "inherit" an API evolution and versioning problem in our own new ssh bundle. If we want to avoid exposing upstream interfaces, we'll need to provide our own abstractions. Sometimes wrapper interfaces, sometimes different things. JGit already has a RemoteSession abstraction, and an FtpChanel abstraction. Those could serve as a starting point. JGit has no need for shell access or scp, so it has no abstractions for that. Those would have to be developed. We'd also need some abstraction for user interaction (callback interface for asking for passwords and the like). JGit and sshd have such interfaces, but they probably should not be re-used directly. Developing such abstractions would have to take into account the needs of current clients. For instance, JGit's FtpChannel interface is rather basic. Other ssh clients might also generally need more configurability than what we've provided in JGit. Another point are the SSH2 preferences. Ssh is customarily configured via a configuration file at ~/.shh/config. The current preference page IMO duplicates too much of that in the Eclipse UI: * ssh home directory: if different from ~/.ssh, command-line ssh tools (like git!) may use a different configuration, which is confusing. * Same for the default identity files. * Known hosts: OK, but openssh already knows _two_ default files (known_hosts and known_hosts2), and the user can specify arbitrary files via the UserKnownHostsFile config in ~/.ssh/config. The current preference page only considers known_hosts. * Authentication methods: yes, makes sense. * KEX & MAC methods: makes no sense, configure those in ~/.ssh/config. Much too technical, and depending on what else is present (e.g., Bouncy Castle), the set of available methods may change. * ssh-agent: was that ever functional? C.f. bug bug 179924. Duplicating parts of the ssh config also raises the question of what should take preference: Eclipse preferences or ~/.ssh/config? Also there's the question with which sshd version this would be attempted. For sshd 2.0.0, we had to include quite a few work-arounds in the JGit implementation. sshd 2.2.0 will have some of these issues fixed, but probably not all. If we can manage not to expose sshd interfaces, the sshd version is not a problem. Otherwise it is.
Thanks for the thoughtful comments Thomas! My view is that the configuration question is pretty simple. Eclipse should use/manage the same configuration files used by OpenSSH. I've had tons of questions over the years about why SSH in Eclipse is not picking up configuration options in .ssh. Having them work together would be much more preferable, IMHO. The API issue is trickier, however I would vote for just using their API directly rather than building another layer. This is already what is done with JSch (and many other external APIs), so there is precedent for this. An abstraction can also be problematic depending on the level chosen. Too little and you may as well just go directly with the MINA api, to much and it may be difficult to access all the features you need. If the abstraction is preferred, in addition to that already provided by JGit, there is a remote abstraction layer provided by the org.eclipse.remote project (part of PTP) which provides a complete abstraction, including an implementation for JSch.
(In reply to Greg Watson from comment #3) > The API issue is trickier, however I would vote for just using their API > directly rather than building another layer. The upstream API changes in incompatible ways between minor versions. For instance, if your API exposes something like public class PrivateKeyFilePasswordProvider implements org.apache.sshd.common.config.keys.FilePasswordProvider { ... } your API _will_ break when you move from sshd 2.0.0 or 2.1.0 to sshd > 2.1.0. Same for HostConfigEntry; 2.1.0 removed a public API method. That's why in JGit we either encapsulated interfaces (FilePasswordProvider in particular), or kept them completely private. Maybe look through the changes in sshd since version 2.1.0... See also Matthias' so far unanswered question on the sshd mailing list: https://www.mail-archive.com/users@mina.apache.org/msg06627.html .
I agree it's not ideal, but better than the current situation with JSch. I think let projects decide what they want to do. Would it be possible to extract the JGit encapsulation layer so that projects can insulate themselves to some degree? Some project may just use SSHD APIs directly if you don't mind keeping the implementation up to date. We can move to whatever the latest SSHD version is for each major Eclipse release so at least everyone will be prepared. I don't think there are many projects that would be using this anyway.
