#5 Support additional OTP prompts - help needed

[Orion Poplawski]

Multi-factor authentication is becoming more import and there are various mechanisms for integrating it into ssh with One-Time Passwords such as pam_oath and pam_google_authenticator. These mechanisms add an additional prompt for the OTP like:

Verification code:

or

One-time password (OATH) for `user':

It would be very helpful is sshpass could handle these additional prompts.

[Shachar Shemesh]

Can you please explain why the -P option is insufficient to achieve this?

[Orion Poplawski]

Because the OTP prompt can be followed by the normal "Password:" prompt, so it needs to process two different prompts.

[Shachar Shemesh]

As you may have gleaned from the time this bug sat there, sshpass is under reduced attention from myself.
If you'd like to submit a patch that adds this feature, I'd gladly look at it. I'm afraid I won't have the resources to work on this myself, however.

[Cálestyo]

This wouldn't just be important for multiple prompts with e.g. OTP + password or multi-hop, but also for scp when using remote hosts as both source and destination.

So one likely would need a way to specify an order in which certain strings are expected and passwords used for it.
Maybe something like pairs of [-f|-d|-p] and -P belonging together.

For -e this would require means to specify different env vars, for -f and -d each next pair could simply read the next line if the same file/descriptor is used.

An alternative for -e would also be to read lines form the env var.

I guess that issue #7 is effectively a duplicate of this.

Cheers,
Chris.

[Cálestyo]

I put some more thinking into this,... so for the records:

a) with scp, one might have actually any number of remote sides (it allows 1-n sources and 1 destination), all of them may have 0-i hops and each of those may have 0-m password/OTP prompts...

b) the prompts may be identifiable (like in "(user@example.org) Your 2nd factor (user):" or non-identifiable (like in"OTP:")

c) it may probably make sense to match using regular expressions (ideally probably PCRE), so if one has one OTP secret or password that is valid for multiple hosts (e.g. within one organisation) one could match like "^(user@.+.example.org) Your 2nd factor (user):$"

d) in principle, I guess, there are two ways of deciding which password to use
- based on an identifiable prompt.. when that uniquely determines which password/OTP to use, things are quite easy
- based on the order in which the prompts appear (for non-identifiable ones)

Somehow these two need to be "mixed"... maybe this could be done simply based on the order in which these (i.e. the regexps for the various prompts) are specified, but then one obviously needs a way to give the same non-identifiable several times and assign passwords to them in a certain order.

So perhaps it would make sense to have different "classes" of prompt patterns... such that may be used multiple times (every time it appears). These would be the identifiable ones.
And these would have precedence.

And if none of those matches a list of patterns, where each is only used/matched once, for the non-identifiable ones.

Of course, for scp things are more complex than that... since one would need to construct the list of patterns dynamically based on the used sources/dest and their order.

I'm just writing some wrapper for ssh, which may eventually try to address this, but not really sure whether it's cleanly possible.

[Cálestyo]

One more thought about it:

e) Maybe, what sshpass would need was even another way to specify the passphrase... something like -c "command", in which command is a shell command executed via system(3).

sshpass could simply check it's exit status and if 0 take whatever was printed to stdout and use that ass password (including any newlines and so).
Exit status 1 would indicate errors, others could be reserved for future use.

Of course one would also need to educate users that they mustn't include any sensible data in the command itself, but one could simply put such things in a wrapper script, which is not publicly readable.

The benefit about all this is that the (passphrase-generating) command could be executed "right" (more or less) at the point when the passphrase is needed, and not just when sshpass itself is executed.

This would be helpful with OTPs, when the time between generation of the OPT, invocation of sshpass and actual request of the OTP could have already been too long and caused it to expire.

That would, I guess, especially get more and more likely the more sources one uses in scp.