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
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. <acherry@alcf.anl.gov> wrote:
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
I did some more experimentation, and it looks like the following specific conditions are needed to reproduce the problem we're having:
Banner configured in /etc/pam.d/sshd using pam_echo.so, e.g.:
auth optional pam_echo.so file=/etc/issue.net
The following config changes in sshd_config:
ChallengeResponseAuthentication yes PasswordAuthentication no
On Aug 29, 2017, at 4:17 PM, Cherry, Andrew J. <acherry@alcf.anl.gov> wrote:
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. <acherry@alcf.anl.gov> wrote:
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
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:
- Banner configured in /etc/pam.d/sshd using pam_echo.so, e.g.:
auth optional pam_echo.so file=/etc/issue.net
- 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/sshmasterconnecti...
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
-
Cherry, Andrew J. -
Mihai Moldovan