Ssh – Ubuntu-Server bash colors not appearing on login

In your login shell's profile files you can set up some things that you will use during your session, and which only need to be done once. Some ideas:

• create a temporary file containing the IP address you connected from, later on you can include it in some scripts setting firewall rules.
• run ssh-agent, ask for your SSH keys, and store the SSH agent environment variables in a file.
• if that is a limited machine, and your co-workers want to be aware of each others logins, write(1) messages informing them of your login.

In a non-login shell's files (.bashrc) you should configure your shell:

• Fancy prompt
• set aliases
• set history options
• define custom shell functions
• export environment variables, (maybe PAGER, EDITOR if system-wide settings suck)
• load ssh-agent variables saved in .bash_profile

Usually, you would include .bashrc from .bash_profile with the following. Then login shell gets all your customizations, and .bash_profile file does not have to duplicate things that are already in .bashrc.

[[ -f ~/.bashrc ]] && . ~/.bashrc

Check to make sure that the login shell you're in doesn't have an alias or a different PATH depending on whether you're logged in via ssh or telnet. Compare this each way:

type -a bash

There could be some conditional code in one of:

• /etc/profile
• /.bash_profile
• ~/.bash_login
• ~/.profile
• ~/.bashrc

That sets the PATH differently or creates an alias depending on whether you're logged in via ssh or telnet. The PATH could point to different versions of Bash that are compiled with different options. An alias could be something like alias bash='bash -i'.

If you echo $SHELL as Nikolaidis suggests, that's only going to show what's set in /etc/passwd as your login shell. It might be more reliable to use ps. If for some reason you're getting a shell other than Bash, you'll need to check its startup files and environment to see if the PATH or aliases are different. Generally, though, your interactive shell shouldn't affect how explicitly calling bash -c works.

And you're correct about this:

As near as I can tell this is the correct behaviour given that the shell is non-interactive in both cases (it is invoked with -c).