Support keyboard-interactive authentication

[waylybaye]

While implementing 2-factor login in my app, I noticed that swift-nio-ssh is missing support for keyboard-interactive authentication. I can create a pull request to add it to the NIOSSHAvailableUserAuthenticationMethods: OptionSet and make the client recognize keyboard-interactive messages. However, I am concerned that this change may cause issues on the server-side. So I created this issue to ask if you have any plans to support keyboard-interactive authentication in the future.

[Lukasa]

We can absolutely add support for keyboard-interactive authentication. We should implement both sides of the flow, but we don't need to actually have the server do anything so long as it can defer the implementation to the delegate that already exists.

[Yeuoly]

We can absolutely add support for keyboard-interactive authentication. We should implement both sides of the flow, but we don't need to actually have the server do anything so long as it can defer the implementation to the delegate that already exists.

I'm trying to implement keyboard-interactive authentication, but there are some troubles I met
In the SSH standard, message type SSH_MSG_USERAUTH_INFO_REQUEST and SSH_MSG_USERAUTH_PK_OK has the same value 60, reference to https://epaul.github.io/jsch-documentation/javadoc/constant-values.html#com.jcraft.jsch.UserAuth.SSH_MSG_USERAUTH_INFO_REQUEST, but in the implement of readSSHMessage, readUserAuthPKOKMessage will try to read if it's SSH_MSG_USERAUTH_PK_OK and mov readerIndex which will cause SSH_MSG_USERAUTH_INFO_REQUEST does not work

code here

case SSHMessage.UserAuthPKOKMessage.id:
                guard let message = try self.readUserAuthPKOKMessage() else {
                    return nil
                }
                return .userAuthPKOK(message)

what I'm trying is to add code here

case SSHMessage.UserAuthInfoRequestMessage.id:
                guard let message = try self.readUserAuthInfoRequestMessage() else {
                    return nil
                }
                return .userAuthInfoRequest(message)

of course UserAuthPKOKMessage will take care of the flow instead of UserAuthInfoRequestMessage, so there is a conflict need to be solved which will cause a major code modification

[Lukasa]

Yeah, this will require a substantial chunk of work. It will be necessary to pass some context information into the parser so that it is able to tell what it is likely to be decoding.