a proposed patch for what I would like: https://go-review.googlesource.com/#/c/24156/

can you give more background? Is this something that openSSH normally supports? I think most servers use keyboard-interactive auth nowadays, which lets the server itself decide how many prompts it wants to do.

I'd be happy to provide more background.

To the first question, yes, this is something openssh supports. Particularly for password authentication, but also for keyboard interactive authentication (and could potentially for other auth methods; though it handles pubkey differently).

With keyboard-interactive authentication, a server expects the number of answers it receives to exactly match the number of prompts it sent. x/crypto/ssh already checks this itself ( https://github.com/golang/crypto/blob/master/ssh/client_auth.go#L419 ). So if a server sends 3 prompts, it expects 3 answers. If any of those answers are incorrect, it would fail that authentication attempt. In a typical keyboard-interactive scenario being used for "password-auth", the servers sends 1 question (e.g. "Password: ") and expects 1 answer. Normally, the server responds to circumstances where the answer is wrong by providing a list of authentications that can continue that still includes the method that just failed. The client can then choose any of the methods that can continue, and (re)attempt one of them.

You can see this behavior if you use the following snippet to connect to an sshd (openssh in my experiments). (with minor hardcoded tweaks of doom) https://play.golang.org/p/F-od_urg3G

The way x/crypto/ssh currently handles this is, as soon as a method is tried, it is immediately placed in the tried map, and never tried again. My patch allows this behavior in the default case (so as not to break any existing users of x/crypto/ssh), but allows a user of x/crypto/ssh to alternatively obtain the behavior clients like openssh/etc exhibit, where failed authentication methods are retryable if you typo, but can after some number of attempts (or other condition) stop allowing a particular method, even if the server lists it as a method that can continue (e.g. NumberOfPasswordPrompts). This enables a more familiar user-experience for human-interactive clients written using x/crypto/ssh.

The unit-tests in my patch are probably better at demonstrating the behavior than my explanation here, so I'll refer to them:
https://go-review.googlesource.com/#/c/24156/1/ssh/client_auth_test.go

The first test shows what happens in the case of a typo, and then successful entry. The second demonstrates the behavior when a client tries password-auth first (which would be silly, but is sometimes how people have things configured to behave) and finally falls back to publickey authentication after password auth fails twice.

Note also, this does not change the behavior of servers demanding multiple forms of authentication must succeed (sshd_config's AuthenticationMethods option). A server requiring multiple authentication methods exhibits the same behavior when the user makes a typo; either offering the client the opportunity to retry the method again by including it in the list of methods that may continue, or not, at the server's discretion.

Thanks again!

fixed by https://go-review.googlesource.com/c/24156/

commit 0c565bf