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 Im 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. Im 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 Ive 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 arent 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, Im 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 Ill 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]
smime.p7s
Description: S/MIME cryptographic signature
