Recently, I needed to add a user to our CentOS server. For some reason, I could not add or remove them using useradd or userdel, so I edited /etc/passwd and /etc/shadow manually, adding them. I was then able to use passwd as root to change their password, and all was well.

Or so I thought. Now, some users aren't able to log in via SSh at all - when prompted for their password, they're given Permission denied, please try again. for three attempts, then Permission denied (publickey,gssapi-with-mic,password).

This may be unrelated to the changes to /etc/passwd and /etc/shadow - removing the changes to those files doesn't solve the problem.

EDIT 1: The new user is able to log in via ssh, but some older users (including root) are not. The problem is also ONLY with ssh - logging in on the physical machine, and using su, both work without problem.

  • When you say you edited them directly, I assume you mean you edited the files with vi (or another editor), and not with vipw? – Bryan Jan 16 '12 at 12:33
  • Yep, used vi. Also directly copied another user line, changing userid and groupid to new numbers. – Tom Jan 16 '12 at 12:34
  • 2
    If you absolutely must edit these files directly, always use vipw. – Bryan Jan 16 '12 at 12:52
  • @Bryan What does vipw do that editing the files in vi does not, other put a lock on the file for all users? I don't see why that would make a difference in this case. Also, auth is working on the physical box, just not through ssh, so I don't think the problem actually lies in those files, now. – Tom Jan 16 '12 at 12:55
  • to the best of my knowledge it doesn't do anything else, it is however considered to be 'good practise' to edit these files this way, and only if you must edit the files. As for useradd, it would help if you detail the error message you receive. Are there any other clues in any log files as to what might be going on? – Bryan Jan 16 '12 at 13:05

I think adding users manually to /etc/passwd and /etc/shadow is a bad idea. Those users may face troubles sooner or later. Also, you may mistype some records. I am not sure what will be the result in this case.

I recommend you to restore these files to the old state if possible and retry adding those users using useradd command.

| improve this answer | |
  • Adding the user using useradd was failing. I don't remember what the error was off the top of my head, but it was not useradd: user exists. Edited the question with a bit more information, if that helps you. – Tom Jan 16 '12 at 12:47
  • i'd suggest looking into that error before this workaround bites you in the butt. – Sirex Jan 16 '12 at 13:18
  • @sirex Deleting the user using userdel worked, but trying to readd it with useradd gave useradd: user exists. I'm not sure what's causing the problem here. I deleted the home directory as well, and still can't useradd the user. – Tom Jan 16 '12 at 13:30
  • 1
    Created serverfault.com/questions/350291/… – Tom Jan 16 '12 at 13:36

Run pwck and grpck to check for formatting errors on the /etc/passwd and /etc/group files, respectively. This also checks the relevant shadow files.

| improve this answer | |

Two possible reasons come to my mind:

  1. Your changes to /etc/passwd or /etc/shadow are somehow malformed.
  2. You forgot to change users home directory owner with chown -R user after changing their uid. File system stores uid numbers, not user names.
| improve this answer | |
  • The new user is able to log in, but some older users are not. The problem is also ONLY with ssh - logging in on the physical machine, and using su both work without problem. Editing the question to include this information – Tom Jan 16 '12 at 12:41

I'm not sure, if this could be a reason, but it is still worth trying:

Are you having SELinux switched on ? Because, if the context gets changed, many apps would have trouble accessing the files.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.