Asynchronous user authentication.

[falemagn]

This patch makes it possible to do asynchronous user authentication, by returning WOLFSSH_USERAUTH_WOULD_BLOCK from the authentication callback.

[wolfSSL-Bot]

Can one of the admins verify this patch?

[JacobBarthelmeh]

ok to test

[JacobBarthelmeh]

I like this idea, having async with user authentication callback. Have been testing with this change. Adding a simple :

--- a/examples/client/common.c
+++ b/examples/client/common.c
@@ -433,6 +433,7 @@ int ClientPublicKeyCheck(const byte* pubKey, word32 pubKeySz, void* ctx)
 }
 
 
+static int count = 0;
 int ClientUserAuth(byte authType,
                       WS_UserAuthData* authData,
                       void* ctx)
@@ -453,6 +454,11 @@ int ClientUserAuth(byte authType,
     printf("wolfSSH requesting to use type %d\n", authType);
 #endif
 
+    if (count++ < 2) {
+        printf("returning auth blocking authRype = %d\n", authType);
+        return WOLFSSH_USERAUTH_WOULD_BLOCK;
+    }
+
     /* Wait for request of public key on names known to have one */

And the server side is still cycling through the available auth types without going back to the first case that returned WOLFSSH_USERAUTH_WOULD_BLOCK.

$ sudo ./apps/wolfsshd/wolfsshd -D -f ./sshd_config -h ./keys/server-key.pem


$ ./examples/client/client -u jak -h 127.0.0.1 -t
returning auth blocking authRype = 1
returning auth blocking authRype = 2
wolfSSH error: Couldn't connect SSH stream.

[falemagn]

@JacobBarthelmeh the functionality has only been tested server-side. To make use of it, one needs to return WOLFSSH_USERAUTH_WOULD_BLOCK and then at a later time trigger a new read from the socket. Since the auth request doesn't get discarded when returning WOLFSH_USERAUTH_WOULD_BLOCK, the auth callback gets then invoked with the same request again.

[ejohnstown]

Superseded by PR #695.