PAM--CM-1341 error when trying to rotate passwords on many Linux target servers
Article ID: 137401
Updated On:
Products
Issue/Introduction
We have multiple target accounts configured in PAM for Linux servers. The accounts are synchronized, password verification works and the accounts can be used successfully for auto-login in SSH sessions. But for accounts on many of the Linux servers we are not able to update the password in PAM. All attempts to set a new password, or have a scheduled job change the password, fail with the following error:
PAM-CM-1341: Failed to establish a communications channel to the remote host.
For a while after that password verification attempts fail as well, but later on they succeed again without any change in PAM.
Environment
This applies to all PAM releases prior to 4.0.2.
Cause
The is caused by the way PAM updates the password prior to the 4.0.2 release in combination with a pam_tally2 setting on the Linux target server, specifically the lock_time setting in /etc/pam.d/system-auth:
# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_tally2.so magic_root deny=6 lock_time=30
This setting causes authentication to be denied for 30 seconds after one failed login attempt by a given user.
When PAM tries to set a new password for a target account, it will always first attempt to login with the new password, which is bound to fail if the original password in PAM is the current password. This results in messages like the following in /var/log/secure on the Linux server:
...
Sep 20 15:36:03 linuxhost sshd[21807]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=myclient.mydomain.com user=pamuser
Sep 20 15:36:06 linuxhost sshd[21807]: Failed password for pamuser from xx.xx.xx.xx port 44501 ssh2
Sep 20 15:36:06 linuxhost sshd[21811]: pam_tally2(sshd:auth): user pamuser (5529) has time limit [27s left] since last failure.
...
In the PAM tomcat logs we can see messages at INFO log level, like
...
Sep 20, 2019 3:36:01 PM PM com.cloakware.cspm.server.plugin.SSHUserInfoImpl promptPassword
INFO: jsch: password prompt: 'Password for [email protected]'
Sep 20, 2019 3:36:03 PM com.cloakware.cspm.server.plugin.SSHConnector$1 log
INFO: jsch: Login trials exceeds 1 ***************** This is the failed logon using the new password ***************
Sep 20, 2019 3:36:03 PM com.cloakware.cspm.server.plugin.SSHConnector$1 log
INFO: jsch: Disconnecting from linuxhost.mydomain.com port 22
Sep 20, 2019 3:36:03 PM com.cloakware.cspm.server.plugin.SSHConnector connect
INFO: connecting to linuxhost.mydomain.com:22
....
Sep 20, 2019 3:36:03 PM PM com.cloakware.cspm.server.plugin.SSHUserInfoImpl promptPassword
INFO: jsch: password prompt: 'Password for [email protected]'
Sep 20, 2019 3:36:06 PM com.cloakware.cspm.server.plugin.SSHConnector$1 log
INFO: jsch: Login trials exceeds 1 ***************** This is the failed logon using the correct old password, but getting rejected because of the lock_time setting ***************
...
SEVERE: UpdateTargetAccountCmd.invoke 15212: PAM-CM-1341: Failed to establish a communications channel to the remote host.
...
Resolution
The PAM authentication module on the Linux server side needs to be reconfigured to not block logon attempts by a user for a period of time after a single failed attempt, in order for PAM to manage target accounts on the server.
If the target device authentication settings cannot be changed, a possible workaround would be to configure the target accounts to have their password updated by another account. This other account will either have to be a root account, or require sudo privileges to allow it to change the password of other accounts. If this account itself is to be managed by PAM, a second account with sudo privileges will be needed to update the password of the first privileged account.
The PAM 4.0.2 release changed the way UNIX target accounts are updated, see Changes to UNIX Connector Logic When Updating Target Accounts. Upgrade to 4.0.2+ or 4.1+ resolves this problem without the need for any configuration change on the target servers.
Feedback
