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