Bug 4062 - Client can't log in to SSH server with ChallengeResponseAutentication without UsePAM
Summary: Client can't log in to SSH server with ChallengeResponseAutentication without...
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: 3.2.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.14.0
Assignee: Frida Flodin
URL:
Keywords: relnotes, wilsj_tester
Depends on:
Blocks:
 
Reported: 2011-11-17 16:07 CET by Karl Mikaelsson
Modified: 2022-01-19 16:52 CET (History)
4 users (show)

See Also:
Acceptance Criteria:
- Only the authentication method configured in the ThinLinc client should be used. - For password there are two auth methods from the server: keyboard-interactive and password. We should always check the password ONCE against the server even if both are available from the server. (If the password was sent it should be seen in the sshd server log) - If it works to ssh with password authentication it should work to log in to thinlinc with password. - If the wrong password is entered the user should still be presented with the usual error message ("Wrong username or password").

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Karl Mikaelsson cendio 2011-11-17 16:07:42 CET 
Problem noticed on Mandriva ES 5.2. The default configuration of sshd on Mandriva is to have ChallengeResponseAuthentication enabled, but UsePAM disabled. This breaks our client which counts
a failed keyboard-interactive as a failed attempt to use the given password, which is not necessarily true.

[root@server ssh]# egrep "^UsePAM|^Chall" sshd_config
ChallengeResponseAuthentication yes
UsePAM no

[derfian@client ~]$ cat ~/.thinlinc/tlclient.log
2011-11-17T15:58:38: Log file created
2011-11-17T15:58:38: ThinLinc client release 3.2.0 build 3129
2011-11-17T15:58:38: Command /opt/thinlinc/lib/tlclient/pcsctun not found
2011-11-17T15:58:38: Disabled smart card export due to missing platform dependencies
2011-11-17T15:58:38: SSH command: /opt/thinlinc/lib/tlclient/ssh -N -o PubkeyAuthentication=no -o CheckHostIP=no -o NumberOfPasswordPrompts=1 derfian@localhost -p 2222 -L 45938:127.0.0.1:9000 thinlinc-login
2011-11-17T15:58:38: SSH pid is 19596
2011-11-17T15:58:38: Processing SSH output: NEXT AUTHMETHOD: none
2011-11-17T15:58:38: Processing SSH output: AUTH FAILURE
2011-11-17T15:58:38: Processing SSH output: NEXT AUTHMETHOD: keyboard-interactive
2011-11-17T15:58:38: Processing SSH output: AUTH FAILURE
2011-11-17T15:58:38: Processing SSH output: NEXT AUTHMETHOD: password
2011-11-17T15:58:38: Already tried one password method. Aborting...
2011-11-17T15:58:40: Log file ended

[root@server ssh]# sed -i -e "s/UsePAM no/UsePAM yes/" /etc/ssh/sshd_config
[root@server ssh]# service sshd restart
Stopping sshd:                                                  [  OK  ]
Starting sshd:                                          [  OK  ]
[root@server ssh]# egrep "^UsePAM|^Chall" sshd_config
ChallengeResponseAuthentication yes
UsePAM yes

