We've seen an issue in the field where a customer is using openSSH with a highly customized keyboard-interactive prompt. From our sshj logs:
INFO [reader:method.AuthKeyboardInteractive@77] Requesting response for challenge `** This system is managed by Puppet
** Unauthorized Access Is Prohibited
** Access is provided to:
** Default: wheel
** Additional: admin
** Additional: ead
** Additional: host_dvd-bihdp-test-200
** Additional: netadm
** Additional: noc
** Additional: secscanadm
** Additional: unixadm
** Additional: users
Password: `; echo=false
There's no way we can anticipate this prompt, but see the "Password: " bit at the end; if we could match against part of the prompt, we could handle this.
I think this is already possible with setting up a AuthKeyboardInteractive instance with a custom ChallengeResponseProvider impl and using that for sshClient.auth()
for example, the default impl --
Fair enough, thanks for the suggestion.
One additional comment, though: The ChallengeResponseProvider interface isn't very well documented, so it's not clear (without looking at its calling code) how to use it. Any chance you can add some Javadoc to help implementers?
point noted about the javadoc...
for your purpose following the PasswordResponseProvider impl I linked to should suffice, basically switching out (or augmenting) the check in getResponse()
!gaveAlready && !echo && (acceptablePrompts.contains(prompt) || prompt.endsWith("Password: "))
Yes, I've done exactly that, though I wish I could subclass or delegate to PasswordResponseProvider. I mean, I could, but it's quite stateful, and most of the real logic is in the one method I'd override (getResponse), so I just ended up implementing something that looks like it.
Thanks again for this great software!
I guess the simplest thing for making this more useful given the variety in prompts would be for the constructor to take regexes instead of exact strings (acceptablePrompts). What do you think?
Yeah, that would work for us.
Per #77 use regex matching inside PasswordResponseProvider. Also remo…
…ve the 'gaveAlready' state, we can leave such logic to the PasswordFinder to implement if needed.