2

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.

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
jcollum
  • 1,149
  • 1
  • 11
  • 24
  • 2
    What makes you think that it has a password? – AlexP Feb 02 '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 https://unix.stackexchange.com/questions/113754/allow-user1-to-su-user2-without-password - 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 03 '19 at 01: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 03 '19 at 02: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 03 '19 at 02:56
  • @EdGrimm absolutely - what I meant, perhaps unclearly, by "require some changes" (the PAM configuration), also you would need to specifically block the user in your sshd config (explicit user or group) as I mentioned at the top. Frankly I just took it as an academic question (hence the comment not an attempt at answer) because ultimately, as you also say, using sudo would be a much better (secure, flexible, auditable, etc) way of working. – Dave C Feb 03 '19 at 11:25
  • @AlexP when I try to `su` that user I get a password challenge – jcollum Feb 03 '19 at 19:48
  • @NasirRiley I don't recall a requirement that no one can su as that user... ? – jcollum Feb 03 '19 at 19:49
  • @EdGrimm sounds like you've got a clear idea of what I should do, can you write up an answer? – jcollum Feb 03 '19 at 19:50
  • *"When I try to su that user I get a password challenge":* This does not mean that the user account has an associated password. It is likely that it does *not* have a password, that is, password authentication is disabled for the account. – AlexP Feb 03 '19 at 19:52
  • OK then if I can't get past that password challenge the account is useless to me – jcollum Feb 03 '19 at 19:53
  • @EdGrimm As that is an error on my part (reading can't in the previous line), I have deleted my previous two comments. Of course, as he has `sudo` on the machine considering that he created the user, there's no reason why he wouldn't be able to use `su` to get to the user. – Nasir Riley Feb 03 '19 at 20:26
  • 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 03 '19 at 20:32
  • @EdGrimm Personally, I run `sudo su -` to become `root` and then use `su -l` to switch to another user. Of course, I'm assuming that questionner is already `root` when switching to the `nodejs` user. He could also just create a `cronjob` or otherwise just have a script that runs as the user instead of having to `su` to the user. – Nasir Riley Feb 03 '19 at 20:43

1 Answers1

1

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)

Ed Grimm
  • 651
  • 4
  • 8
  • 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 03 '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 03 '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 03 '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 03 '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 04 '19 at 02:12