Some keyboard-interactive authentication schemes involve echo-on prompts, and echo-off prompts which don't correspond to user passwords (e.g. PIN prompts). The current behavior which is to use the standard user/password dialog for the prompts works, but is very confusing especially for echo-on prompts (e.g. giving an e-mail address in a password field). A separate dialog for keyboard-interactive authentication could support all possible prompts in a general way.
The most straightforward solution would be to bring up a dialog for each prompt in turn, containing the prompt message and a single input field for the answer. The input field would be a regular text field or a password field depending on the "echo" flag for that prompt. I've attached a screenshot showing how this is implemented in WinSCP. Here, "#AC login:" is the prompt message and the field is a regular text field (echo on).
Generally speaking, it's not possible for a client application to know for sure the meaning of any prompt, because the challenge-response authentication method can't convey any metadata about them. Still, if the server is simply doing normal password authentication using challenge-response, sending a simple "Password:" prompt, it's probably safe to assume that is the password. Currently, Cyberduck assumes that the first prompt is always the password prompt regardless of the message or value of the echo flag.
Here is how I would implement this:
If this is the first prompt, echo=off and the message is "Password:", assume it's asking for the user's password. Supply the value from the standard user/password dialog (or automatically, if the user chose remember password). If that is all the server wants, then the user doesn't have to deal with the challenge/response prompt dialog.
If this is the first prompt, but the prompt it something else, then don't assume anything and just present the user with the challenge/response dialog. Don't record the answer anywhere (as in "remember password"), since it's not really possible to say if this is a one-time value (e.g. google authenticator code) or not.
For all the rest of the prompts, present the challenge/response dialog.
Note that if a "Password:" prompt comes in after the first prompt, it might not correspond the password for the SSH user. This is the case for the service depicted in the screenshot, where it first asks the user for his e-mail address, and then for a password corresponding to that e-mail address (not the SSH user). In this case, the password from the standard user/password dialog would go unused and could be left empty.