How to get coloured terminal over ssh?

Question

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 =)

Is that an Ubuntu server you're connecting to? – Stefano Palazzo Dec 05 '10 at 20:42 — Stefano Palazzo, Dec 05 '10 at 20:42

score 45 · Answer 1 · edited Feb 24 '20 at 16:37

45

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.

edited Feb 24 '20 at 16:37

Tapper

2,780

answered Oct 20 '16 at 00:57

sites

739

This works perfectly, and is very convenient for one off tasks. Thanks! – XtraSimplicity Jan 04 '17 at 03:17
I lost the colorize when I did su - command in the ssh connection prompt – dubis Feb 20 '19 at 08:30
This is the missing link if adding --color alone doesn't help. – Murphy Jul 07 '22 at 13:17
I was indeed looking for a way to get ANSI colours back to my local terminal when executing a remote command through ssh. This is the solution! – AstroFloyd May 06 '24 at 11:20

score 44 · Accepted Answer · edited May 06 '19 at 06:49

44

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.

edited May 06 '19 at 06:49

rjurney

105

answered Dec 06 '10 at 00:41

Dima

9,965

58

It would help this answer a lot if you said where you put --color=auto. .bashrc on the server? What commands? – rfay Aug 24 '13 at 19:37
21

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 06 '15 at 17:58
3

it was Mike E 's comment that fixed it for me, – Frank Schrijver Sep 24 '16 at 21:10
8

I'm confused. What does it mean to "changing everything to simply --color"? Can I see an example? – DivergentSpaceTimeWanderer Aug 10 '17 at 21:11
2

Are you guys talking about the local host, the remote host or both? – Adam Jan 10 '18 at 09:47
2

@Adam the remote host. – Chai T. Rex Oct 16 '18 at 20:15
5

Can someone improve this answer and show an example ? – DollarAkshay Apr 17 '19 at 06:09
1

This answer was silly, it never said where to put --color. So I fixed it. – rjurney May 06 '19 at 06:06
@rjurney There are at least four .bashrc files in different locations "on the server" I looked at. – Peter Kionga-Kamau Nov 09 '22 at 08:40

score 34 · Answer 3 · edited Apr 11 '15 at 18:54

34

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

edited Apr 11 '15 at 18:54

Michael Lindman

1,742

answered Apr 11 '15 at 18:12

dariusz gorczynski

441
4
2

2

This worked for me, and was a simple and efficient way to get it done! – flith May 26 '17 at 08:24
Ubuntu 20.04 LTS this worked for me + Miek-e's answer. – BHP Nov 21 '21 at 05:36
Bongo! This worked for me. Ubuntu 20.04 and Windows Terminal. – Tejasvi Hegde Feb 10 '22 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 09 '22 at 06:57
This is a very bad idea to add inside your .bashrc file. Is there something wrong with your .bashrc you will get a infinite loop here. Instead, it's safe to place this logic in .profile – GLindqvist Oct 14 '24 at 14:03

score 25 · Answer 4 · answered Apr 14 '19 at 08:14

25

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)

answered Apr 14 '19 at 08:14

hinneLinks

447

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 – walnut_salami May 30 '21 at 10:10

score 8 · Answer 5 · answered Dec 05 '10 at 21:09

8

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

~ > export | grep -i term
TERM=xterm

answered Dec 05 '10 at 21:09

Vedran Krivokuća

89

$ export | grep -i term declare -x TERM="xterm" – Dima Dec 06 '10 at 00:36
I got: declare -x TERM="dumb" – Daniel Mar 18 '25 at 14:29

score 8 · Answer 6 · answered May 31 '17 at 07:35

8

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.

answered May 31 '17 at 07:35

Stuart Clark

81

Only one that worked for me in windows – Gaspa79 Jan 26 '25 at 11:15

score 4 · Answer 7 · edited Oct 17 '18 at 06:03

4

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.

edited Oct 17 '18 at 06:03

zx485

2,894

answered Oct 16 '18 at 18:53

Kevin

41

2

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

score 3 · Answer 8 · answered Mar 15 '18 at 21:02

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.

score 3 · Answer 9 · edited May 23 '17 at 12:39

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.

edited May 23 '17 at 12:39

Community

1

answered Mar 07 '16 at 21:57

chris544

151

1