[derfian@client ~]$ cat ~/.thinlinc/tlclient.log
2011-11-17T16:03:14: Log file created
2011-11-17T16:03:14: ThinLinc client release 3.2.0 build 3129
2011-11-17T16:03:14: Command /opt/thinlinc/lib/tlclient/pcsctun not found
2011-11-17T16:03:14: Disabled smart card export due to missing platform dependencies
2011-11-17T16:03:15: SSH command: /opt/thinlinc/lib/tlclient/ssh -N -o PubkeyAuthentication=no -o CheckHostIP=no -o NumberOfPasswordPrompts=1 derfian@localhost -p 2222 -L 42483:127.0.0.1:9000 thinlinc-login
2011-11-17T16:03:15: SSH pid is 20036
2011-11-17T16:03:15: Processing SSH output: NEXT AUTHMETHOD: none
2011-11-17T16:03:15: Processing SSH output: AUTH FAILURE
2011-11-17T16:03:15: Processing SSH output: NEXT AUTHMETHOD: keyboard-interactive
2011-11-17T16:03:15: Processing SSH output: SSH_PROMPT:Password: 
2011-11-17T16:03:15: Processing SSH output: AUTH SUCCESS
2011-11-17T16:03:15: Processing SSH output: CONNECTED
2011-11-17T16:03:15: Processing SSH output: THINLINC-LOGIN: HELLO 3.2.0post
2011-11-17T16:03:15: Processing SSH output: THINLINC-LOGIN: CONNECTED
[...]
Comment 1 Karl Mikaelsson cendio 2011-11-17 16:09:39 CET 
The problem is that the client doesn't know if it has sent the password or not, and just counts the number of failed authentication methods that usually takes a password.
Comment 2 Aaron Sowry cendio 2012-11-02 09:28:35 CET 
This also makes authentication fail if keyboard-interactive is enabled on the SSH server. This is a bit silly IMO; removing the target milestone so we can revisit this.
Comment 3 Aaron Sowry cendio 2012-11-02 10:43:40 CET 
(In reply to comment #2)
> This also makes authentication fail if keyboard-interactive is enabled on the
> SSH server. This is a bit silly IMO; removing the target milestone so we can
> revisit this.

This was actually due to a misconfigured SSH server. I still think we should revisit this, though; there's even a FIXME in the code for it.
Comment 4 Peter Åstrand cendio 2013-05-28 09:03:37 CEST 
Note that having ChallengeResponseAutentication without UsePAM on Linux is a strange configuration, because the only ChallengeResponseAutentication supported on Linux is PAM. Strange the the SSH server offers keyboard-interactive when it cannot be used. We could consider reporting this upstream.
Comment 5 didibus 2016-02-26 22:26:55 CET 
I'm getting a similar error, but I have usePAM enabled, and ChallengeResponseAutentication disabled:

2016-02-26T13:21:16: Host key previously known.
2016-02-26T13:21:16: ssh[E]: debug1: SSH2_MSG_NEWKEYS sent
2016-02-26T13:21:16: ssh[E]: debug1: expecting SSH2_MSG_NEWKEYS
2016-02-26T13:21:16: ssh[E]: debug1: SSH2_MSG_NEWKEYS received
2016-02-26T13:21:16: ssh[E]: debug1: Roaming not allowed by server
2016-02-26T13:21:16: ssh[E]: debug1: SSH2_MSG_SERVICE_REQUEST sent
2016-02-26T13:21:16: ssh[E]: debug1: SSH2_MSG_SERVICE_ACCEPT received
2016-02-26T13:21:16: ssh[E]: debug1: pubkey_prepare: ssh_get_authentication_socket: Invalid argument
2016-02-26T13:21:16: ssh[E]: NEXT AUTHMETHOD: none
2016-02-26T13:21:16: ssh[E]: AUTH FAILURE
2016-02-26T13:21:16: ssh[E]: debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
2016-02-26T13:21:16: ssh[E]: NEXT AUTHMETHOD: keyboard-interactive
2016-02-26T13:21:16: ssh[E]: AUTH FAILURE
2016-02-26T13:21:16: ssh[E]: debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
2016-02-26T13:21:16: ssh[E]: NEXT AUTHMETHOD: password
2016-02-26T13:21:16: Already tried one password method. Aborting...
Comment 6 didibus 2016-02-26 23:23:10 CET 
(In reply to comment #5)
> I'm getting a similar error, but I have usePAM enabled, and
> ChallengeResponseAutentication disabled:
> 
> 2016-02-26T13:21:16: Host key previously known.
> 2016-02-26T13:21:16: ssh[E]: debug1: SSH2_MSG_NEWKEYS sent
> 2016-02-26T13:21:16: ssh[E]: debug1: expecting SSH2_MSG_NEWKEYS
> 2016-02-26T13:21:16: ssh[E]: debug1: SSH2_MSG_NEWKEYS received
> 2016-02-26T13:21:16: ssh[E]: debug1: Roaming not allowed by server
> 2016-02-26T13:21:16: ssh[E]: debug1: SSH2_MSG_SERVICE_REQUEST sent
> 2016-02-26T13:21:16: ssh[E]: debug1: SSH2_MSG_SERVICE_ACCEPT received
> 2016-02-26T13:21:16: ssh[E]: debug1: pubkey_prepare:
> ssh_get_authentication_socket: Invalid argument
> 2016-02-26T13:21:16: ssh[E]: NEXT AUTHMETHOD: none
> 2016-02-26T13:21:16: ssh[E]: AUTH FAILURE
> 2016-02-26T13:21:16: ssh[E]: debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> 2016-02-26T13:21:16: ssh[E]: NEXT AUTHMETHOD: keyboard-interactive
> 2016-02-26T13:21:16: ssh[E]: AUTH FAILURE
> 2016-02-26T13:21:16: ssh[E]: debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> 2016-02-26T13:21:16: ssh[E]: NEXT AUTHMETHOD: password
> 2016-02-26T13:21:16: Already tried one password method. Aborting...

Similarly, I can fix it with disabling keyboard-interactive, but it seems silly that ThinLinc doesn't try the password auth when keyboard-interactive fails. It should attempt the auth a second time at least to address this problem.
Comment 8 Frida Flodin cendio 2021-08-27 14:36:20 CEST 
I could reproduce this with tl-4.13.0 client on Fedora 34 and server on Ubuntu 20.04. With the following configured on the server side /etc/ssh/sshd_config

> PasswordAuthentication yes
> ChallengeResponseAuthentication yes
> UsePAM no

It works just fine to ssh to the server with password authentication.



However I also tried a server on RHEL 8, with the exact same sshd_config and got another result. I still get the same tlclient.log. But when trying to ssh I get 'Permission denied'. Looking at the server side sshd log: 


> Aug 27 14:30:20 lab-172.lkpg.cendio.se sshd[19537]: WARNING: 'UsePAM no' is not supported in Fedora and may cause several problems.
> Aug 27 14:30:22 lab-172.lkpg.cendio.se sshd[19537]: error: Could not get shadow information for cendio
> Aug 27 14:30:22 lab-172.lkpg.cendio.se sshd[19537]: Failed password for cendio from 10.48.2.31 port 52280 ssh2

So obviously the RHEL ssh server do not like this configuration and maybe have some extra security to not let you ssh with password when UsePAM is set to no. I will look more into this.
Comment 10 Frida Flodin cendio 2021-08-30 13:08:39 CEST 
This should be fixed now. Tested client build 2177 on Fedora 34 against RHEL 8, SLES 15 and Ubuntu 20.04 servers. All servers with the same sshd_config as in comment #8.

> - Only the authentication method configured in the ThinLinc client should be used.
Yes

> - For password there are two auth methods from the server: keyboard-interactive and password. We should always check the password ONCE against the server even if both are available from the server. (If the password was sent it should be seen in the sshd server log)
Yes

> - If it works to ssh with password authentication it should work to log in to thinlinc with password.
Yes, worked on all server but RHEL 8. There you can neither ssh with password nor connect with ThinLinc client.

> - If the wrong password is entered the user should still  be presented with the usual error message ("Wrong username or password").
Yes

Also made sure this did not affect other authentication methods by testing Public key authentication and it works just fine.
Comment 11 William Sjöblom cendio 2021-08-31 11:07:28 CEST 
Tested client build #2179 running on Fedora 34 against servers running on Mint 19 (OpenSSH 7.6p1) and RHEL 7 (OpenSSH 7.4p1).

RHEL 7 seems to suffer from the problems as RHEL 8 described in comment 8, but everything works as expected on Mint 19.

> Only the authentication method configured in the ThinLinc client should be used.

Yes.

> For password there are two auth methods from the server: keyboard-interactive and password. We should always check the password ONCE against the server even if both are available from the server. (If the password was sent it should be seen in the sshd server log)

Yes.

> If the wrong password is entered the user should still be presented with the usual error message ("Wrong username or password").

Yes.

> If the wrong password is entered the user should still be presented with the usual error message ("Wrong username or password").

Yes.

I also verified that these changes do not interfere with smart card authentication and that error messages from _ALL_ authentication methods show up as expected.
Comment 13 Samuel Mannehed cendio 2022-01-18 10:52:49 CET 
Unfortunately something seems broken here. When pressing "Connect" without specifying a password, I get a popup:

> Authentisering
> --------------
> +---+
> | ? |  Password:
> +---+  ______________________________
>                           OK   Avbryt

The expected behaviour is to get "wrong username or password". The client log looks like this:

2022-01-18T10:52:08: ssh[E]: NEXT AUTHMETHOD: none
2022-01-18T10:52:08: ssh[E]: AUTH FAILURE
2022-01-18T10:52:08: ssh[E]: NEXT AUTHMETHOD: keyboard-interactive
2022-01-18T10:52:08: ssh[E]: SSH_PROMPT:(tester@samuel.lkpg.cendio.se) Password:
Comment 14 Samuel Mannehed cendio 2022-01-19 16:10:05 CET 
False alarm, this was caused by misconfigured PAM for local users on our workstations. The ThinLinc client behaves as it should.
Note You need to log in before you can comment on or make changes to this bug.