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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ x2go-dev mailing list [email protected] https://lists.x2go.org/listinfo/x2go-dev
