0
  • First of all it doesn't load my PS1. It just prompts me with a $
  • The arrow keys instead of doing what they're supposed to do, the just echo things like: $ ^[[A

And that makes it very unusable. A couple of things to consider here:

  • This only happens when I login through ssh, it doesn't happen when I login directly to the server.
  • One of the users works pretty fine even with ssh; and that's the user that was setup during the installation of the OS (ubuntu server 14.04).
  • When I su - otherUser from within that user that works fine, everything works fine.

Here's the .bashrc in case you want to take a look at it (It is the same on all users including the one that works correctly):

function parse_git_branch () {
  git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}

RED="\[\033[0;31m\]"
YELLOW="\[\033[0;33m\]"
GREEN="\[\033[0;32m\]"
NO_COLOR="\[\033[0m\]"
#PS1="[\u@\h \W]\$"
export PS1="[\u@\h $YELLOW\W$NO_COLOR]$GREEN\$(parse_git_branch)$NO_COLOR\$ "

Here's an output log for when I try to login to the user the works properly ssh -vvv ubuntu@server: http://paste.ubuntu.com/15436267/

Here's an output log for when I try to login to the user the doesn't work properly ssh -vvv adam@server: http://paste.ubuntu.com/15436301/

  • 1
    What distro? It looks like you don't have TTY for that user (for some reason). Can you post the commands which you use to connect to the server with -vvv switches for both users (working and not working)? There will be some difference. – Jakuje Mar 20 '16 at 12:32
  • Seems almost the same. Then check the potential errors in the server log and permissions of /home, /home/adam, /home/ubuntu` and the respective *rc and .profile files. Also what is in sshd_config on server might be interesting. – Jakuje Mar 20 '16 at 13:15
  • The shell problem might be debugged by logging what the shell is doing, e.g. via ssh -l thatuser -t thathost "bash -x" or such. – thrig Mar 20 '16 at 15:47
  • What's the output of getent passwd mega | cut -d : -f 6-? What makes you think that your .profile isn't executed (your .bashrc clearly isn't, but I don't see any clue that your .profile isn't executed)? – Gilles Mar 20 '16 at 18:12
1

The symptoms you describe (very basic prompt only, arrow keys don't work) are consistent with having /bin/sh as your login shell, rather than /bin/bash as expected. /bin/sh is a small shell designed to run scripts fast, not to be comfortable for interactive use.

To check what your login shell is, run

getent passwd $USER

This displays a list of colon-separated fields, the login shell is the last one.

If the login shell is not the one you want, run chsh -s /bin/bash.

The reason you're getting bash in a terminal may be that somewhere in your configuration you're setting the SHELL environment variable to bash. Terminal emulators normally run the program indicated by SHELL, falling back to the login shell if SHELL is not set.

  • It is very often that /bin/sh is symlink to somthing else (/bin/bash on centos7 or /bin/dash on Ubuntu 14.04, for example), so it should be checked first. Dash doesn't not process .bashrc – Boban P. Mar 20 '16 at 22:20
  • @BobanP. /bin/sh is dash on Ubuntu. Dash does not process .bashrc. – Gilles Mar 20 '16 at 22:25
  • ok, so that's the reason why it's not working as expected. You should update the answer. – Boban P. Mar 20 '16 at 22:26
  • @BobanP. What do you think I should add to the answer? I'm already explaining that /bin/sh doesn't have the expected interactive features. – Gilles Mar 20 '16 at 22:35
  • /bin/sh is dash. Dash manual pages says that if dash is started as login shell it reads /etc/profile and ~/.profile. ~/.profile should source ~/.bashrc but that should be checked. – Boban P. Mar 20 '16 at 22:47

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.