The sys-apps/shadow package on my GNU / Linux system comes with a useradd command that supports an option that I have previously overlooked: --non-unique. For the sake of convenience when shellig home from the university, I have created an alias for my original username (casual name at home) thusly:

useradd --non-unique -u 1001 \
     --no-create-home --home-dir /home/casualname \
     -g 1001 -G `id casualname -G | tr ' ' ,` universityUsername

This allows me to login from campus with the login universityUsername without creating a ~/.ssh/config alias or specifying the -l option for ssh. After logging in, whoami reports that I am casualname. This is due to the fact that casualname appears closer to the top of the /etc/passwd file.

I wonder how widely supported such aliases are and if there are any drawbacks to using them. And also, is there a way to select the preferred user alias as the acting one (what $USER is set to) on a system where the user can not re-order entries in /etc/passwd?


5 Answers 5


You can't have several users with the same UID. If they have the same UID, then they're the same user.

What you have is multiple entries in the user database for the same user. That's possible in all unix variants I've seen. The user name determines which entry is used and thus which password, home directory and shell applies at login time. The first entry determines what id-based lookups to the user database will return. Some applications look up the user database by name (using perhaps $USER), others by UID; if they use the UID, then they'll get the first entry and you can't do anything about it.

This is a cute setup, but it's one of these cute but mostly useless things. It's unusual: if you have any fellow administrator, they won't thank you for it; many applications won't bother to cover this case and may behave suboptimally (e.g. depend on your $LOGNAME for some functionality, resulting in using different data depending on what user name you logged in as). It's also error-prone: you need to use root access to create the second entry, you need to remember to edit both entries in passwd or shadow (e.g. to change your password, which will require root access unlike normal passwd invocation). You should do that only if you have a very good reason.

If all you wanted was to have the same username for SSH, then the way everybody else does it is with aliases in .ssh/config. That's what they're for. It's simpler to set up, doesn't require more privileges, and doesn't set up an unusual and potentially confusing configuration.

One useful use of multiple entries for the same user is a rescue user when things go wrong. For example, a toor account (traditional name) whose shell is a statically-linked binary, which you use only for system repair.

  • 1
    Error-prone because you feel so? You will forgive me if I don't take your word for it. Commented Apr 22, 2014 at 12:20
  • @ЯрославРахматуллин This requires using root access and editing the passwd and shadow files manually. You need to remember the existence of the multiple entries for any maintenance such as updating your password. Then you'll run into cases where applications get inconsistent information about your user name (one from the login name, one by looking the name corresponding to your UID). Commented Apr 22, 2014 at 13:57
  • Thanks for elaborating on your answer. The chapter Multiple accounts with the same UID from Practical Unix and Internet Security mentions that "This approach should only be used for system-level accounts, not for personal accounts" without providing any compelling reasons (like your answer). - The maintenance overhead of invoking passwd for the aliases and "copying" groups from the original user is not a problem on a personal desktop. I lack the experience to see grievous implications of this approach, without ruling out that it may not be worth the effort. Commented Apr 23, 2014 at 1:08
  • "The user name determines which entry is used and thus which password, home directory and shell applies at login time." This is not true, or at least not always, especially on a system that uses nsswitch.conf to use multiple sources. If the duplicate users are on different sources, the system will use the user name to look up the UID, and then use the home directory, password etc. from the first entry that has that UID, regardless of the user name. Commented Oct 10, 2023 at 2:06
  • The reason that chapter doesn't elaborate is because it expects anyone who understands enough about how POSIX works to actually set it up will understand enough to know it's almost always a bad idea. Commented Jan 5 at 7:00

It is not recommended because it is not a true alias. Some programs, such as kerberos, recognize the user by name instead of UID.

For example, following may work

kinit universityUsername

but following are not guarantee to work

kinit casualname

Unless you know whether UID or username the programs actually use, you confuse yourself and the program you use, thus it is not the best practice.


I've used such an alias for the root user so that I can specify a different login shell (and home directory). So my zoot user is root, but with zsh as the login shell and my home directory as the home directory, so that zoot gets all of my shell configuration (~/.z* files for aliases etc.). It's very convenient. And it means I don't have to modify root's setup in any way, which would be great if there are any other administrators.

The only side effect I've noticed is that, if you use rkhunter, you have to let it know that it was really you that did it:


In my experience, there are no obvious drawbacks to this approach. Other than some odd application may get confused. Thus far, this has not happened to me, but my setup is fairly simple.

I would not recommend using this on a system where you are not the only user.

For the second part of the question, no there is no way to do that. Also, on a system where you don't have root is also a system where a double-username setup is not likely to exist.

  • Changing UID on the fly, while the user is logged in can cause a lock out, especially on a hardened system (apparmor, pam, ). Remember to keep a shell open (as root) and chown $HOME/.ssh to the new UID, set the same password for both users (on a local system), and re-test access before logging out. Again, all of this is sort of undefined behavior, so don't do it in production because you don't want surprises in production. Commented May 2, 2023 at 9:08

I'm using this setup on servers that authenticate against LDAP. A few important (admin) users also have local accounts so we don't get locked out if there is a LDAP or network problem. Using the same uid means that all the standard setup is immediately available.

I also noticed the behavior of the $USER variable. It is actually a bug, probably in glibc.

Generally, in this scenario, you are supposed to "be" whatever user name you logged on with. Looking up the user name from the user ID is incorrect behavior.

Another important aspect to be aware of (you took care of it, but I want to highlight it for other readers): group membership is determined by name, not by user ID. That means that in your scenario, you have to add universityusername to all the same groups that casualuser is in.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .