5

When I SSH into a server, as anything other than root, it only shows a $ and not the path. It also won't allow me to press the up key and see the command history when I don't SSH in as root. How do I give other users the mentioned options?

7

There are two steps to accomplish this.

Step 1) Make sure your users are using the bash shell. Look at the entry for each user in /etc/passwd and ensure it ends in /bin/bash. For example, if you see this:

joeuser:x:1234:1234:Joe User:/home/joeuser:/bin/sh

then change it to this:

joeuser:x:1234:1234:Joe User:/home/joeuser:/bin/bash

Using bash should fix the up-arrow problem and will enable the next step.

Step 2) If you still don't see a prompt with the current working directory, then tell bash that's what you want. There are two ways to do this. Add the following line:

export PS1='\w> '

to either

  1. Each user's .bash_profile file; OR
  2. The system-wide /etc/profile file

This line assigns the PS1 variable, which represents the main shell prompt. I recommend putting it in /etc/profile as this is easier and provides a helpful prompt to all your users. If a user wants something else for their prompt, they can always edit their own .bash_profile file.

Note: if your system has a /etc/bash.bashrc then put the line there instead of /etc/profile.

| improve this answer | |
1

My passwd(5) man page says this about the last field of an /etc/passwd entry, called the “command interpreter”:

The command interpreter field provides the name of the user's command language interpreter, or the name of the initial program to execute. The login program uses this information to set the value of the $SHELL environmental variable. If this field is empty, it defaults to the value /bin/sh.

So, it looks like your options are to:

  1. Put your users in the /etc/passwd file.
  2. Have your users information available by NIS or some other network means.
  3. Link /bin/sh to some other shell. I don’t recommend this because programs most likely rely on the behaviour of the existing /bin/sh.
| improve this answer | |
1

This sounds quite odd since—by default—any non-root user should be able to have the basic functionality you describe. That said, this issue does sound familiar. Whenever I setup a user on Ubuntu (Debian) I use adduser which works fine; but I have always had issues with useradd. As it states in the official man page for useradd:

useradd is a low level utility for adding users. On Debian, administrators should usually use adduser(8) instead.

The reason boils down to the fact that useradd is ultimately a low-level system binary that requires more commands than just a username to add paths and shell info for a new user. In contrast, adduser is a Perl script wrapper for useradd that provides a nicer, user-friendly workflow to create a new user to the system without much thought. Just think of adduser as a “wizard” setup for useradd.

So, if you added a user via useradd chances are you missed a config setting in the command-line options. So technically, you did add a user to the system, but not much else in the way of system configuration. In contrast, adduser is designed to handle all of the sundry basics.

Knowing that, what I would recommend is you delete any user you have already created like this; of course change [username] to the actual username:

sudo deluser --remove-home [username]

And then recreate that user with adduser like this:

sudo adduser [username]
| improve this answer | |

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.