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?
3 Answers
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
- Each user's
.bash_profile
file; OR - 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
.
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:
- Put your users in the
/etc/passwd
file. - Have your users information available by NIS or some other network means.
- 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
.
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 useadduser
(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]