Bug 1192072 - kie-config-cli: Cannot connect to server running on IBM WebSphere
Summary: kie-config-cli: Cannot connect to server running on IBM WebSphere
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.0.3
Hardware: x86_64
OS: All
high
high
Target Milestone: ER6
: 6.1.0
Assignee: manstis
QA Contact: Radovan Synek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-12 15:16 UTC by Pavel Zeman
Modified: 2020-03-27 20:04 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 20:04:42 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Server log with authentication failure (15.66 KB, text/plain)
2015-02-12 21:22 UTC, Pavel Zeman
no flags Details

Description Pavel Zeman 2015-02-12 15:16:45 UTC
Description of problem: I'm running BRMS business central on IBM WebSphere 8.5.5.4 and I cannot connect to the server using kie-config-client. It seems, that the SSH server provides an invalid certificate:

Exception in thread "main" java.lang.RuntimeException: org.eclipse.jgit.api.errors.TransportException: ssh://bcadmin@localhost:8001/system: verify: false
        at org.uberfire.java.nio.fs.jgit.util.JGitUtil.cloneRepository(JGitUtil.java:217)
        at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.newFileSystem(JGitFileSystemProvider.java:541)
        at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:117)
        at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:83)
        at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:254)
        at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:244)
        at org.kie.config.cli.command.impl.CloneGitRepositoryCliCommand.execute(CloneGitRepositoryCliCommand.java:68)
        at org.kie.config.cli.CmdMain.main(CmdMain.java:78)
Caused by: org.eclipse.jgit.api.errors.TransportException: ssh://bcadmin@localhost:8001/system: verify: false
        at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
        at org.eclipse.jgit.api.CloneCommand.fetch(CloneCommand.java:178)
        at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:125)
        at org.uberfire.java.nio.fs.jgit.util.JGitUtil.cloneRepository(JGitUtil.java:196)
        ... 7 more
Caused by: org.eclipse.jgit.errors.TransportException: ssh://bcadmin@localhost:8001/system: verify: false
        at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:142)
        at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:121)
        at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:248)
        at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:147)
        at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
        at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
        at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1111)
        at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
        ... 10 more
Caused by: com.jcraft.jsch.JSchException: verify: false
        at com.jcraft.jsch.Session.connect(Session.java:309)
        at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:116)
        ... 17 more


To verify the problem, I tried connecting to the server using ssh client and the ssh client complains about invalid server key:
$ ssh bcadmin@localhost -p 8001
key_verify: incorrect signature
key_verify failed for server_host_key


I did a little research and the problem seems to be related to Apache SSHD run using IBM JVM. So I created a simple testcase to verify this hypothesis:

public class SSHD {

  public static void main(String[] args) throws IOException {
    SshServer sshd = SshServer.setUpDefaultServer();
    sshd.setPort(2222);
    sshd.setKeyPairProvider(new SimpleGeneratorHostKeyProvider("c:\\Temp\\hostkey.ser"));
    sshd.setPasswordAuthenticator(new PasswordAuthenticator() {
      public boolean authenticate(String arg0, String arg1, ServerSession arg2) {
        return true;
      }
    });
    sshd.setShellFactory(new ProcessShellFactory(new String[] { "cmd.exe"}));
    sshd.start();
  }

}

When I run this with the latest version of Apache SSHD (0.13.0) using Oracle Java (1.7.0_71), a key is generated and I can successfully connect using ssh client. However, when I run the same testcase using IBM Java (1.7.0, build 2.6) after deleting the previous generated key, a new key is generated, but an attempt to connect using ssh client fails with 
key_verify: incorrect signature
key_verify failed for server_host_key

I've also tried generating a key using Oracle Java and then using it with IBM Java. In this case, the testcase works as expected and I'm able to connect.


Version-Release number of selected component (if applicable):
JBoss BRMS 6.0.3
IBM Java 1.7.0 build 2.6
IBM WebSphere 8.5.5.4

How reproducible:
Install business central on IBM WebSphere and try to connect using kie-config-cli.

Steps to Reproduce:
See above.

Actual results:
Connection attempt fails with an exception related to invalid server key.

Expected results:
Connection attempt succeeds.

Additional info:

Comment 2 Maciej Swiderski 2015-02-12 17:30:47 UTC
IBM JDK requires to use bouncy castle for Apache SSHD and to use that you can configure it as follows:
- set customproperty for WebSphere server instance:
org.apache.sshd.registerBouncyCastle = true

- Configure shared library that will provide bouncy castle library (tested with bcprov-jdk16-1.46.jar)

- Reference shared library with bouncy castle to the business central application on war level (actually any level should work as it uses single class loader per application)

- remove the .security folder from previous runs

- restart WebSphere application server

from now on close over SSH should work as expected. Could you please update bz after applying these changes?

Comment 3 Pavel Zeman 2015-02-12 21:21:17 UTC
Thanks a lot, Maciej. The server now generates a valid key. However, I'm still not able to log in because of authentication failure. My setup is as follows:
- My username is bcadmin.
- In WebSphere configuration, bcadmin is assigned to group admin.
- In WAR configuration, group admin is mapped to role admin.

