Secondary login credentials

Sometimes I need to access my files on my servers using SSH/SCP from an untrusted device and/or application. Usually I would create a new SSH key pair so that I can easily revoke these credentials later if such need arises. But what if the used application doesn’t support SSH keys or we do not want to use them for some reason?

There is a trick supposedly used by sysadmins in the olden days, before sudo was around. I assume you’re at least aware of the /etc/passwd file that contains the basic information about all the system users. Information such as the username, historically hash of the password1, the user and group ID (UID and GID). It looks like this:

vifon:x:1000:1000:Wojciech Siewierski,,,:/home/vifon:/bin/zsh

The trick is to create a second line for your user — with the same UID but a different username.

vifon:x:1000:1000:Wojciech Siewierski,,,:/home/vifon:/bin/zsh
alsovifon:x:1000:1000:Wojciech Siewierski,,,:/home/vifon:/bin/zsh

Such user has a separate password (among other things) but once you log in, it functions almost the same as your regular user.

What do we gain this way? The most important part to me is that in case the credentials get compromised, only the password to the secondary username needs to be changed.

Are there any other differences between our twin users? The following ones come to my mind:

Groups in /etc/group are assigned to usernames, not UIDs. Usually our user after a login with a secondary username belongs only to its main group (defined by GID specified in /etc/passwd). Seemingly as an added benefit the compromised credentials cannot be used for instance to manage Docker even if normally the user would be privileged to do so. I said seemingly… Well, nothing stops the user from using newgrp(1) to change their group to any group associated with our primary username.
Login shell
Login shell may be changed separately for each username. I didn’t find it particularly useful but maybe you will.
Home directory
The home directory also may be changed separately. Once again, might come useful but I didn’t use it.

I definitely do not recommend using this technique on important servers but it’s a workaround that comes in handy here and there.

  1. These days usually x is placed in this field which means “the actual hash is in /etc/shadow“.