mina-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: SSHD SshClient - should I reuse the same instance for multiple independent sessions?
Date Mon, 25 Aug 2014 13:01:46 GMT
Would you mind creating a JIRA and attaching your patch to it ?
That's the usual way for patches and it's easier to keep track of those.

Guillaume


2014-08-25 14:29 GMT+02:00 <Matthew.W.Pitts@wellsfargo.com>:

> Thank you for the input. I know what you mean about using
> addPasswordIdentity even for keyboard-interactive. But unfortunately, some
> of the devices we connect to do not use the standard 'password:' prompt. So
> the logic inside AuthUserKeyboardInteractive that just uses the available
> password identities doesn't pass the prompt check.
>
> Maybe another avenue would be to provide an 'allowed password prompts'
> property/option that can somehow be passed into
> AuthUserKeyboardInteractive. Then I could customize the prompts that will
> pass the check.
>
> If you get a chance, please check out my patch on the dev list that adds
> per-session UserInteractive support. I would greatly appreciate any
> feedback on it.
>
> Regards,
> -matt
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@apache.org]
> Sent: Sunday, August 24, 2014 8:11 AM
> To: users@mina.apache.org
> Subject: Re: SSHD SshClient - should I reuse the same instance for
> multiple independent sessions?
>
> I think it would be better to use a single SshClient.  All the threading /
> resource management has been designed with this use case, that's why you
> end up with lots of threads if you create a lot of those objects.
>
> For the authentication, I suppose you're not really prompting the user for
> the password if you create 10 to 50 sessions per seconds.
> So fwiw, you can use the ssh keyboard interactive authentication and feed
> the password without using the UserInteraction object, simply by calling
> addPasswordIdentity on the ClientSession.  Those password identities will
> actually be used by the UserAuthKeyboardInteractive object if the server
> asks for a password, and when known passwords have failed, it will actually
> use the UserInteraction to prompt for the password.
>
>
> 2014-08-22 4:52 GMT+02:00 <Matthew.W.Pitts@wellsfargo.com>:
>
> > Hey all, thanks for all the work that has gone into Mina/SSHD – great
> > libraries!
> >
> > I have a codebase that is currently running quite well with SSHD
> > v0.8.0, but I am looking to upgrade to 0.12.0 for some of the
> > fixes/improvements that have come out since 0.8.0. For an overview of
> > how I’m using SSHD - the system executes a 10-50 SSH commands – each
> > in its own channel - to 2000 or so (and growing) devices every day.
> > Some of the commands/channels will re-use an existing session by way
> > of a keyed pooling system I have setup for the sessions. This all
> > works quite well right now.
> >
> > The current model uses a single SshClient instance and spawns ALL
> > sessions to each respective host from that same instance. This is true
> > regardless of the details of each session (username, destination host,
> > port, authentication, etc). This obviously avoids the need to call
> > SshClient.setupDefaultClient() for each and every SSH session. I’m not
> > sure if this is the recommended way, but again, it is working now.
> >
> > I am prototyping my code with 0.12.0 and refactoring some things to
> > align with how I see the differences in the versions and I’ve run into
> > a bit of conundrum. I want to take advantage of the
> > keyboard-interactive support, which appears to be done by calling
> > SshClient.setUserInteraction with an appropriate implementation. The
> > problem is that with my shared-SshClient model it is not practical to
> > give it a single UserInteraction implementation to support all
> > subsequent sessions since the credentials aren’t known ‘ahead of time’
> > when the global SshClient is created. So, as part of my prototyping I
> > have refactored my model to use an SshClient instance per session,
> > thereby allowing me to provide a UserInteraction impl that is
> > appropriate for each particular session. In my testing this seems to
> > be work, but again, I’m not sure if this is the recommended approach.
> >
> > So my question is: when using SSHD for relatively short-lived sessions
> > (a few minutes at a time) that are spawned in lots of different
> > threads to different host+credential combinations (password, private
> > key, etc.); is it appropriate for performance/scalability reasons to
> > use a single SshClient instance to spawn each session? If this is
> > true, then is there a suggested/recommended approach for dealing with
> > keyboard-interactive using different credentials for each session from
> > a single UserInteraction instance?
> >
> > OR - Is the creation of SshClient instances pretty inexpensive so it
> > would then be OK to create a new SshdClient instance for each session
> > where one can then set the UserInteraction impl appropriately? If this
> > is true, what would be a good setting for the number of NIO threads to
> > use for each SshClient instance in a system like this? The default,
> > which AFAIK is CPU cores + 1, is a bit excessive I think for a system
> > like mine that could be creating a few thousand sessions at any given
> > time - that could mean a lot of threads on a 8 or 16 core system.
> > Since each session instance is borrowed from a pool, used exclusively
> > and then returned, I figured just one thread would be fine, but I
> > welcome suggestions.
> >
> > OR - Would it be more appropriate for the UserInteraction impl be set
> > on the ClientSession rather than the SshClient? To me, this would seem
> > to align more with the other ‘auth’ methods that are already in the
> > ClientSession API (e.g. addPasswordIdentity and addPublicKeyIdentity)?
> > This would then allow for a shared SshClient, but with customizable
> > keyboard-interaction per session.
> >
> > If this is confusing, let me know and I’ll try to restate appropriately.
> >
> > Any advice on this is greatly appreciated.
> >
> > Thanks,
> >
> > Matthew Pitts
> >
> > Developer
> > Security Solutions Design & Automation
> >
> > Wells Fargo Bank | Tel 336.608.3332 | Cell 336.202.3913 |
> > Winston-Salem, NC
> > | MAC D4002-040
> > matthew.w.pitts@wellsfargo.com
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message