Comment 1 Martin Oberhuber 2007-08-03 06:26:28 EDT

When I am understanding this right, the request is that when RSE is embedded in a user's (RCP) application it should be possible to perform all authentication programmatically, such that no user interaction is required any more. I modified the summary accordingly -- old value was:

   Authentication menu has' t displayed for a new remote connection

For the standard RSE user/password dialog, and already having the ISubSystemConfiguration and the given host, this is already possible as follows,
by injecting user and password into the connector service and connect it right
from there without using the subsystem:

IConnectorService cs = ssConfig.getConnectorService(host);
cs.setUserId(userid);
cs.setPassword(userid, password, false, true);
cs.connect(new NullProgressMonitor());

The problem with this for SSH is, that it does not turn off the host key checking, which shows the dialog via a callback (MyUserInfo.promptYesNo() is being called). Currently, there is no API for modifying the behavior of the SshConnectorService, such that 
   * a different UserInfo class could be provided for different kind of
     returning the answer
   * the Jsch session config could be changed in order to perform this:
         java.util.Hashtable config=new java.util.Hashtable();
         config.put("StrictHostKeyChecking", "no");
         session.setConfig(config);

There are also other use cases for making the used Jsch session more configurable, e.g. allowing additional algorightms:
         config.put("cipher.s2c", "aes128-cbc,3des-cbc,blowfish-cbc");

I think the easiest solution for a start, is to turn 
   private static createSession()
into
   protected createSession()
such that users can derive from SshConnectorService, and thus modify the Jsch session before or after creation -- either by supplying a different kind of UserInfo or by changing the JSch config.

What I'm not sure about is, how to turn this "internal" unsupported API into public API that is also supportable, without moving too many classes into API. Supposedly, this will also need to be considered in the context of UI / Non-UI split since we'd like the SSH connector to run fully in non-UI eventually.

Comment 2 Martin Oberhuber 2007-08-03 06:48:50 EDT

I made SshConnectorService.createSession() protected:

[198790] make SSH createSession() protected
    SshConnectorService.java   //for RSE
    SshConnection.java         //for TM Terminal

With this, it is now possible to switch off strict host key checking, by using unsupported "internal" API:

  class MySshConnectorService extends SshConnectorService {
     protected Session createSession(...) {
         Session s = super.createSession(...);
         Hashtable config=new Hashtable();
         config.put("StrictHostKeyChecking", "no");
         session.setConfig(config);
         return config;
     }
  }
  class MySshShellConfig extends SshShellSubSystemConfiguration {
     public IConnectorService getConnectorService(IHost host) {
         return new MySshConnectorService(host);
     }
  }

... and register a specific "My SSH Only" systemType and "My SSH Shell" subsystem configuration.

One thing to consider, though, is that it is generally not recommended to switch off the SSH host key checking, because it protects against the "man in the middle attack". Usually, SSH connections should only be made to known hosts. If the host is unknown, it is potentially impersonated by an intruder -- that's why the dialog is there and not easily removable in the first place. 

The recommended behavior is to allow the dialog, let SSH store it in the known_hosts file if accepted by the user, and from that point on it will no longer be questioned (no more dialogs shown for that particular host).

I would love to hear more about your particular application, what you are trying to accomplish, and why you'd like to avoid the host key check dialog. Eventually, there might also be the possibility to add a Preference setting in Eclipse Platform for disabling host key checking.

Comment 3 Martin Oberhuber 2007-08-03 07:00:56 EDT

(In reply to comment #2)
Actually, for overriding the connector service, there is even a simpler way without modifying the subsystem configuration or system type extension point:
Simply explicitly specify the connector service to use before connecting:

ISystemRegistry sr = RSECorePlugin.getDefault().getSystemRegistry();
ISubSystemConfgiuration ssc = sr.getSubSystemConfiguration("ssh.shells");
ssc.setConnectorService(host, new MySshConnectorService());

from now on, ALL SSH subsystems on the given host will use the modifyied MySshConnectorService, which does not prompt.

But still, I'd like to better understand why exactly you want to suppress that prompt, since there is the risk of a man-in-the-middle attack and it is better to have the user confirm at least once.