Tag Info

Hot answers tagged

17

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


13

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 ...


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) ...


10

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.


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.


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

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.


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

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

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

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>.


4

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


4

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


3

Boot up into a live disk, mount the partition and fix /etc/passwd :)


3

See the manpage for adduser: useradd is a low level utility for adding users. On Debian, administrators should usually use adduser(8) instead.


3

The purpose of that command is to feed your password through a one-way hashing algorithm (-1 outputs MD5). What that gets you is a string that's derived from your password cryptographically, but cannot be used to find your password on its own if an attacker gets their hands on the hashed version (theoretically - there's a salt included which helps against ...


3

No, this is not going to work, at least not in any reliable form, and it's quite likely these files are needed before NFS shares could be mounted, which would make it impossible. If you have such problems with LDAP, you might have a look into NIS, which is an kind of an (ancient) predecessor of LDAP and is arguably easier to get running. But as I said, ...


3

Process to reset the password is in the Ubuntu Documentation: https://help.ubuntu.com/11.04/ubuntu-help/user-forgottenpassword.html


3

In a Linux system... there is always a root account. Most of the time it is configured to prevent users from logging in as root, but it still exists. "sudo passwd" will set a password for the user root. In some cases, this will do nothing, as root is not permitted to login. In others, it will actually enable the root account for login. (depending on ...


3

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.


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.


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

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: ...


3

Direct from the proftpd docs: Question: If virtual users are not defined in the system /etc/passwd file, then where are they defined? Answer: There are several other locations where user information can be stored, e.g. AuthUserFiles, LDAP directories, SQL databases, and RADIUS servers. Note that virtual users are not defined in the proftpd.conf file ...


3

You could probably do something with ssh force-commands in the ~/.ssh/authorized_keys file. This works on a CentOS system I have to hand. Change the authorized_key file entry for the relevant key so that it runs passwd command="/usr/bin/passwd" ssh-rsa AAAAB3NzaC1yc2EAA... When someone logs in using that key the /usr/bin/passwd program (and only that ...



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