On 08/30/2017 04:10 AM, Cherry, Andrew J. wrote:
> I did some more experimentation, and it looks like the following specific
> conditions are needed to reproduce the problem we're having:
> 
> 1. Banner configured in /etc/pam.d/sshd using pam_echo.so, e.g.:
> 
> auth optional pam_echo.so file=/etc/issue.net
> 
> 2. The following config changes in sshd_config:
> 
> ChallengeResponseAuthentication yes PasswordAuthentication no

This sort of makes sense.

If challenge response auth is turned on and normal password authentication is
turned off, X2Go Client expects a certain challenge response string to come up.
If none of the built-in strings match, authentication is marked as failed, since
it cannot proceed with password authentication (i.e., the keyboard-interactive
method.)

The patch you initially provided merely ignores whatever data comes first and
then matches on the password prompt.


Am I correct that in any case challenge auth is being used?


The problem certainly is that pam_echo.so outputs data before the prompt.

I'm reluctant to apply your patch, since I'm not sure that this is actually good
practice. Allowing arbitrary data before the password prompt doesn't make a lot
of sense to me, although I could probably do that.

We have a set of hardcoded prompts that are recognized as challenge auth
prompts, namely these listed here:
https://code.x2go.org/gitweb?p=x2goclient.git;a=blob;f=src/sshmasterconnection.cpp;h=0556299002e6402e332efe478d8ec7f83ab0ac57;hb=HEAD#l59


The requirement is that challenge auth prompts either contain *challenge* or
that they *start* with the known prompts.

Maybe it would make sense to check each consecutive *line* explicitly?

Would that make sense to you? I guess that would fix your problem.



Mihai