Subject: Bug#966: Banner issue update

From: "Cherry, Andrew J." <[email-masked]>
Date: Tue, 29 Aug 2017 16:52:08 +0000

I've done some additional testing, prompted by your mention of the banner being configured using the Banner option in sshd_config.  It turns out we are *not* using the sshd config option -- instead, we are displaying the banner using the pam_echo module, configured with the following line in /etc/pam.d/sshd:

auth        optional    pam_echo.so file=/etc/issue.net

What I've found so far is that the same /etc/issue.net plays nice with x2go when configured via the Banner option, but causes an auth failure when configured using pam_echo.so.

I'm going to do some more digging to see if I can figure out what the difference is.  Oddly, if I cut/paste the output from the OpenSSH client (on Linux) up to and including the Password: prompt, and do a diff between the two, they are byte-for-byte identical.

By the way, the reason we use pam_echo.so instead of the Banner option is because we actually have two banners -- /etc/issue/net for the standard security boilerplate which is always displayed, and /etc/issue.alcf which is normally empty but is populated with information during our scheduled maintenance windows when logins are disabled.  However, I've confirmed that the problem still occurs even if I configure pam_echo.so to only display /etc/issue.net

-Andrew

---

From: "Cherry, Andrew J." <[email-masked]>
Date: Tue, 29 Aug 2017 20:17:55 +0000

One more note about reproducing this -- I've found that pam_echo.so only prints the banner *before* the password prompt if sshd is configured with "ChallengeResponseAuthentication yes" (which we happen to have due to our CryptoCard token usage).

-Andrew

> On Aug 29, 2017, at 12:52 PM, Cherry, Andrew J. <[email-masked]> wrote:
>

---

From: "Cherry, Andrew J." <[email-masked]>
Date: Wed, 30 Aug 2017 02:10:24 +0000

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.:

2. The following config changes in sshd_config:

   ChallengeResponseAuthentication yes
   PasswordAuthentication no

> On Aug 29, 2017, at 4:17 PM, Cherry, Andrew J. <[email-masked]> wrote:
>

---

From: Mihai Moldovan <[email-masked]>
Date: Fri, 1 Sep 2017 08:13:38 +0200

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:
> 
> 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