[CentOS] Authentication Problems

Wed Feb 16 12:59:16 UTC 2011
David Sommerseth <dazo at users.sourceforge.net>

On 16/02/11 13:28, James Bensley wrote:
> Hi List,
> We have a CentOS VPS running a web site in a DC far away. The chap that
> dev's this site told me he couldn't SFTP in yesterday, his password was
> being rejected (I went to his desk to confirm and saw it was telling him
> the password was incorrect but neither him nor me had changed it and we are
> the only two with access to this VPS). So I logged in as root and reset his
> password, be he still couldn't log in (same problem, claiming the password
> was wrong).
> [root at server ~]# passwd webdevuser
> Changing password for user webdevuser.
> New UNIX password:
> Retype new UNIX password:
> passwd: all authentication tokens updates successfully.
> I tried to SSH in as the web dev user and it wouldn't let me in. Returning
> back to my root console window;
> [root at server ~]# su - webdevuser
> [webdevuser at server ~]# passwd
> Changing password for user webdevuser.
> Changing password for webdevuser.
> (current) UNIX password:
> passwd: Authentication token manipulation error
> Firstly; I am stracthing my head as to why his password was no longer
> working in the first place?
> Secondly; Why I can't reset it?
> Googling around many people suggest there is a discrepancy between the
> /etc/passwd and /etc/shadow files and by deleting /etc/shadow and using
> pwconv to recreate shadow and the same for /etc/groups, deleting gshadow
> recreating it with grpconv will solve the problem but I still can't login
> as the web dev user.
> Any ideas anyone?

- Could the account have become locked somehow?  (passwd -u $user)  Or
could the account have become expired?

- Are the permissions strict on the users ~/.ssh?  (0700 on the directory,
and 0600 on any files inside that directory - like authorized_keys ...)

- Is SELinux in Enforced mode and are the SELinux file context correct on
/home?  (restorecon -rv /home)

Also double check /var/log/messages, /var/log/secure and
/var/log/audit/audit.log carefully when trying to log in as that user.

kind regards,

David Sommerseth