I'm doing this over ssh.

I want to create a user that:

  • can't be accessed via ssh

  • can be impersonated with su

  • doesn't have a password (is this a good practice?)

  • can run web apps (specifically with pm2 (nodejs))

This is how we do it at work -- I access a server via ssh (pem key) and then su to the nodejs user and run the app. I've read a few answers here but they are usually in the form of "I created a user but it doesn't work, what's wrong"

I created a user with adduser nodejs --system --group but it has a password that I don't know. Perhaps I just need to add something to that command.

OS is Mint/Ubuntu.

  • 2
    What makes you think that it has a password? – AlexP Feb 2 '19 at 23:36
  • You can add users explicitly to be denied in the sshd config and it's perfectly possible to have a user without a password (username:: in /etc/shadow - can be set various ways). Changing to the user with su would require some changes though as by default su will prompt for a password and an empty one will fail. See the top answer on unix.stackexchange.com/questions/113754/… - however I'd be much more tempted for this use case to use sudo -u username to execute commands as the user rather than trying to circumvent security on su. – Dave C Feb 3 '19 at 1:03
  • @DaveC you've depicted a user which won't prompt for a password. Depending on the pam configuration, an ssh connection may log into that just fine - but won't get any prompt blocking them. username:x: on the other hand, assuming a system that uses hashed passwords (like virtually all these days), will prompt for a password but none will be valid. – Ed Grimm Feb 3 '19 at 2:54
  • 1
    sudo -u username is probably a much better way to get access to such a restricted account than su, as it uses the credentials from the originating account rather than the target account. One would, of course, need sudo configured to allow that. – Ed Grimm Feb 3 '19 at 2:56
  • 2
    @NasirRiley sudo su sets off my bad code sense. I especially twitch when someone doesn't even bother to give a username to su, but is instead doing that to get their root prompt. I understand it doesn't matter really. But why would I suggest someone run two commands rather than one, especially when the second command would work around the added sophistication of the first? For me, su is just an emergency way to get root access to fix my coworker's mistake with the /etc/sudoers file and otherwise bad memories I want to forget. – Ed Grimm Feb 3 '19 at 20:32

By default, most Linux distributions don't set a password for new users, but instead create it with password authentication disabled. The account doesn't appear from the outside to have that disabled - you still get prompted. But no password will work.

If you set a password, someone who knows that password will be able to ssh to it. But you don't need to set a password to be able to switch to the account, if your system has the sudo package installed and your account is in the wheel group, or sudo has been specifically configured to allow your account to switch to that user.

Assuming sudo is configured to let you change to that user and run any command,

sudo -u nodejs -H -s -i

will prompt you for your credentials (which I would assume is your password), and after you successfully enter them, will log you into the account with the target user's login shell. (-i says to make the shell be the target user's login shell.)

If your account is not configured to allow you to use sudo to switch to that user and run any command, how to configure that is a separate and much larger question. But before you ask that question, read the sudo and sudoers manpages (man sudo sudoers)

  • OK so we should add adduser nodejs --system --group to create the user and this answer is complete (assuming the user running the commands has sudo access), yes? – jcollum Feb 3 '19 at 21:10
  • In your question, you said you already made the user. But as far as the concern I feel like you are raising, yes. The sudo command I specified is safe to run. It basically just logs in as the user specified by the -u option, using that user's home directory, and running your shell. – Ed Grimm Feb 3 '19 at 21:26
  • There is a problem here though: when I su to the user the user's bashrc isn't sourced. I need the bashrc for some env vars that are used by NVM and PM2. Do I have to have a login shell to accomplish that? I suppose I could source it every time I log in... – jcollum Feb 3 '19 at 21:38
  • I get the feeling you're not understanding there's no need for su with sudo. In my experience, without the -i option, sudo -s gives me a $SHELL login shell. With it, it uses the target user's configured shell and makes a login shell. My experiences with su have made me feel it's more often than not a frustrating way to go. sudo may be more complicated, but it at least works as documented and it doesn't have different behavior due to differences in the OS it's running on. It also has more options and flexibility. – Ed Grimm Feb 3 '19 at 22:35
  • In my experience when you run any node.js install with sudo it gets messed up. I avoid it unless I need it. – jcollum Feb 4 '19 at 2:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.