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