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] > > > > > > >
