SSHD client and keyboard-interactive auth

[Izzy Alanis <iz...@gmail.com>]

I needed to get my client to authenticate with a ssh server that
supported keyboard-interactive auth, but not password auth.

And, while I got it to work, the implementation wasn't as clean as it
should have been.

The code that dealt with getting the right bits down the pipe to
support the RFC was easy enough, but the ClientSessionImpl code just
didn't have enough extensibility built into it to make it easy to
integrate my changes.

My first take on was to try to set up a session factory that gave me a
subclass of ClientSessionImpl with a new auth method attached to it,
but the userAuth and authFuture fields are private to
ClientSessionImpl, and the auth method needs those fields to do its
job.

Maybe it would have been nice to have a factory creating the UserAuth
instances, so I could plug my KeyboardInteractiveUserAuth into the
spot where the UserAuthPassword implementation was created ... though
that wouldn't have been a general solution for a keyboard interactive
auth, it would have solved my problem and kept me out of the inner
workings of ClientSessionImpl.

Having a more generic auth method would have helped.
protected AuthFuture auth(UserAuth) ?
but the implementations of UserAuthPassword, UserAuthPublicKey and
UserAuthAgent, all do so much logic in their constructor, and the
UserAuth interface has only one method defined... to really implement
that method with an eye toward extensibility, would probably mean
refactoring that interface and those implementations to do less work
in their constructor.

In the end, there was no clean way to add the functionality purely by
extending ClientSessionImpl, without making some sort of change or
copy of the ClientSessionImpl code directly.

I recommend either:

* Increase the visibility of the userAuth and authFuture fields in
ClientSessionImpl (either directly, or by providing accessor methods
for them -- which is easy to do, but still feels unclean)

or

* Introduce the factory pattern into the UserAuth instantiation, to
let people roll their own UserAuths.

or

* Create a way to use ANY UserAuth implementation with something like:
protected AuthFuture auth(AuthUser)... and go through the work of
refactoring the AuthUser interface and implementations to work with
that method, getting rid of some code duplication in the
ClientSessinImpl.auth* methods along the way.

Thoughts?

 - Izzy