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
- 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 usingnewgrp(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.
-
These days usually
x
is placed in this field which means “the actual hash is in/etc/shadow
”. ↩︎