This page present some questions about OpenMOLE.
OpenMOLE is fully working under OpenJDK 7 and 8. This is the recommended option. You can check which Java version
you're running by typing
in a console.
If you use the closed-source Oracle Java virtual machine (which is probably the case if you are working on Mac or
Windows), you have to install the Java Cryptography Extension (JCE) available at the bottom of this
in order for OpenMOLE to be
JCE is an archive containing a bunch of files that you should replace in the jre/lib/security
directory of your java installation. It enables strong cryptographic algorithms.
Another concern for Mac users
are the concurrent versions of Java that are often present on the same system. Mac
OS ships with a default Java 6 that is not suitable to execute OpenMOLE. You must install Java 7 ir greater and
set the environment variable JAVA_HOME
to the install location on your machine (typically the directory
Old versions of OpenMOLE software and documentation are available here
When your workflow does not start to the remote environment you’re accessing through SSH, you can try these few
steps to identify the problems.
If you are using OpenMOLE in console mode, enable the FINE
level of logging in the console using:
A typical SSH connection error will report as:
FINE: Error in job refresh
net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods
FINE: Error in job refresh
net.schmizz.sshj.transport.TransportException: Incorrect identification: line too long
If you are using the
authentication you might want to double check the user and
password you entered since one of them is more than likely incorrect.
In such a case, we'll have to investigate multiple options, as SSH public key authentications are sensible to
several configuration parameters.
Public key authentication has usually a higher priority than password-based authentication when trying to
connect to a remote server. Thus, when you attempt an SSH connection to the the target environment, if your
client asks you to enter a password (please note that a passphrase is different from a password), then your
public key authentication is not taken into account.
SSH will skip your public key in case of bad configuration. The most common cases of badly configured keypairs
are the following:
- You haven't created an SSH keypair yet (using ssh-keygen). Private keys are usually stored in
~/.ssh/id_rsa or ~/.ssh/id_dsa, and should have a matching ~/.ssh/id_[rd]sa.pub next to them.
- Permissions of your ~/.ssh folder must be set to drwx—— (700 in octal). Also, too permissive home
directories (with write access given to the whole group for instance) might show problematic.
- A ~/.ssh/authorized_keys file must be present on the remote system. It should at least contain a line
matching the content of the ~/.ssh/id_[rd]sa.pub from your base system.
- You entered a passphrase when you generated your SSH keys and cannot remember it. In such a case, it might
be better to generate another keypair.
If you still could not solve your SSH authentication problems, another option is to recreate a public/private
keypair using the
shell command. Store it to a different file to avoid
overwriting the one already in place. You might also want to try a simple
authentication as explained in the SSH section
flag to your ssh
command will give a lot more details on the
communication between your client and the remote server. This will allow you to find out which authentication
is successful as well as the order in which the authentication modes are tried.
If you could not resolve your problems, feel free to post your problem on the mailing-list
If you think your problem is induced by a bug in OpenMOLE, please report the issue exhaustively on our GitHub page