Ubuntu uses .profile and not .bash_profile by default, and the default .profile does source .bashrc. – muru Mar 07 '16 at 22:18
That is correct. But does .profile get executed by default when logging in through ssh? – chris544 Mar 07 '16 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 07 '16 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 07 '16 at 22:51
See my first comment again. No, it doesn't. Ubuntu uses .profile. – muru Mar 07 '16 at 22:52
Ok, you are correct. I had quite a few remote AWS Ubuntu instances running and all of them seemed to have .bash_profile file (without me remembering putting them there). It turns out that other people did actually create them there. So in one instance it broke my terminal colors. So much for unexpected consequences. – chris544 Mar 07 '16 at 23:03
Sigh. Being AWS, I suppose graphical login isn't done. Or the other users might have noticed different behaviour, for example, if they'd changed the PATH in .bash_profile but not in .profile or vice versa. – muru Mar 07 '16 at 23:04
This is a good clarification. But I am not sure how useful this answer is in the end because I realized that I somehow did not notice that one of the earlier answers actually described the same solution (just with less detail). So this probably should have been just a clarification comment. – chris544 Mar 07 '16 at 23:20

score 1 · Answer 10 · answered Aug 28 '18 at 03:54

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'"

answered Aug 28 '18 at 03:54

ErichBSchulz

121

1

You should allocate a terminal on the first connection as well, if you're going to do that. – muru Aug 28 '18 at 04:02

score 1 · Answer 11 · answered Aug 20 '20 at 22:34

1

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

answered Aug 20 '20 at 22:34

Kristian Torres

11

score 0 · Answer 12 · edited Jan 01 '23 at 02:49

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=no/s/^/#/g' /home/*/.bashrc
 sudo sed -i '/force_color_prompt=no/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

score 0 · Answer 13 · answered Mar 16 '22 at 13:16

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.

score 0 · Answer 14 · answered Jul 30 '22 at 06:56

0

just run

sudo chsh -s /bin/bash <user>

answered Jul 30 '22 at 06:56

Piotr Rusin

1

score 0 · Answer 15 · answered Feb 04 '25 at 17:26

On native Debian systems like the Raspberry Pi there is a .profile file in the users home directory that takes care of this. Ubuntu doesn't appear to have a default .profile in the users home directory. I copied the .profile from a Raspberry Pi and put it in my home directory on the Ubuntu system and now when i login remotely via SSH I have color directory listings. Here are the contents of the ~/.profile file:

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

the default umask is set in /etc/profile; for setting the umask
for ssh logins, install and configure the libpam-umask package.
#umask 022
if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
PATH="$HOME/.local/bin:$PATH"
fi

score 0 · Answer 16 · answered Apr 09 '25 at 14:51

Terminal-based applications typically color output based on the value of the environment variable TERM and sometimes others like COLORTERM. These will need to be set on the host.

You can test this by running the command with colored output after setting the environment variables with export. You can determine the value to change term to by running echo $TERM on your local machine, or you can use xterm or xterm-256color.

After ssh'ing into the host:

export TERM=xterm
echo abcd | grep ab

Locally, the terminal sets the TERM environment variable. Ideally, you want to pass this along to the remote server so that the programs will use the right ANSI codes or escape sequences to colorize the output in a way that is compatible with the terminal you are currently using.

One way to accomplish this is to create the an entry in ~/.ssh/config for your target host and instruct ssh to pass the current value of TERM. If the file doesn't exist, you can create it.

Host example
    Hostname example.com
    SendEnv TERM

If you're using a terminal that isn't recognized by an older system you are ssh'ing into (such as Ghostty which sets xterm-ghostty) you may want to pick a value that the server recognizes and that all of your terminals more or less support. This can be done with SetEnv.

Host example
    Hostname example.com
    SetEnv TERM=xterm

Most coloring is done with a 16 or 256 color pallete. Newer terminals support 16 million colors. I have software that detects the terminals ability to support this number of colors by reading the COLORTERM environment variable and looking for the value truecolor. This variable is again set locally by the terminal, but needs to be passed to the server. Our Host entry can be modified accordingly.

Host example
    Hostname example.com
    SetEnv TERM=xterm
    SendEnv COLORTERM

If you try this and run echo $COLORTERM you may find that it has not been set on the remote machine. This is because sshd on the server is not configured to accept COLORTERM from ssh clients.

If you have permissions on the host to change the sshd settings, edit /etc/ssh/sshd_config and add COLORTERM to AcceptEnv. Then sshd must be restarted with systemctl restart sshd (or the appropriate command for your system) for the configuration to take effect.

How to get coloured terminal over ssh?

16 Answers16

the default umask is set in /etc/profile; for setting the umask

for ssh logins, install and configure the libpam-umask package.

if running bash

set PATH so it includes user's private bin if it exists

set PATH so it includes user's private bin if it exists