Missing password callback

[awesomenode]

Hi!

I'm trying to update to the latest libnetconf2 version, bit I've
noticed that the SSH password callback has been removed, only the
interactive callback is usable.

libnetconf now retrieves the password from the datastore, if I'm
understanding it correctly, but I'm using a separate app that verifies
the password and handles other checks, so the password callback was
fairly useful.

I guess the interactive callback could replace it, but I don't need the
extra functions of that. Do you perhaps plan to add the regular
password callback to libnetconf2? Or we have to use the interactive
callback from now on to support the same functionality?

Thanks!

[Roytak]

Hi, you are right, the password callback was removed. Michal may correct me later, but I do not think that we plan to add it back. So I suggest you use the interactive callback, it shouldn't be that much extra work to implement the same functionality.

[michalvasko]

That is correct, we decided that password should always perform just simple password check. You can use keyboard-interactive for any elaborate user password retrieval or something similar.

[awesomenode]

I'm trying to implement the keyboard auth callback, but for some reason
it doesn't seem to work.

I attached the example that shows what I'm trying to do. I get the
following in the server logs, when I try to connect using netopeer2-cli:

[INF]: Listening on 0.0.0.0:10830 for SSH connections.
[INF]: Accepted a connection on 0.0.0.0:10830 from 127.0.0.1:48212.
[INF]: Received an SSH message "request-service" of subtype "ssh-userauth".
[INF]: Received an SSH message "request-auth" of subtype "none".
[INF]: Received an SSH message "request-auth" of subtype "interactive".
Failed to send an authentication request to client: test
[INF]: Failed user "test" authentication attempt (#1).
SSH log: ssh_auth_reply_default: ssh_auth_reply_default: Sending a auth failure. methods that can continue: keyboard-interactive
SSH log: ssh_socket_unbuffered_write: ssh_socket_unbuffered_write: Enabling POLLOUT for socket
SSH log: packet_send2: packet_send2: packet: wrote [type=51, len=32, padding_size=5, comp=26, payload=26]
SSH log: ssh_packet_socket_callback: ssh_packet_socket_callback: packet: read type 1 [len=32,padding=11,comp=20,payload=20]
SSH log: ssh_packet_process: ssh_packet_process: Dispatching handler for packet type 1
SSH log: ssh_packet_disconnect_callback: ssh_packet_disconnect_callback: Received SSH_MSG_DISCONNECT 11:Bye Bye
SSH log: ssh_packet_disconnect_callback: ssh_packet_disconnect_callback: Received SSH_MSG_DISCONNECT: 11:Bye Bye
[ERR]: Communication SSH socket unexpectedly closed.

I also tried connecting using ncclient (got 'No authentication methods
available' error), and ssh client (got 'Permission denied (keyboard-
interactive)', I know plain ssh is not supported properly, but for testing's
sake I tried it anyway.

Also, when I specify a password with ncclient the program segfaults,
because auth_password_compare_pwd() tries to read stored_pw, which
isn't initialized.

Could you give me some advice on what I'm doing wrong?
nc_interactive.zip

[Roytak]

Hello, the issue you're facing lies in your interactive callback.

The line Failed to send an authentication request to client: test from the output you provided comes from invalid parameters to the libssh function. I changed int ret = ssh_message_auth_interactive_request(msg, name, NULL, 1, (const char **)&prompt, NULL); to the following:

char *prompt = "Password: ";
char echo[] = {0};
int ret = ssh_message_auth_interactive_request(msg, name, "Enter your token:", 1, (const char **)&prompt, echo);

Another issue comes from the line int n_answers = ssh_userauth_kbdint_getnanswers(ssh_session);. You need to handle receiving the answers to the keyboard interactive challenge yourself in your callback. What I mean is doing something similar to this.

And lastly you forgot to call nc_server_init() for initialization (and to free the configuration data).

All in all, based on your issue we will:

• improve error output
• modify the documentation of nc_server_ssh_set_interactive_auth_clb to add more detail
• add checks for server initialization to some API

I haven't tested it with clients other than netopeer2-cli, so can't help with that.

[awesomenode]

Thanks, it's working now. I've used nc_server_init_ctx(), doesn't that do the initialization too? Or it only initializes the context?

[Roytak]

Yes, nc_server_init_ctx() only initializes the context (loads the required modules, etc.). It does not initialize the server as a whole though. In the referenced commit I made an internal function public. This function should help with getting the answers to your interactive queries.

[awesomenode]

Thank you very much!

[awesomenode]

That is correct, we decided that password should always perform just simple password check. You can use keyboard-interactive for any elaborate user password retrieval or something similar.

Sadly, replacing the password auth method with keyboard-interactive is not an option, as it's not supported by ncclient (or MG-SOFT NETCONF Browser). I have to provide support for ncclient, because it's one of the most popular netconf clients, and used by a number of vendors, like Cisco, Nokia or Huawei.

Could you please put back the password callback from the older version please? Removing an existing auth method is not feasible for me.

[Roytak]

Hi, if I understand you correctly, then storing the password in the datastore is not an option for you. Well, then if we were to add the password callback back and still be compliant with ietf-netconf-server YANG module, how exactly should this be handled? When it comes to keyboard interactive, we defined our own YANG for this, so that it's possible to deduce which configured user supports it and which does not. As for the password method, if a password callback was set, would that mean that all the configured users must authenticate via the password method?

A section from the SSH client-authentication subtree states the following:

list user {
          key "name";
          description
            "A locally configured user.

             The server SHOULD derive the list of authentication
             'method names' returned to the SSH client from the
             descendant nodes configured herein, per Sections
             5.1 and 5.2 in RFC 4252.

             The authentication methods are unordered.  Clients
             must authenticate to all configured methods.
             Whenever a choice amongst methods arises,
             implementations SHOULD use a default ordering
             that prioritizes automation over human-interaction.";

Suppose password wasn't configured for a user, because you can not store it in the datastore, then:

The server SHOULD derive the list of authentication
'method names' returned to the SSH client from the
descendant nodes configured herein, per Sections
5.1 and 5.2 in RFC 4252.

even if password wasn't configured for the user, but the callback was set, we could still send the password method as available to the client. It's just a question of whether the password callback MUST return success for every client in order for the authentication to be successful, or whether it should only apply to a subset of the configured users. I suppose it could be done similarly to the keyboard-interactive method with some extra YANG modelling to tell the difference if need be. Or some dummy value that won't be used could be stored as the user's password, so that it's clear he wishes to support the method.

I agree that a password callback can be useful. We'll discuss and try to find the solution to this with Michal when he is back.

[awesomenode]

I support remote authentication (like TACACS+), so local user configuration in this case is not sufficient. I need a solution that's compatible with remote auth, where we don't store the user locally.

[jktjkt]

@awesomenode , are you OK with using PAM? In my opinion, the "password/passphrase/kbd-interactive" authentication methods should all reach the same backend (PAM in case it was enabled at build time, or traditional UNIX getpwnam/getspuid/... in case of no PAM), and it should not matter whether a client auths via kbd-interactive or password SSH methods. If it was done that way, would it work for you?

Also, the current config implies that all auth methods have to succeed. That's not great for your use csae, and we would like to have an or method, something like this:

<cesnet:any-auth-of>
  <system-password/>
  <system-kbd-interactive/>
  <system-ssh-pubkey/>
</cesnet:any-auth-of>