SSH password authentication vs keyboard-interactive

[jimbobmcgee]

I've been setting up some SSH-based servers in Otter, and have experienced authentication failures, even though I know the username and password to be correct:

Unhandled exception: Inedo.Agents.Ssh.SshException: Authentication failed (username/password)

It took me a while to work out what was going wrong.

In the SSH standard, there are two types of "password" authentication:

• password
• keyboard-interactive

It appears the SSH agent in Otter only supports true "password" authentication, but many users' expectation of using a login that is username/password-based might also fall under the bracket of "keyboard-interactive". Indeed many distributions actually disable true "password" authentication and enable "keyboard-interactive" by default.

Obviously, the correct way to work around this is to use public/private key based authentication but, as a feature request, could keyboard-interactive authentication also be supported?

Note that I am not suggesting that the end-user should be required to manually enter the password on each job run, just that the Otter SSH client correctly handle if the server's permitted authentication method happens to be keyboard-interactive.

Both "password" and "keyboard-interactive" ultimately resolve when the SSH client sends a password string so, if your SSH client library supports sending a keyboard-interactive authentication, can you expose that option?

At its simplest, I imagine this could be a tickbox option (e.g. Use keyboard-interactive method for passwords), when editing an SSH-based server. but I suppose you could attempt to auto-detect from the server response when authentication has failed due using to the wrong method.

Keyboard-interactive also technically allows for receiving multiple prompts from the server, and answering each in turn (with the same or other strings), so the ability to define multiple strings in turn might be useful but, at a minimum, supporting just the password going over the keyboard-interactive layer should be enough for most.

[stevedennis]

Hi @jimbobmcgee,

I haven't seen this option in too many tools that use SSH; and actually it's the first time I've even heard of this as an option. But I'm not an SSH expert by anymeans, so no idea if this is common.

We use libssh2, and I have no idea if it's technically possible. We use the libssh2_userauth_password_ex(IntPtr session, IntPtr username, uint username_len, IntPtr password, uint password_len, IntPtr passwd_change_cb) method to authenticate.

Unless it's absolutely trivial to change (like a simple flag on libssh2 or something), it probably doesn't make sense for us to invest in this feature... unless it came from a from a paid user trying to solve a specific problem/usecase that we could work together on.

SSH is already difficult to support/maintain, so this would add more complexity to testing, debugging, documentation, etc... and we've got enough of that already heh

Cheers,
Steve

[jimbobmcgee]

Thanks for replying, and for indicating what you guys use internally. It is a feature I have had to implement myself in a tool we use internally, so I have some familiarity with doing it (at least, in Go).

I believe the equivalent in libssh2 is to call libssh2_userauth_keyboard_interactive_ex, so I presume the code path would branch based on whether a Use keyboard-interactive method option was set.

That function takes a callback argument which, when invoked, receives pointers to an array of server prompts and a target array of responses. The callback is expected to populate the target array with the responses.

At its simplest, you can probably assume the password prompt is the first in the array, and set the first element in the target array with the configured password -- that should cover most use-cases.

So, not a simple flag, but should be trivial enough, depending on the libssh2 wrapper you are using (your signature is C#?)

If you did want to support more than one prompt, you could allow storing a list of responses against either the server or the credential object, and writing them to the target response array in the order they were stored.

[apxltd]

Curious ... why not just enable non-interactive login on the servers? Seems like both ought to be enabled in most cases, right?

[jimbobmcgee]

@apxltd; apologies for the delay; I did not get a notification.

Essentially, it is a chicken-and-egg problem.

Enabling key-based, non-interactive login was one of the things I was hoping to automate/remediate with Otter; instead it is currently a prerequisite to using Otter.

The device is not a 'server' per se, but a third-party 'appliance' built on top of Linux. The device image itself comes prebuilt with keyboard-interactive auth (not password) enabled.

Having Otter support keyboard-interactive seemed more beneficial to a wider audience, than trying to alter the appliance software.