80

When I connect over ssh to remote hosts everything is just a single font/color. I would like to have colours like I do locally e.g. green for executable and blue for symlinks etc. And such that when I run $ git diff on the ssh host it shows me diff with colours =)

2
  • Is that an Ubuntu server you're connecting to? Dec 5, 2010 at 20:42
  • @stefano-palazzo: to Debian.
    – Dima
    Dec 6, 2010 at 0:46

13 Answers 13

40

Because it was xterm on the server, I figured something was wrong with .bashrc

And indeed! ls --color=auto works only when you are connected to TTY. Changing everything to simply --color in .bashrc on the remote host and everything is in pretty colours now.

8
  • 53
    It would help this answer a lot if you said where you put --color=auto. .bashrc on the server? What commands?
    – rfay
    Aug 24, 2013 at 19:37
  • 16
    Since this is an old question which is still relevant, I just wanted to add that on Ubuntu systems, the default .bashrc has a case statement which defines which terms are allowed color. If you find the "case "$TERM$" in" line in your .bashrc, adding "xterm) color_prompt=yes;;" will also enable color. Also you can uncomment the "force_color_prompt=yes" line to globally enable it always.
    – Mike E
    Jul 6, 2015 at 17:58
  • 3
    it was Mike E 's comment that fixed it for me, Sep 24, 2016 at 21:10
  • 5
    I'm confused. What does it mean to "changing everything to simply --color"? Can I see an example? Aug 10, 2017 at 21:11
  • 2
    @Adam the remote host. Oct 16, 2018 at 20:15
36

This worked for me:

ssh -t my_host my_command

-t was the key. Explained:

-t      Force pseudo-tty allocation.  This can be used to execute arbitrary screen-based programs on a
        remote machine, which can be very useful, e.g. when implementing menu services.  Multiple -t
        options force tty allocation, even if ssh has no local tty.
3
  • This works perfectly, and is very convenient for one off tasks. Thanks! Jan 4, 2017 at 3:17
  • I lost the colorize when I did su - command in the ssh connection prompt
    – dubis
    Feb 20, 2019 at 8:30
  • I wonder, why do you mention my_command here? I barely never use it.
    – mazunki
    Apr 30, 2020 at 1:47
27

Seems like colors were already set in ~/.bashrc for me and the issue is that ssh does not use the bashrc file. You can use bashrc in your ssh session by adding the following to ~/.bash_profile:

if [ -f ~/.bashrc ]; then
      . ~/.bashrc
fi
4
  • 1
    This worked for me, and was a simple and efficient way to get it done!
    – flith
    May 26, 2017 at 8:24
  • Ubuntu 20.04 LTS this worked for me + Miek-e's answer.
    – Behzad
    Nov 21, 2021 at 5:36
  • Bongo! This worked for me. Ubuntu 20.04 and Windows Terminal. Feb 10 at 14:21
  • Thanks! For me, it's just adding [[ -s "$HOME/.profile" ]] && source "$HOME/.profile" into ~/.bash_profile. My ~/.profile includes above recommended ~/.bashrc condition
    – Ravi Misra
    Mar 9 at 6:57
19

Since the colors worked fine while being loggged in directly, I just un-uncommented the line force_color_prompt=yes in the file ~/.bashrc, that gave me colors over ssh, too:

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
force_color_prompt=yes

(Ubuntu 18.04 LTS)

3
  • Upvoted, this seems to be the most straight-forward solution.
    – snwflk
    Apr 25, 2019 at 12:53
  • Yeap, best and most simple answer (at least for Ubuntu). +1
    – DimP
    Nov 25, 2020 at 11:08
  • This also works for Debian 10 (buster). If you're ssh-ing into your server and you don't have colors when TERM=xterm-kitty or others this is what you need to do to get colors. The lines the above answer mentions should be in your ~/.bashrc after initial Debian install May 30, 2021 at 10:10
8

What's the content of your XTERM env variable on the server when you connect to it?

~ > export | grep -i term
TERM=xterm
1
  • $ export | grep -i term declare -x TERM="xterm"
    – Dima
    Dec 6, 2010 at 0:36
5

In my case, the missing part was to have colored ls, grep, etc. which can be added by adding aliases to the .bashrc file:

alias ls='ls --color=auto'
alias grep='grep --color=auto'

etc.

3

