Hot answers tagged

21

Start with /etc/passwd - user account information less the encrypted passwords /etc/shadow - contains encrypted passwords /etc/group - user group information /etc/gshadow - - group encrypted passwords Be sure to ensure that the permissions on the files are correct too


14

It should be trivial to hack up a quick python/perl/whatever script and call the crypt(3) function. The glibc2 version of this function supports additional encryption algorithms. If salt is a character string starting with the characters "$id$" followed by a string terminated by "$": $id$salt$encrypted then instead of using the DES machine, id ...


12

I did this with Gentoo Linux already and copied: /etc/passwd /etc/shadow /etc/group /etc/gshadow that's it. If the files on the other machine have different owner IDs, you might change them to the ones on /etc/group and /etc/passwd and then you have the effective permissions restored.


10

Any proper answer is going to more or less boil down to this: Keep configs in a config management system. These can also handle package installation and upgrades. (Puppet, Chef, etc.) Use some sort of centralized database for user and group information. (LDAP, Kerberos, NIS, etc.) Use shared storage for /home. (NFS is the most frequently-used method here)


9

You need to check if the /etc/.pwd.lock exists and if it's there rm /etc/.pwd.lock In this way you can solve your issue


8

Tell your ssh client which username to use when connecting to remote hosts. Put this in .ssh/config on your workstation: Host * User dweinta I recommend you read all of the man page for ssh_config while you're at it.


7

This should work for you using process substitution with bash, diff, awk, and sort: diff <(awk -F: '{print $1}' /etc/passwd | sort) <(sort your_other_list_file) This assumes your your_other_list_file only contains usernames, one per line. Can't help you parse that unless you post an example line.


7

As the package description says, "Realtime Kit enables realtime scheduling for the PulseAudio daemon". This is an entry for the user running the RealtimeKit daemon.


6

useradd doesn't create the user's home directory by default, nor does it ask for a password. You can pass the -m flag to create the home directory, and just run passwd after creation to set the password. man useradd will tell you more, obviously.


6

Yes, this discrepancy is normal. I've seen it so many times I stopped looking at the /etc/passwd and /etc/group files and instead started looking at group memberships the way they should be looked at: getent group <groupname> and groups <username>.


5

If you type: echo $PS1 at the Bash prompt, you'll see: [\u@\h \w] That says to display the username, an at sign, the hostname and the current working directory all inside square brackets. Evidently, they've given your server the same hostname as your customer login ID.


5

Seems like your clipuser account has been locked by the pam_tally module. You either have to wait for the unlock timer to expire, or manually run the pam_tally --reset command. If that happened, then it can only be one thing: The password you used to login was not the password you set with passwd or you made a typo more than 3 times (or whatever the ...


5

Always use vipw to edit /etc/passwd, and vipw -s to edit /etc/shadow. Check that the shells you're trying to use are listed in /etc/shells. Check that SElinux is not set to 'enforcing' in /etc/selinux/config. Change it to 'permissive' or 'disabled'. [requires reboot] When you want to try a new shell don't log out to test it. Start up an additional SSH ...


5

If you don't have LDAP configured on the NFS server you lack the username <--> UID and groupname <--> GID number mappings there. No problem you can simply use the numerical UID and GUID values in chown. Normally though you really should have LDAP and Kerberos enabled on the NFS server, as that not only allows you to use the user and group names in ...


4

usr1 is using a md5 hash indicated by $1 and usr2 using sha512 hash indicated by $6. Use authconfig --test | grep hashing to see what method is in force now. The reason why is probably that the usr2 user got added after an OS upgrade where the default algorithm changed from MD5 to SHA512. See this link for a bit of background: http://www.akkadia.org/...


4

Or .. start your box in single user mode and modify your passwd file - ubuntu single user mode link.


4

Try: usermod -d /var/www/clients/client1/web3 web3 or just vipw without -s.


4

In your /etc/pam.d/common-password , change the minimum_uid in your first line to something bigger than 1000, example: password [success=3 default=ignore] pam_krb5.so minimum_uid=10000 That worked for me. This is what you should see in /var/log/auth.log after changing the password for that user as root: Dec 26 12:34:36 3.8.0-29-generic passwd[...


4

After some chat on the #chef IRC channel, here's what I ultimately needed to know. Most of it is actually peripheral info, rather than openssl passwd specific, but anyway... Chef users the standard adduser command (http://linux.die.net/man/8/adduser) for adding users. That command accepts the password already encrypted - Hence why you need to store an ...


4

I believe the answers you've got so far are slightly inaccurate or at least incomplete. You specifically mention that the question is related to Solaris 11 and this is important to the answer. If no shell is explicitly mentioned in /etc/passwd then it is correct as the man page says that /usr/bin/sh will be used but this is a logical link to Korn 93 Shell. ...


4

Be careful that you don't delete or renumber system accounts when copying over the files mentioned in the other answers. System services don't usually have fixed user ids, and if you've installed the packages in a different order to the original machine (which is very likely if it was long-lived), then they'll end up in a different order. I tend to copy ...


4

What security problem? If you have 2 devices logged in as root and you're worried about one changing the password before the other you have bigger issues to worry about. Just so you know, the password and shadow files are owned by root, so if someone is logged in as root they can do whatever they want to the password. They don't even need to worry about ...


4

Kerberos never allows the client to get its hand on the password or a hash of the password (like many of the good authentication systems do). This basically means that you cannot do this. Th behavior that you describe for that application means that it doesn't use PAM but instead it directly manipulates /etc/passwd and /etc/shadow. Otherwise it would go ...


3

The GECOS field is in /etc/passwd, not /etc/shadown. I've been using UTF-8 realnames there with no adverse effects for years. (The adduser utility on Debian used to let me specify UTF-8 usernames a long time ago, but later started rejecting them. I sometimes wonder why.)


3

It's not actually a required package (only a recommended one): $ aptitude why rtkit i pulseaudio Recommends rtkit So you can remove it (though you may find you need if your pulseaudio app doesn't sound so good afterwards - but you can just reinstall it): sudo apt-get remove rtkit


3

to temporarily lock a user's account you can do passwd -l username which simply adds a '!' to the beginning of the password hash in /etc/shadow, preserving the user's password, and preventing them from being able to log in with any password.


3

There's no reason you couldn't edit it directly. You just have to remember that if you run authconfig, your changes will likely be blown away. We certainly edit the file directly on all of our systems because authconfig isn't flexible enough for our tastes (and doesn't fit in well with the config management tools we use). So, it's safe as long as you ...


3

remove password required pam_deny.so


3

Ubuntu does have a root user account. You just enabled it. To test this, try logging in as root and giving the password you just created at the prompt. You will be logged in as root.



Only top voted, non community-wiki answers of a minimum length are eligible