I'm able to log in to business central using the user bcadmin and I'm able to manage repositories and organizational units using this user. However, when I try to use this user in kie-config-cli, it fails with the following exception:
Exception in thread "main" java.lang.RuntimeException: org.eclipse.jgit.api.errors.TransportException: ssh://bcadmin@localhost:8001/system: Auth fail
        at org.uberfire.java.nio.fs.jgit.util.JGitUtil.cloneRepository(JGitUtil.java:217)
        at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.newFileSystem(JGitFileSystemProvider.java:541)
        at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:117)
        at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:83)
        at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:254)
        at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:244)
        at org.kie.config.cli.command.impl.CloneGitRepositoryCliCommand.execute(CloneGitRepositoryCliCommand.java:68)
        at org.kie.config.cli.CmdMain.main(CmdMain.java:78)
Caused by: org.eclipse.jgit.api.errors.TransportException: ssh://bcadmin@localhost:8001/system: Auth fail
        at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
        at org.eclipse.jgit.api.CloneCommand.fetch(CloneCommand.java:178)
        at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:125)
        at org.uberfire.java.nio.fs.jgit.util.JGitUtil.cloneRepository(JGitUtil.java:196)
        ... 7 more
Caused by: org.eclipse.jgit.errors.TransportException: ssh://bcadmin@localhost:8001/system: Auth fail
        at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:142)
        at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:121)
        at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:248)
        at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:147)
        at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
        at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
        at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1111)
        at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
        ... 10 more
Caused by: com.jcraft.jsch.JSchException: Auth fail
        at com.jcraft.jsch.Session.connect(Session.java:484)
        at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:116)
        ... 17 more

Please find attached the server log.

Do I need to configure anything else, so that I'm able to log in to kie-config-cli?

Comment 4 Pavel Zeman 2015-02-12 21:22:10 UTC
Created attachment 991151 [details]
Server log with authentication failure

Comment 5 Maciej Swiderski 2015-02-13 10:39:41 UTC
for that you need to set the JAAS login domain it shall use to authenticate and that is done via another system property (custom property as called in WAS) for JVM:

org.uberfire.domain = WSLogin

this is the default one so if you have configured security in different way then use proper security domain for it.

Comment 6 Pavel Zeman 2015-02-13 12:07:04 UTC
I've added the system property, restarted the server and according to the server log, I'm successfully authenticated:
DEBUG o.a.s.s.s.ServerUserAuthService - Authentication succeeded

However, kie-config-cli fails with the following exception:
Exception in thread "main" java.lang.RuntimeException: org.eclipse.jgit.api.errors.InvalidRemoteException: Invalid remote: origin
        at org.uberfire.java.nio.fs.jgit.util.JGitUtil.cloneRepository(JGitUtil.java:217)
        at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.newFileSystem(JGitFileSystemProvider.java:541)
        at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:117)
        at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:83)
        at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:254)
        at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:244)
        at org.kie.config.cli.command.impl.CloneGitRepositoryCliCommand.execute(CloneGitRepositoryCliCommand.java:68)
        at org.kie.config.cli.CmdMain.main(CmdMain.java:78)
Caused by: org.eclipse.jgit.api.errors.InvalidRemoteException: Invalid remote: origin
        at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:136)
        at org.eclipse.jgit.api.CloneCommand.fetch(CloneCommand.java:178)
        at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:125)
        at org.uberfire.java.nio.fs.jgit.util.JGitUtil.cloneRepository(JGitUtil.java:196)
        ... 7 more
Caused by: org.eclipse.jgit.errors.NoRemoteRepositoryException: ssh://bcadmin@localhost:8001/system: Invalid credentials.
        at org.eclipse.jgit.transport.TransportGitSsh.cleanNotFound(TransportGitSsh.java:194)
        at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:274)
        at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:147)
        at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
        at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
        at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1111)
        at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
        ... 10 more

This is the same exception as in https://bugzilla.redhat.com/show_bug.cgi?id=1163840, but I'm using BRMS version 6.0.3. 

I also tried deleting the .niogit directory and restarted the server. The .niogit directory including the system repository was successfully recreated, but kie-config-cli now fails with another exception:
Exception in thread "main" java.lang.RuntimeException: org.eclipse.jgit.api.errors.InvalidRemoteException: Invalid remote: origin
        at org.uberfire.java.nio.fs.jgit.util.JGitUtil.cloneRepository(JGitUtil.java:217)
        at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.newFileSystem(JGitFileSystemProvider.java:541)
        at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:117)
        at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:83)
        at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:254)
        at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:244)
        at org.kie.config.cli.command.impl.CloneGitRepositoryCliCommand.execute(CloneGitRepositoryCliCommand.java:68)
        at org.kie.config.cli.CmdMain.main(CmdMain.java:78)
Caused by: org.eclipse.jgit.api.errors.InvalidRemoteException: Invalid remote: origin
        at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:136)
        at org.eclipse.jgit.api.CloneCommand.fetch(CloneCommand.java:178)
        at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:125)
        at org.uberfire.java.nio.fs.jgit.util.JGitUtil.cloneRepository(JGitUtil.java:196)
        ... 7 more