I tried changing ~./bashrc settings (both on local and remote server), but it did not seem to work.

Then I noticed that ~/.bashrc of remote server does not even get executed if I connect to it over ssh. So I made ~/.bashrc of remote server to execute by puttinng if [ -f ~/.bashrc ]; then . ~/.bashrc fi in remote server's ~/.bash_profile. (based on https://stackoverflow.com/questions/820517/bashrc-at-ssh-login).

So this solution did not require changing any ~/bashrc files directly but it did require changing ~/bash_profile file of remote server so that ~/bashrc file of remote server got executed.

8
  • 1
    Ubuntu uses .profile and not .bash_profile by default, and the default .profile does source .bashrc.
    – muru
    Mar 7, 2016 at 22:18
  • That is correct. But does .profile get executed by default when logging in through ssh?
    – chris544
    Mar 7, 2016 at 22:43
  • 1
    Yes. Provided you didn't override it using .bash_profile, bash runs .profile when started as a login shell. And SSH starts bash as a login shell.
    – muru
    Mar 7, 2016 at 22:44
  • It is correct that ~/.profile is not read if ~/.bash_profile exists. But doesn't ~/.bash_profile exist on Ubuntu by default?
    – chris544
    Mar 7, 2016 at 22:51
  • See my first comment again. No, it doesn't. Ubuntu uses .profile.
    – muru
    Mar 7, 2016 at 22:52
3

In my situation, I recently installed chef-local and it asked me to add a line to .bash_profile. When I sign in, .bashrc never loads anymore, because it saw .bash_profile.

What I did was to add a line in .bash_profile:

source .bashrc
export PATH="/opt/chefdk/embedded/bin:$PATH"

I logged out and back in and got my colored terminal right away.

1
  • 1
    +1 for similar situation. Just adding source .bashrc to .bash_profile fixed it in Ubuntu server 18.04 LTS.
    – rdtsc
    Dec 10, 2019 at 15:00
2

There is a comment from "Mike E" above that contained the answer for me, but it is not only hard to read, it is kind of hard to figure out what he means if you don't use .bashrc a lot - and I don't.

After screwing around a bit, I got the desired results by changing the following lines in ~/.bashrc on the machine I was logging into with ssh:

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color|*-256color) color_prompt=yes;;
esac

to:

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color|*-256color) color_prompt=yes;;
    xterm) color_prompt=yes;;
esac

I am thinking I could have just added "|xterm" after "color" in the first line, or dug around and figure out why ssh was using "xterm" instead of "xterm-color" and change that, but this works and I have other things to do now.

1

I was losing my color when connecting via a proxy because TERM=dumb so I fixed it:

ssh myproxy "ssh pi@localhost -p 5000 -tt 'TERM=xterm bash'"
1
  • 1
    You should allocate a terminal on the first connection as well, if you're going to do that.
    – muru
    Aug 28, 2018 at 4:02
1

This worked for me: just open your .bashrc file in your $HOME folder, and uncomment the line force_color_prompt=yes

0
cd
cat << 'EOF' >color_terminals_over_ssh.sh
#!/bin/bash
#Must pass either enable or disable to script
#./color_terminals_over_ssh.sh enable

DO=$1

if [[ $DO = "enable" ]]
then
 sudo sed -i '/force_color_prompt=yes/s/^#//g' /home/*/.bashrc
 sudo sed -i '/force_color_prompt=yes/s/^#//g' /root/.bashrc
 sudo su
elif [[ $DO = "disable" ]]
then
 sudo sed -i '/force_color_prompt=yes/s/^/#/g' /home/*/.bashrc
 sudo sed -i '/force_color_prompt=yes/s/^/#/g' /root/.bashrc
 sudo su
fi

cat ~/.bashrc | grep force_color_prompt=yes

EOF
chmod +x color_terminals_over_ssh.sh
./color_terminals_over_ssh.sh enable
0

I had this issue after creating a new user on Linux (Ubuntu). Setting force_color_prompt=yes didn't do it for me.

I forgot to specify the shell, so it went for the default /bin/sh, redirecting to /bin/dash apparently on my distribution. When manually setting it to /bin/bash everything worked out of the box.

So in my case I could have used the -s flag when adding the user (so useradd -s /bin/bash ... to specify the shell. Instead I used chsh -s /bin/bash to set it after creation.

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.