|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
|News||Access Control||Recommended Links||Rainbow Books||Root Account||The /etc/passwd File||Root Security|
|ACL||Solaris ACLs||Linux ACL||Solaris RBAC||Sudo||PAM||UID policy|
|Group administration||Wheel Group||Authentication||Unix permissions model||History||Humor||Etc|
On most Unix systems the user accounts are listed in the database file /etc/passwd; the corresponding passwords for these accounts are kept in a file named /etc/shadow, /etc/security/passwd, or /etc/master.passwd. To improve lookup speed, some systems compile the password file into a compact index file named something like /etc/pwd.db, which is used instead. In general, after, say, 256 user you need something better that a text file. But most server contain less the a hundred accounts. For them passwd files is "perfect" as it is simple, reliable (stored locally so it does not depend on the availability of network) and can be synchronized/distributed with/to multiples servers, if necessary via ssh or other protocol. More complex alternative authentication scheme such as Kerberos or Active Directory are often an overkill in such cases.
The /etc/passwd file contains basic user attributes. This is an ASCII file that contains a line for each user. Each entry consists of seven fields
Here is an example of an /etc/passwd file from a Red Hat 5.8 system containing a variety of system and ordinary users:
cat /etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin news:x:9:13:news:/etc/news: uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin games:x:12:100:games:/usr/games:/sbin/nologin gopher:x:13:30:gopher:/var/gopher:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin nscd:x:28:28:NSCD Daemon:/:/sbin/nologin vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin ntp:x:38:38::/etc/ntp:/sbin/nologin pcap:x:77:77::/var/arpwatch:/sbin/nologin dbus:x:81:81:System message bus:/:/sbin/nologin avahi:x:70:70:Avahi daemon:/:/sbin/nologin rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin apache:x:48:48:Apache:/var/www:/sbin/nologin sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin dovecot:x:97:97:dovecot:/usr/libexec/dovecot:/sbin/nologin oprofile:x:16:16:Special user account to be used by OProfile:/home/oprofile:/sbin/nologin rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin xfs:x:43:43:X Font Server:/etc/X11/fs:/sbin/nologin haldaemon:x:68:68:HAL daemon:/:/sbin/nologin avahi-autoipd:x:100:156:avahi-autoipd:/var/lib/avahi-autoipd:/sbin/nologin gdm:x:42:42::/var/gdm:/sbin/nologin sabayon:x:86:86:Sabayon user:/home/sabayon:/sbin/nologin
There is generally nothing special about any Unix account name. All Unix privileges are determined by the UID plus the group ID (GID). Account name is just a label for UID, a numeric value. For example, an account with name root and UID 1005 would have no special privileges, but an account named lowlyuser with UID 0 would be a superuser.
In general, you should avoid creating users with a UID of 0 other than root, and you should avoid using the name root for a regular user account. So in most case when people talk about account "root" or "superuser" account in Linux/Unix they mean the account with the UID of 0.
Unix keeps the mapping between usernames and UIDs in the file /etc/passwd. Each user's UID is stored in the third field of this file, after the one which in the past contained the user's encrypted password (and still contain in case on NIS users).
The UID is the actual information that the operating system uses to identify the user; usernames are provided merely as a convenience for humans. If two users are assigned the same UID, Unix views them as the same user, even if they have different usernames and passwords. Two users with the same UID can freely read and delete each other's files and can kill each other's running programs. Giving two users the same UID is almost always a bad idea; it is better to create multiple users and put them in the same group.
Conversely, files can be owned by a UID that is not listed in /etc/passwd and do not have an associated username. This is a typical situation when the user was deleted but some of his/her files stayed. This is actually a sign of sloppy system administration. If a user is added to /etc/passwd in the future with that UID, that user will suddenly become the owner of the files, which might be not a good idea.
NOTE: you can provide the ability to login to other user account iether via SUDO, or via ssh passwordless login.
From passwd - Wikipedia
/etc/shadowis used to increase the security level of passwords by restricting all but highly privileged users' access to hashed password data. Typically, that data is kept in files owned by and accessible only by the super user.
Systems administrators can reduce the likelihood of brute-force attacks by making the list of hashed passwords unreadable by unprivileged users. The obvious way to do this is to make the
passwddatabase itself readable only by the root user. However, this would restrict access to other data in the file such as username-to-userid mappings, which would break many existing utilities and provisions. One solution is a "shadow" password file to hold the password hashes separate from the other data in the world-readable passwd file. For local files, this is usually
/etc/shadowon Linux and Unix systems, or
/etc/master.passwdon BSD systems; each is readable only by root. (Root access to the data is considered acceptable since on systems with the traditional "all-powerful root" security model, the root user would be able to obtain the information in other ways in any case). Virtually all recent Unix-like operating systems use shadowed passwords.
The shadow password file does not entirely solve the problem of attacker access to hashed passwords, as some network authentication schemes operate by transmitting the hashed password over the network (sometimes in cleartext, e.g., Telnet), making it vulnerable to interception. Copies of system data, such as system backups written to tape or optical media, can also become a means for illicitly obtaining hashed passwords. In addition, the functions used by legitimate password-checking programs need to be written in such a way that malicious programs cannot make large numbers of authentication checks at high rates of speed.
Regardless of whether password shadowing is in effect on a given system, the passwd file is readable by all users so that various system utilities (e.g., ls) can work (e.g., to ensure that user names are shown when the user lists the contents of a folder), while only the root user can write to it. Without password shadowing, this means that an attacker with unprivileged access to the system can obtain the hashed form of every user's password. Those values can be used to mount a brute force attack offline, testing possible passwords against the hashed passwords relatively quickly without alerting system security arrangements designed to detect an abnormal number of failed login attempts. Especially when the hash is not salted it is also possible to look up these hashed passwords in rainbow tables, databases specially made for giving back a password for a unique hash.
With a shadowed password scheme in use, the
/etc/passwdfile typically shows a character such as '
*', or '
x' in the password field for each user instead of the hashed password, and
/etc/shadowusually contains the following user information:
- User login name
- salt and hashed password OR a status exception value e.g.:
- "$id$salt$hashed", the printable form of a password hash as produced by crypt (C), where "$id" is the algorithm used. On GNU/Linux, "
$1$" stands for MD5, "
$2a$" is Blowfish, "
$2y$" is Blowfish (correct handling of 8-bit chars), "
$5$" is SHA-256 and "
$6$" is SHA-512, other Unix may have different values, like NetBSD. Key stretching is used to increase password cracking difficulty, using by default 1000 rounds of modified MD5, 64 rounds of Blowfish, 5000 rounds of SHA-256 or SHA-512. The number of rounds may be varied for Blowfish, or for SHA-256 and SHA-512 by using e.g. "$6$rounds=50000$".
- Empty string – No password, the account has no password (reported by passwd on Solaris with "NP").
- "!" – the account is password locked, user will be unable to log in via password authentication but other methods (e.g. ssh key) may be still allowed.
- "*LK*" or "*" – the account is locked, user will be unable to log in via password authentication but other methods (e.g. ssh key) may be still allowed.
- "!!" – the password has never been set (RedHat)
- Days since epoch of last password change
- Days until change allowed
- Days before change required
- Days warning for expiration
- Days before account inactive
- Days since epoch when account expires
The format of the shadow file is simple, and basically identical to that of the password file, to wit, one line per user, ordered fields on each line, and fields separated by colons. Many systems require the order of user lines in the shadow file be identical to the order of the corresponding users in the password file.
Every Unix user belongs to one or more groups. As with user accounts, groups have both a group name and a group identification number (GID). Historically GID values were also 16-bit integers, but many systems now use 32-bit or 64-bit integers for these, too.
As the name implies, Unix groups are used to group users together. As with usernames, group names and numbers are assigned by the system administrator when each user's account is created. Groups can be used by the system administrator to designate sets of users who are allowed to read, write, and/or execute specific files, directories, or devices.
Each user belongs to a single primary group that is stored in the /etc/passwd file. The GID of the user's primary group follows the user's UID. Historically, every Unix user was placed in the generic group called users, which had a GID of 100. These days, however, most Unix sites place each account in its own group. This results in decreased sharing, but somewhat better security and flexibility for sysadmin:
The advantage of assigning each user his own group is that it allows users to have a unified umask of 007 in all instances. When users wish to restrict access of a file or directory to themselves, they leave the group set to their individual group. When they wish to open the file or directory to members of their workgroup or project, all they need to do is to change the file's or directory's group accordingly.
Consider, again, our /etc/passwd example:
In this example, primary GID is 9262 which might be the badge number for this particular user. Generally it makes sense to assign users unique UID and primary group id (GID) uniformly on multiple servers. This simplifies the transfer of files between servers -- they are automatically owned by the same user.
Groups provide a handy mechanism for providing a subset of users access to some subset of files. For example, you might want to set up a group for a team of researchers working on a project (for example decoding of genome), so that only researchers from this group, but nobody else, can read and modify the genome FASTQ/FASTA files.
Groups can also be used to restrict access to sensitive information or specially licensed applications to a particular set of users: for example, many Unix computers are set up so that only users who belong to the kmem group can examine the operating system's kernel memory.
Similarly user wheel group usually list users who have root access to the system with the first one considered to be "primary system administrator" for the particular server. In case datacenter has a thousand of server that greatly simplify determining who need to contacted for the particular server problem even if the person who discovered the problem does not have access to spreadsheet or database with the servers assignment for sysadmin group. In a large corporation when a ticket can travel in the helpdesk jungles for a week or so that increase chances that the user or server problem will be resolved promptly.
You can also have a group tempadmin which are people who need root access for specific and short period of time. You can grand them access to root via sudo and schedule at command for the end of the period that automatically removes the user from this group.
The operator group is commonly used to allow only specific users to perform operations with media such as DVD, USB flash drives, as well as the tape backup system, which may have "read" access to the system's raw disk devices.
And a privileged group might be limited to people who have signed nondisclosure forms so they can view the source code for particular software or sensitive files.
RHEL supports mandatory access controls (MAC), which have controls based on data labeling in addition to the traditional Unix discretionary access controls (DAC). This system called SE linux is often disabled for internal "infrastructure" servers, as it unnecessary complicates things, but should be enabled for all server facing Internet and servers with privileged information such as credit cards data.
The /etc/group file contains the database that lists every group on your computer and its corresponding GID. Its format is similar to the format used by the /etc/passwd file.
bezroun@lustwz54: $ cat /etc/group root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon sys:x:3:root,bin,adm adm:x:4:root,adm,daemon tty:x:5: disk:x:6:root lp:x:7:daemon,lp mem:x:8: kmem:x:9: wheel:x:10:root,bezroun mail:x:12:mail news:x:13:news uucp:x:14:uucp man:x:15: games:x:20: gopher:x:30: dip:x:40: ftp:x:50: lock:x:54: nobody:x:99: users:x:100: utmp:x:22: utempter:x:35: nscd:x:28: vcsa:x:69: ntp:x:38: pcap:x:77: slocate:x:21: dbus:x:81: audio:x:63:gdm avahi:x:70: rpc:x:32: mailnull:x:47: smmsp:x:51: apache:x:48: sshd:x:74: dovecot:x:97: oprofile:x:16: screen:x:84: rpcuser:x:29: nfsnobody:x:65534: xfs:x:43: stapdev:x:101: stapusr:x:102: stap-server:x:155: haldaemon:x:68: avahi-autoipd:x:156: gdm:x:42: sabayon:x:86:
One important group is the Wheel Group.
Group's "password" (obsolite)
List of the users who are in the group
Most versions of Unix use the wheel group as the list of all of the computer's system administrators (in this case, bezroun and the root user are the only members). On some systems, the group has a GID of 10; on other systems, the group has a GID of 15. Unlike a UID of 0, a GID of 0 is usually not significant. However, the name wheel is very significant: on many systems the use of the su command to invoke superuser privileges is restricted to users who are members of a group named wheel.
Linux and Solaris have an id command that offers more detailed UIDs, GIDs, and group lists:
Few sysadmins and users know that you can change the user active group using the newgrp command. This is useful when a user wants to create files owned by a group other than his default group.
$ id uid=10001(furrycat) gid=100(users) $ newgrp project27 $ id uid=1001(furrycat) gid=866(project27)
Solaris and other versions of Unix derived from AT&T SVR4 allow users to use newgrp to switch to a group that they are not a member of if the group is equipped with a group password:
$ newgrp fiction password: rates34
This looks like a backdoor and generally should be avoided.
But theoretically we can state that the password in the /etc/group file is interpreted exactly like the passwords in the /etc/passwd file. However, most systems do not have a program to install or change the passwords in this file. To set a group password, you must first assign it to a user with the passwd command, then use a text editor to copy the encrypted password out of the /etc/passwd file into the /etc/group file. Alternatively, you can encode the password using the proper program (if present) and edit the result into the /etc/group file in the appropriate place.
Group passwords are rarely used and can represent a security vulnerability, as an attacker can put a password on a critical group as a way of creating a back door for future access.
Root can impersonate any user. for regular user in order to be able to impersonalized another user he/she need to know the other user password. But this is against most corporation security policies to share password.
The alternative and more flexible way is to provide such a capability via sudo.
Another alternative is using passwordless SSH login.
Linux distributions usually provide a pwck utility. This small utility will check the consistency of both files and state any specific issues. By specifying the -r it may run in read-only mode. It also can sort /etc/passwd, /etc/shadow and /etc/group files.
The pwck command verifies the integrity of the users and authentication information. It checks that all entries in /etc/passwd and /etc/shadow have the proper format and contain valid data. The user is prompted to delete entries that are improperly formatted or which have other uncorrectable errors.
Checks are made to verify that each entry has:
- the correct number of fields
- a unique and valid user name
- a valid user and group identifier
- a valid primary group
- a valid home directory
- a valid login shell
- shadow checks are enabled when a second file parameter is specified or when /etc/shadow exists on the system.
These checks are the following:
- every passwd entry has a matching shadow entry, and every shadow entry has a matching passwd entry
- passwords are specified in the shadowed file
- shadow entries have the correct number of fields
- shadow entries are unique in shadow
- the last password changes are not in the future
The checks for correct number of fields and unique user name are fatal. If the entry has the wrong number of fields, the user will be prompted to delete the entire line. If the user does not answer affirmatively, all further checks are bypassed. An entry with a duplicated user name is prompted for deletion, but the remaining checks will still be made. All other errors are warning and the user is encouraged to run the usermod command to correct the error.
The commands which operate on the /etc/passwd file are not able to alter corrupted or duplicated entries. pwck should be used in those circumstances to remove the offending entry.
The options which apply to the pwck command are:
- -q Report errors only. The warnings which do not require any action from the user won't be displayed.
- -r Execute the pwck command in read-only mode.
- -s Sort entries in /etc/passwd and /etc/shadow by UID.
By default, pwck operates on the files /etc/passwd and /etc/shadow. The user may select alternate files with the passwd and shadow parameters.
The number of records in /etc/passwd and /etc/shadow files should be identical and order of records should be identical too.
To ensure this you can sort both /etc/passwd and /etc/shadow by UID using
pwck -s and
grpck -s commands
You can also use Unix sort command.
sort -t ':' -n -k3,3 /etc/passwd
The chances are that your password database is in something of a state of disrepair. In the past people used to maintain the password file (/etc/passwd, /etc/shadow and /etc/group) by hand. That's what the vipw and vigr commands were for: locking the files while they were being edited to make sure that sysadmins didn't overwrite each other's work. And because they were hand edited, people tended to keep the files ordered by increasing user or group id.
These days, though, it's more likely that you'll be using a tool like useradd to put entries in these files, and these tools invariably plonk new entries at the end of the file. Adding and removing packages (with tools like rpm) can also create and delete users and groups, so after a few years of system upgrades you can finish up with files that are anything but sorted. That can be a real problem if you want to make sure two password files on different systems contain the same entries, for example.
Sorting the password and group files is actually really easy, because the Unix sort command is so flexible. The following command will sort the lines of the password file into ascending order by user id:and this will do the group file:$ sort -g -t : -k 3 /etc/passwdthose with sharp eyes will notice that the commands are the same: the user id and group id are the third fields in both files, and they both use : as a field separator, so the arguments to sort are the same.$ sort -g -t : -k 3 /etc/group
Ok, so that sorts the file, but the results just get printed to the terminal. How do we sort the password file in place? Well, you could play around with redirecting the output into a temporary file and then renaming it, but we can return to our old friends vipw and vigr for a slightly tidier solution. Run vipw to load the password file into vi, then type !G to filter the whole of the file through a command. You'll be prompted to enter the command at the bottom of the screen (in vim the prompt looks like :.,$!); enter sort -g -t : -k 3 and press return. The password entries should now be sorted into ascending order. If all seems well save the file and quit the editor. You can then run vigr to do the same transformation on your group file.
What's that? Oh, vipw and vigr are prompting you to edit the shadow password and shadow group files, and they're not in order either? Ah, well that a more tricky problem - neither of these files contains the user id, so we really need to sort them so that the user names (or group names) are in the same order as the names in the password (or group) file, and that's a bit more than we can get sort to do.
There is another way to do all this though: the pwck and grpck commands have a little-known -s option that will sort their respective databases. So another way to get things sorted out would be:which is very brief, but we don't find out how to use sort that way...$ pwck -s $ grpck -s
In bash can read /etc/passwd file using the while loop and IFS separator as follows (Understanding -etc-passwd File Format - nixCraft )
#!/bin/bash # seven fields from /etc/passwd stored in $f1,f2...,$f7 # while IFS=: read -r f1 f2 f3 f4 f5 f6 f7 do echo "User $f1 use $f7 shell and stores files in $f6 directory." done < /etc/passwd
But it is better to use Perl for this purpose.
passwd - Wikipedia
Prior to password shadowing, a Unix user's hashed password was stored in the second field of their record in the
/etc/passwdfile (within the seven-field format as outlined above).
Password shadowing first appeared in Unix systems with the development of SunOS in the mid-1980s, System V Release 3.2 in 1988 and BSD4.3 Reno in 1990. But, vendors who had performed ports from earlier UNIX releases did not always include the new password shadowing features in their releases, leaving users of those systems exposed to password file attacks.
System administrators may also arrange for the storage of passwords in distributed databases such as NIS and LDAP, rather than in files on each connected system. In the case of NIS, the shadow password mechanism is often still used on the NIS servers; in other distributed mechanisms the problem of access to the various user authentication components is handled by the security mechanisms of the underlying data repository.
In 1987 the author of the original Shadow Password Suite, Julie Haugh, experienced a computer break-in and wrote the initial release of the Shadow Suite containing the
sucommands. The original release, written for the SCO Xenix operating system, quickly got ported to other platforms. The Shadow Suite was ported to Linux in 1992 one year after the original announcement of the Linux project, and was included in many early distributions, and continues to be included in many current Linux distributions.
In the past, it was necessary to have different commands to change passwords in different authentication schemes. For example, the command to change a NIS password was yppasswd. This required users to be aware of the different methods to change passwords for different systems, and also resulted in wasteful duplication of code in the various programs that performed the same functions with different back ends. In most implementations, there is now a single passwd command, and the control of where the password is actually changed is handled transparently to the user via pluggable authentication modules (PAMs). For example, the type of hash used is dictated by the configuration of the
pam_unix.somodule. By default, the MD5 hash has been used, while current modules are also capable of stronger hashes such as blowfish, SHA256 and SHA512.
Aug 07, 2018 | unix.stackexchange.com
Ned64 ,Feb 18 at 13:52My
/etc/grouphas grown by adding new users as well as installing programs that have added their own user and/or group. The same is true for
/etc/passwd. Editing has now become a little cumbersome due to the lack of structure.
May I sort these files (e.g. by numerical id or alphabetical by name) without negative effect on the system and/or package managers?
I would guess that is does not matter but just to be sure I would like to get a 2nd opinion. Maybe
rootneeds to be the 1st line or within the first 1k lines or something?
The same goes for
Kevin ,Feb 19 at 23:50"Editing has now become a little cumbersome due to the lack of structure" Why are you editing those files by hand? – Kevin Feb 19 at 23:50
Barmar ,Feb 21 at 20:51How does sorting the file help with editing? Is it because you want to group related accounts together, and then do similar changes in a range of rows? But will related account be adjacent if you sort by uid or name? – Barmar Feb 21 at 20:51
Ned64 ,Mar 13 at 23:15@Barmar It has helped mainly because user accounts are grouped by ranges and separate from system accounts (when sorting by UID). Therefore it is easier e.g. to spot the correct line to examine or change when editing with
vi. – Ned64 Mar 13 at 23:15
ErikF ,Feb 18 at 14:12You should be OK doing this : in fact, according to the article and reading the documentation, you can sort
/etc/groupby UID/GID with
grpck -s, respectively.
hvd ,Feb 18 at 22:59@Menasheh This site's colours don't make them stand out as much as on other sites, but "OK doing this" in this answer is a hyperlink. – hvd Feb 18 at 22:59
mickeyf ,Feb 19 at 14:05OK, fine, but... In general, are there valid reasons to manually edit /etc/passwd and similar files? Isn't it considered better to access these via the tools that are designed to create and modify them? – mickeyf Feb 19 at 14:05
ErikF ,Feb 20 at 21:21@mickeyf I've seen people manually edit
/etc/passwdwhen they're making batch changes, like changing the GECOS field for all users due to moving/restructuring (global room or phone number changes, etc.) It's not common anymore, but there are specific reasons that crop up from time to time. – ErikF Feb 20 at 21:21
hvd ,Feb 18 at 17:28Although ErikF is correct that this should generally be okay, I do want to point out one potential issue:
You're allowed to map different usernames to the same UID. If you make use of this, tools that map a UID back to a username will generally pick the first username they find for that UID in
/etc/passwd. Sorting may cause a different username to appear first. For display purposes (e.g.
ls -loutput), either username should work, but it's possible that you've configured some program to accept requests from username A, where it will deny those requests if it sees them coming from username B, even if A and B are the same user.
Rui F Ribeiro ,Feb 19 at 17:53Having root at first line has been a long time de facto "standard" and is very convenient if you ever have to fix their shell or delete the password, when dealing with problems or recovering systems.
Likewise I prefer to have daemons/utils users in the middle and standard users at the end of both
hvdanswer is also very good about disturbing the users order, especially in systems with many users maintained by hand.
If you somewhat manage to sort the files, for instance, only for standard users, it would be more sensible than changing the order of all users, imo.
Barmar ,Feb 21 at 20:13If you sort numerically by UID, you should get your preferred order. Root is always
0, and daemons conventionally have UIDs under 100. – Barmar Feb 21 at 20:13
Rui F Ribeiro ,Feb 21 at 20:16@Barmar If sorting by UID and not by name, indeed, thanks for remembering. – Rui F Ribeiro Feb 21 at 20:16
Aug 07, 2018 | linux-audit.com
Linux distributions usually provide a pwck utility. This small utility will check the consistency of both files and state any specific issues. By specifying the -r it may run in read-only mode.
Example when running pwck on /etc/passwd and /etc/shadow file
Aug 07, 2018 | serverfault.comI am migrating over a server to new hardware. A part of the system will be rebuild. What files and directories are needed to copy so that usernames, passwords, groups, file ownership and file permissions stay intact?
Ubuntu 12.04 LTS. linux passwd share | improve this question asked Mar 20 '14 at 7:47
Mikko Ohtamaa, Mar 20 '14 at 7:54/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 share | improve this answer edited Mar 20 '14 at 9:48 answered
Iain 102k 13 154 250
- 5 +1 from me. I wondered about
/homeas well; generally, ssh keys live in the home directories, so
~/.sshat least can be considered part of the authentication infrastructure. – MadHatter Mar 20 '14 at 8:33
- 2 @MadHatter: In truth I kind of assumed that the OP would know that they needed to copy the user home directories but I guess you never know here on SF :) – Iain Mar 20 '14 at 8:37
- 1 Don't worry, the author knows. – Mikko Ohtamaa Mar 20 '14 at 8:53
- 2 Although the above will work, you should realy copy over gshadow too. – symcbean Mar 20 '14 at 9:45
- 6 An important point: this assumes a server with file-based authentication only. To migrate a server that uses e.g. LDAP or NIS these files will not be enough, especially if the authentication server is on the same system. Other subsystems (e.g. Samba, SQL) may also have their own authentication databases. – thkala Mar 20 '14 at 16:55
| show 4 more comments up vote 13 down vote
I did this with Gentoo Linux already and copied:
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. share | improve this answer edited Mar 20 '14 at 11:52 answered Mar 20 '14 at 7:53
vanthome 560 3 10
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 those files to somewhere like /root/saved-from-old-system and hand-edit them in order to just copy the non-system accounts. (There's probably a tool for this, but I don't tend to copy systems like this often enough to warrant investigating one.)Mar 26 '14 at 5:36
Google matched content
passwd - Wikipedia
Understanding -etc-passwd File Format - nixCraft
Unix security - Wikipedia
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: August 08, 2018