Caused by: org.eclipse.jgit.errors.NoRemoteRepositoryException: ssh://bcadmin@localhost:8001/system: not found.
        at org.eclipse.jgit.transport.BasePackConnection.noRepository(BasePackConnection.java:263)
        at org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefsImpl(BasePackConnection.java:198)
        at org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:176)
        at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:269)
        at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:147)
        at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
        at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
        at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1111)
        at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
        ... 10 more

Comment 7 Maciej Swiderski 2015-02-13 17:07:24 UTC
as you pointed out, that bz (https://bugzilla.redhat.com/show_bug.cgi?id=1163840) is required as well otherwise it will fail to clone the repo. That means you need to wait for 6.1 to be released.

since there is no more code changes required moving this to modified so it gets retested.

Comment 8 Pavel Zeman 2015-02-13 22:28:48 UTC
But https://bugzilla.redhat.com/show_bug.cgi?id=1163840 is reported for 6.1. Moreover, when I install 6.0.3 on JBoss EAP, kie-config-cli works as expected. This would mean, that https://bugzilla.redhat.com/show_bug.cgi?id=1163840 is a WebSphere-specific bug, which is not. And how do you explain, that after recreating the repository the exception changes?

And let me ask a few more questions:
- Can you update the BRMS WebSphere installation guide to contain the additional information mentioned in this bug? Or should I submit a separate bug?
- As there is a separate BRMS WAR for WAS, can you add the bouncy castle JAR to this WAR, so that there is no need to download it separately and to setup shared libraries?

And I also found this exception in the WAS FFDC. It is generated, when I try to connect from kie-config-cli:
[13.2.15 23:24:23:135 SEÈ]     FFDC Exception:javax.naming.ConfigurationException SourceId:com.ibm.ws.naming.java.JavaNameSpaceManagerImpl.getJavaNameSpace ProbeId:537 Reporter:java.lang.Class@5d594d5e
javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names.
	at com.ibm.ws.naming.java.javaURLContextImpl.throwExceptionIfDefaultJavaNS(javaURLContextImpl.java:522)
	at com.ibm.ws.naming.java.JavaNameSpaceManagerImpl.getJavaNameSpace(JavaNameSpaceManagerImpl.java:100)
	at com.ibm.ws.naming.java.javaURLContextRoot.getContextIfUrlName(javaURLContextRoot.java:668)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookupExt(javaURLContextRoot.java:463)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:370)
	at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
	at javax.naming.InitialContext.lookup(InitialContext.java:436)
	at javax.naming.InitialContext.doLookup(InitialContext.java:176)
	at org.uberfire.commons.async.SimpleAsyncExecutorService.getDefaultInstance(SimpleAsyncExecutorService.java:30)
	at org.uberfire.java.nio.fs.jgit.daemon.ssh.BaseGitCommand.start(BaseGitCommand.java:102)
	at org.apache.sshd.server.channel.ChannelSession.handleExec(ChannelSession.java:409)
	at org.apache.sshd.server.channel.ChannelSession.handleRequest(ChannelSession.java:291)
	at org.apache.sshd.server.channel.ChannelSession$ChannelSessionRequestHandler.process(ChannelSession.java:548)
	at org.apache.sshd.server.channel.ChannelSession$ChannelSessionRequestHandler.process(ChannelSession.java:546)
	at org.apache.sshd.common.channel.AbstractChannel.handleRequest(AbstractChannel.java:96)
	at org.apache.sshd.common.session.AbstractConnectionService.channelRequest(AbstractConnectionService.java:261)
	at org.apache.sshd.common.session.AbstractConnectionService.process(AbstractConnectionService.java:139)
	at org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:396)
	at org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:295)
	at org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:717)
	at org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:277)
	at org.apache.sshd.common.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:54)
	at org.apache.sshd.common.io.mina.MinaService.messageReceived(MinaService.java:95)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:716)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
	at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:715)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:668)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:657)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1141)
	at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
	at java.lang.Thread.run(Thread.java:784)

Thank you.

Comment 9 Maciej Swiderski 2015-02-19 15:42:20 UTC
confirmed that this is still an issue caused by lack of proper mechanism to fetch user roles and then authorization manager disallows access to repository.

when it comes to bouncy castle I believe there are some licensing/export rights issue about distributing security/crypto libraries and thus it's not allowed to be done so.

Comment 11 Radovan Synek 2015-03-23 12:25:05 UTC
Verified with BRMS-6.1.0.ER6 that after adding bouncy castle provider as a shared library, kie-config-cli can connect and operate with BRMS Business Central deployed on WebSphere AS.

Comment 12 Pavel Zeman 2015-03-24 20:48:22 UTC
Please, don't forget to mention the bouncy castle provider and JAAS login domain configuration in the WebSphere installation guide.

Comment 13 Radovan Synek 2015-03-25 06:52:33 UTC
(In reply to Pavel Zeman from comment #12)
> Please, don't forget to mention the bouncy castle provider and JAAS login
> domain configuration in the WebSphere installation guide.

Please see bug 1204802 regarding the documentation update.


Note You need to log in before you can comment on or make changes to this bug.