#2484 Password change over ssh doesn't work with OTP and FreeIPA
Closed: Fixed None Opened 9 years ago by npmccallum.

Here is the terminal session:

$ ssh foo@localhost
foo@localhost's password: 
Password expired. Change your password now.
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user foo.
Current Password: 
New password: 
Retype new password: 
Password change failed. Server message: Old password not accepted.
passwd: Authentication token manipulation error
Connection to localhost closed.

Here is the logs:

Nov 06 17:42:22 ipa.example.com sshd[5189]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost.localdomain  user=foo
Nov 06 17:42:27 ipa.example.com [sssd[krb5_child[5215]]][5215]: Password has expired
Nov 06 17:42:30 ipa.example.com ipa-otpd[3652]: foo@EXAMPLE.COM: request received
Nov 06 17:42:30 ipa.example.com ipa-otpd[3652]: foo@EXAMPLE.COM: user query start
Nov 06 17:42:30 ipa.example.com ipa-otpd[3652]: foo@EXAMPLE.COM: user query end: uid=foo,cn=users,cn=accounts,dc=example,dc=com
Nov 06 17:42:30 ipa.example.com ipa-otpd[3652]: foo@EXAMPLE.COM: bind start: uid=foo,cn=users,cn=accounts,dc=example,dc=com
Nov 06 17:42:31 ipa.example.com ipa-otpd[3652]: foo@EXAMPLE.COM: bind end: success
Nov 06 17:42:31 ipa.example.com ipa-otpd[3652]: foo@EXAMPLE.COM: response sent: Access-Accept
Nov 06 17:42:33 ipa.example.com sshd[5189]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost.localdomain user=foo
Nov 06 17:42:33 ipa.example.com sshd[5189]: pam_sss(sshd:auth): received for user foo: 12 (Authentication token is no longer valid; new one required)
Nov 06 17:42:50 ipa.example.com sshd[5189]: pam_sss(sshd:account): User info message: Password expired. Change your password now.
Nov 06 17:42:50 ipa.example.com sshd[5189]: Accepted password for foo from 127.0.0.1 port 46088 ssh2
Nov 06 17:42:55 ipa.example.com kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Nov 06 17:42:55 ipa.example.com systemd-logind[779]: New session 3 of user foo.
Nov 06 17:43:01 ipa.example.com systemd[5216]: pam_unix(systemd-user:session): session opened for user foo by (uid=0)
Nov 06 17:43:05 ipa.example.com systemd[5216]: Starting Paths.
Nov 06 17:43:05 ipa.example.com systemd[5216]: Reached target Paths.
Nov 06 17:43:05 ipa.example.com systemd[5216]: Starting Timers.
Nov 06 17:43:05 ipa.example.com systemd[5216]: Reached target Timers.
Nov 06 17:43:05 ipa.example.com systemd[5216]: Starting Sockets.
Nov 06 17:43:05 ipa.example.com systemd[5216]: Reached target Sockets.
Nov 06 17:43:05 ipa.example.com systemd[5216]: Starting Basic System.
Nov 06 17:43:05 ipa.example.com systemd[5216]: Reached target Basic System.
Nov 06 17:43:05 ipa.example.com systemd[5216]: Starting Default.
Nov 06 17:43:05 ipa.example.com systemd[5216]: Reached target Default.
Nov 06 17:43:05 ipa.example.com systemd[5216]: Startup finished in 17ms.
Nov 06 17:43:05 ipa.example.com sshd[5189]: pam_unix(sshd:session): session opened for user foo by (uid=0)
Nov 06 17:43:06 ipa.example.com passwd[5376]: pam_unix(passwd:chauthtok): user "foo" does not exist in /etc/passwd
Nov 06 17:43:33 ipa.example.com ipa-otpd[5378]: LDAP: ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket
Nov 06 17:43:34 ipa.example.com ipa-otpd[5378]: foo@EXAMPLE.COM: request received
Nov 06 17:43:34 ipa.example.com ipa-otpd[5378]: foo@EXAMPLE.COM: user query start
Nov 06 17:43:34 ipa.example.com ipa-otpd[5378]: foo@EXAMPLE.COM: user query end: uid=foo,cn=users,cn=accounts,dc=example,dc=com
Nov 06 17:43:34 ipa.example.com ipa-otpd[5378]: foo@EXAMPLE.COM: bind start: uid=foo,cn=users,cn=accounts,dc=example,dc=com
Nov 06 17:43:34 ipa.example.com ipa-otpd[5378]: foo@EXAMPLE.COM: bind end: success
Nov 06 17:43:34 ipa.example.com ipa-otpd[5378]: foo@EXAMPLE.COM: response sent: Access-Accept
Nov 06 17:43:49 ipa.example.com passwd[5376]: pam_unix(passwd:chauthtok): user "foo" does not exist in /etc/passwd
Nov 06 17:43:53 ipa.example.com ipa-otpd[3644]: foo@EXAMPLE.COM: request received
Nov 06 17:43:53 ipa.example.com ipa-otpd[3644]: foo@EXAMPLE.COM: user query start
Nov 06 17:43:53 ipa.example.com ipa-otpd[3644]: foo@EXAMPLE.COM: user query end: uid=foo,cn=users,cn=accounts,dc=example,dc=com
Nov 06 17:43:53 ipa.example.com ipa-otpd[3644]: foo@EXAMPLE.COM: bind start: uid=foo,cn=users,cn=accounts,dc=example,dc=com
Nov 06 17:43:54 ipa.example.com ipa-otpd[3644]: foo@EXAMPLE.COM: bind end: Invalid credentials
Nov 06 17:43:54 ipa.example.com ipa-otpd[3644]: foo@EXAMPLE.COM: response sent: Access-Reject
Nov 06 17:43:55 ipa.example.com passwd[5376]: pam_sss(passwd:chauthtok): User info message: Password change failed. Server message: Old password not accepted.
Nov 06 17:43:55 ipa.example.com passwd[5376]: pam_sss(passwd:chauthtok): Password change failed for user foo: 4 (System error)
Nov 06 17:43:55 ipa.example.com passwd[5376]: gkr-pam: couldn't update the login keyring password: no old password was entered
Nov 06 17:43:57 ipa.example.com sshd[5189]: pam_unix(sshd:session): session closed for user foo

