Done. Thanks. https://issues.apache.org/jira/browse/SSHD-341
-----Original Message----- From: Guillaume Nodet [mailto:[email protected]] Sent: Monday, August 25, 2014 9:02 AM To: [email protected] Subject: Re: SSHD SshClient - should I reuse the same instance for multiple independent sessions? 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 <[email protected]>: > 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:[email protected]] > Sent: Sunday, August 24, 2014 8:11 AM > To: [email protected] > 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 <[email protected]>: > > > 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 > > [email protected] > > > > > > >
