I thought there was API at both the SshClient and ClientSession levels to
specific authentication information... both inherit from
org.apache.sshd.client.ClientAuthenticationManager which would seem to
indicate you can do things like #addPasswordIdentity at either level.

I will try to develop a unit test straight from your sample code, but I have
existing code that works with v0.8.0 on these devices and upgrading to 1.2.0
(with some refactoring) seems to break the authentication due to how the
SSHD client sends auth_request right after KEX even if ClientSession#auth
has not been called yet. This is only happening on the Cisco ASA devices...
I have several other devices that are working fine with 1.2.0 and my
existing code, so I'm wondering too if it is something with Cisco's SSH
implementation.

Thanks for the input

-matt



-----Original Message-----
From: elijah baley [mailto:e_ba...@outlook.com] 
Sent: Monday, August 29, 2016 1:03 PM
To: dev@mina.apache.org
Subject: Re: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as
service name 'ssh-connection'?

Can you post some code that shows the client side ? My concern is with


    "Could this be because I am specifying my authentication at the session
level rather than the client level?"

In order to do that correctly one needs to use a
SessionListener#sessionCreated and modify the KEX:

    @Override
    public void sessionCreated(Session s) {
        s.setXXX... - e.g., s.setUserAuthFactories(...);
    }

Anyway, some code snippet showing what you are trying to do and how you set
up the client, connect the session and then authenticate would help diagnose
the issue.
________________________________
From: matthew.w.pi...@wellsfargo.com <matthew.w.pi...@wellsfargo.com>
Sent: Monday, August 29, 2016 6:14 PM
To: dev@mina.apache.org
Subject: RE: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as
service name 'ssh-connection'?

Ok, adding some context here as I may be getting closer to this problem...

So the log/exception in [1] seems to indicate to me that the client/server
are indeed starting the auth exchange properly. However, it seems as though
this exchange is *starting* prior to calling session.auth() so there is no
AuthFuture present. This seems to initiate from ClientSession's override of
#sendSessionEvent where it calls #sendInitialServiceRequest for
KeyEstablished events.

Could this be because I am specifying my authentication at the session level
rather than the client level? So, it's as if the Kex and initial service
request happen so fast, that my code hasn't called session#auth. Is this
possible and/or normal?

[1]
10:48:14.401 [sshd-SshClient[33a630fa]-nio2-thread-9] DEBUG
o.a.s.c.session.ClientSessionImpl -
sendInitialServiceRequest(ClientSessionImpl[xxxxx@/1.2.3.4:22]) Send
SSH_MSG_SERVICE_REQUEST for ssh-userauth
10:48:14.402 [sshd-SshClient[33a630fa]-nio2-thread-9] DEBUG
o.a.sshd.common.io.nio2.Nio2Session - Writing 68 bytes
10:48:14.402 [sshd-SshClient[33a630fa]-nio2-thread-2] DEBUG
o.a.sshd.common.io.nio2.Nio2Session -
handleCompletedWriteCycle(Nio2Session[local=/0:0:0:0:0:0:0:0:51883,
remote=/1.2.3.4:22]) finished writing len=68
10:48:14.474 [sshd-SshClient[33a630fa]-nio2-thread-1] DEBUG
o.a.sshd.common.io.nio2.Nio2Session -
handleReadCycleCompletion(Nio2Session[local=/0:0:0:0:0:0:0:0:51883,
remote=/1.2.3.4:22]) read 52 bytes
10:48:14.475 [sshd-SshClient[33a630fa]-nio2-thread-1] DEBUG
o.a.s.c.session.ClientSessionImpl -
handleServiceAccept(ClientSessionImpl[xxxxx@/1.2.3.4:22])
SSH_MSG_SERVICE_ACCEPT service=ssh-userauth
10:48:14.475 [sshd-SshClient[33a630fa]-nio2-thread-3] DEBUG
o.a.sshd.common.io.nio2.Nio2Session -
handleReadCycleCompletion(Nio2Session[local=/0:0:0:0:0:0:0:0:51883,
remote=/1.2.3.4:22]) read 196 bytes
10:48:14.476 [sshd-SshClient[33a630fa]-nio2-thread-3] DEBUG
o.a.sshd.common.io.nio2.Nio2Session -
exceptionCaught(Nio2Session[local=/0:0:0:0:0:0:0:0:51883,
remote=/1.2.3.4:22]) caught IllegalArgumentException[No current future] -
calling handler
10:48:14.477 [sshd-SshClient[33a630fa]-nio2-thread-3] DEBUG
o.a.s.c.session.ClientSessionImpl -
signalAuthFailure(ClientSessionImpl[xxxxx@/1.2.3.4:22])
type=IllegalArgumentException, signalled=false, message="No current future"
10:48:14.477 [sshd-SshClient[33a630fa]-nio2-thread-3] WARN
o.a.s.c.session.ClientSessionImpl -
exceptionCaught(ClientSessionImpl[xxxxx@/1.2.3.4:22])[state=Opened]
IllegalArgumentException: No current future
10:48:14.483 [sshd-SshClient[33a630fa]-nio2-thread-3] DEBUG
o.a.s.c.session.ClientSessionImpl -
exceptionCaught(ClientSessionImpl[xxxxx@/1.2.3.4:22])[state=Opened] details
java.lang.IllegalArgumentException: No current future
        at
org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(Vali
dateUtils.java:138) ~[sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.util.ValidateUtils.checkTrue(ValidateUtils.java:115)
~[sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.util.ValidateUtils.checkNotNull(ValidateUtils.java:34
) ~[sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.client.session.ClientUserAuthService.process(ClientUserAuthS
ervice.java:167) ~[sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(Abstr
actSession.java:530) ~[sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(Abstrac
tSession.java:463) ~[sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSessio
n.java:1325) ~[sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(Abstr
actSession.java:424) ~[sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageRecei
ved(AbstractSessionIoHandler.java:67) ~[sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Ses
sion.java:285) ~[sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:26
5) [sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:26
2) [sshd-core-1.2.0.jar:1.2.0]
        at
org.apache.sshd.common.io.nio2.Nio2CompletionHandler$1.run(Nio2CompletionHan
dler.java:37) [sshd-core-1.2.0.jar:1.2.0]
        at java.security.AccessController.doPrivileged(Native Method)
[na:1.8.0_92]
        at
org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2Completio
nHandler.java:34) [sshd-core-1.2.0.jar:1.2.0]
        at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
[na:1.8.0_92]
        at sun.nio.ch.Invoker$2.run(Invoker.java:218) [na:1.8.0_92]
        at
sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.j
ava:112) [na:1.8.0_92]
        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
42) [na:1.8.0_92]
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
17) [na:1.8.0_92]
        at java.lang.Thread.run(Thread.java:745) [na:1.8.0_92]
10:48:14.484 [sshd-SshClient[33a630fa]-nio2-thread-3] DEBUG
o.a.s.c.s.h.SessionTimeoutListener -
sessionException(ClientSessionImpl[xxxxx@/1.2.3.4:22])
IllegalArgumentException: No current future
10:48:14.484 [sshd-SshClient[33a630fa]-nio2-thread-3] DEBUG
o.a.s.c.s.h.SessionTimeoutListener -
sessionClosed(ClientSessionImpl[xxxxx@/1.2.3.4:22]) un-tracked
10:48:14.484 [sshd-SshClient[33a630fa]-nio2-thread-3] DEBUG
o.a.s.c.session.ClientSessionImpl -
close(ClientSessionImpl[xxxxx@/1.2.3.4:22]) Closing immediately

-----Original Message-----
From: matthew.w.pi...@wellsfargo.com [mailto:matthew.w.pi...@wellsfargo.com]

Sent: Monday, August 29, 2016 8:16 AM
To: dev@mina.apache.org
Subject: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as
service name 'ssh-connection'?

I am testing sshd 1.2.0 against a bunch of devices that we are currently
accessing just fine using version 0.8.0. I'm running into problems during
the authentication phase when logging into Cisco ASA devices. I am seeing
logs like [1] which appear to indicate that the SSHD library is sending the
SSH_MSG_USERAUTH_REQEUST packet under the 'ssh-connection' service name
which I would expect to see as 'ssh-userauth'. I'm no SSH expert so I may
not understand this correctly, but the ASA devices simply don't respond to
this packet/request and my session login eventually times-out.

When testing the same device with v0.8.0 I see that the login process seems
to jump straight to 'ssh-userauth' after key exchange as indicated by the
logs at [2]. This works fine with the devices and the session executes
normally.

Any ideas here? Is it OK for SSH_MSG_USERAUTH_REQUEST packets to be sent
with service name 'ssh-connection'?

If this is normal, is there a way to work with devices that don't seem to
respond to these packets?

Thanks in advance for any help you can give on this.

[1]
07:51:08.022 [main] DEBUG o.a.s.c.s.ClientUserAuthService -
auth(ClientSessionImpl[xxxx@1.2.3.4:22])[ssh-connection] send
SSH_MSG_USERAUTH_REQUEST for 'none'


[2]
07:43:54.266 [NioProcessor-2] INFO  o.a.s.c.session.ClientSessionImpl -
Received SSH_MSG_NEWKEYS
07:43:54.277 [NioProcessor-2] INFO  o.a.s.c.session.ClientSessionImpl - Send
SSH_MSG_SERVICE_REQUEST for ssh-userauth
07:43:54.490 [NioProcessor-2] DEBUG o.a.s.c.session.ClientSessionImpl -
Received packet SSH_MSG_SERVICE_ACCEPT

Matthew Pitts

Developer
Security Solutions Design & Automation

Wells Fargo Bank | Tel 336.608.3332 | Cell 336.202.3913 | Kernersville, NC |
MAC D9693-010
matthew.w.pi...@wellsfargo.com



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to