Result, was : [VOTE] MINA 2.0.14 release

Hi guys, I'm closing the vote for the MINA 2.0.14 release. We have had 6 +1 (4 binding votes): Ashish, Guillaume, Jeff, Maria (non binding), Mondain (non binding), and me. Many thanks to the voters ! I'll update the web site, push the packages and announce the release in the coming 24h.

RE: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as service name 'ssh-connection'?

Ok... I'm back :)... and I think I'm on to something. I was able to replicate the problem I'm seeing using basic/manual SshClient code [1] by introducing a sleep between connect().verify() and calling any auth methods. After enabling TRACE logging and weeding through it here's where I think the

RE: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as service name 'ssh-connection'?

Ok, makes sense... I have managed to simplify my test down to raw SshClient/session creation and it appears to get past the auth phase on the ASAs. It must be something with how my code is doing the client/session setup/management but it's interesting that it is only showing on the ASAs... maybe

Re: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as service name 'ssh-connection'?

Hard to say without seeing the code and debugging it From: matthew.w.pi...@wellsfargo.com Sent: Monday, August 29, 2016 10:41 PM To: dev@mina.apache.org Subject: RE: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as

RE: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as service name 'ssh-connection'?

Ok, thanks. This helps me understand the context better. So is the java.lang.IllegalArgumentException I detailed not an issue? -Original Message- From: elijah baley [mailto:e_ba...@outlook.com] Sent: Monday, August 29, 2016 2:10 PM To: dev@mina.apache.org Subject: Re: SSHD v1.2.0 client

Re: [VOTE] MINA 2.0.14 release

+1 On 29 Aug 2016 9:19 p.m., "Emmanuel Lécharny" wrote: > Le 29/08/16 à 18:24, Mondain a écrit : > > Not that I count, but +1 from me :) > > All votes count ! > >

Re: [VOTE] MINA 2.0.14 release

Le 29/08/16 à 18:24, Mondain a écrit : > Not that I count, but +1 from me :) All votes count !

Re: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as service name 'ssh-connection'?

" 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. " As far as I can tell this is entirely according to the standard + should pose no problem to the server - all it does is indicate to the server

Re: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as service name 'ssh-connection'?

Indeed one can use the client and/or the session for authentication details. If placing the authentication details on the client, then all sessions will use the same password for all users - which is not what is usually meant. The use-case for placing authentication data on the client rather

RE: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as service name 'ssh-connection'?

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

Re: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as service name 'ssh-connection'?

Here is how the code should work (there are other options but this is the simplest): SshClient client = SshClient.setupDefaultClient(); client.set... - override if needed some defaults try (ClientSession session = client.connect(user, host,

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:

RE: SSHD v1.2.0 client sending SSH_MSG_USERAUTH_REQUEST packet as service name 'ssh-connection'?

More of my own discoveries... I can confirm that by simply applying my authentication credentials at the SshClient-level rather than the session level that the login and session execute normally. So, why does sendInitialServiceRequest seem to prevent session-level authentication from working

Re: [VOTE] MINA 2.0.14 release

Not that I count, but +1 from me :) On Mon, Aug 29, 2016 at 9:25 AM Guillaume Nodet wrote: > +1 > > 2016-08-25 16:16 GMT+02:00 Emmanuel Lécharny : > > > Hi, > > > > Here is a new release, MINA 2.0.14. It fixes many issues, some of them > > being a real

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

Re: [VOTE] MINA 2.0.14 release

+1 2016-08-25 16:16 GMT+02:00 Emmanuel Lécharny : > Hi, > > Here is a new release, MINA 2.0.14. It fixes many issues, some of them > being a real burden for SSHD DIRMINA-1021). Some patches were also applied > (thanks to Maria Petridan). > > Here are the fixed issues : > >

Re: [VOTE] MINA 2.0.14 release

Anyone else ? On Thu, Aug 25, 2016 at 11:49 PM, Ashish wrote: > +1 > > Executed the build. Looks good, all test cases passed > > On Thu, Aug 25, 2016 at 7:16 AM, Emmanuel Lécharny > wrote: > > Hi, > > > > Here is a new release, MINA 2.0.14. It

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