Notice that I entered the password+OTP twice, but three binds were attempted. This means that after the second password entry SSSD (?) tried to reuse the credentials. The first use of the credentials succeeded. But the subsequent use failed (as designed on the server side).


Since this feature worked fine in RHEL-7.0, I'm marking the bug as critical and moving to 1.12.3 for now.

If we identify the commit that broke OTP password change in the sssd-1-11 branch as well, we need to backport the fix to 1.11

milestone: NEEDS_TRIAGE => SSSD 1.12.3
priority: major => critical

Fields changed

owner: somebody => jhrozek
status: new => assigned

Fields changed

patch: 0 => 1

resolution: => fixed
status: assigned => closed

Fields changed

rhbz: => 0

Metadata Update from @npmccallum:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.12.3

7 years ago

Is there a fix for this one? It still continues, and we're trying to make it a bit easier on users to change their own passwords via SSH with OTP enabled.

As you can see this bug was fixed more than 3 years ago, so chances are quite high you might be hitting something else (https://pagure.io/SSSD/sssd/issue/3585?) but it's impossible to know unless you tell us the version you are using.

Metadata Update from @jhrozek:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch adjusted to on (was: 1)
- Custom field review reset (from 0)
- Custom field testsupdated reset (from 0)

5 years ago

@michaelsmoody, the issue reported here was fixed 3 years ago in sssd-1.12.3. If you have issues with OTP and password changes with SSH I would like to ask you to open a new ticket with the version of SSSD where you see the issue and debug logs of at least the pam responder and the backend with debug_level=10, see https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html for details.

Thanks.

bye,
Sumit

Metadata Update from @sbose:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field testsupdated reset (from false)

5 years ago

My apologies, I missed the fixed comment. (I have, from time to time seen some older bugs that are a few years old that are yet to be fixed, my apologies on this one). I am definitely seeing an issue with password changes, and will look for existing bugs, and if I don't find a matching one, will open a new one.

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3526

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata