`ls --color=auto` works locally but not when connecting over SSH

TLDR

If you've ran into this with the aforementioned symptoms, you are probably using a relatively new and/or obscure terminal emulator (I was using Alacritty). Colours work by default because your terminal emulator sets the COLORTERM environment variable, which gets picked up by ls. However, this variable is not propagated across SSH by default, which causes the symptom of "coloured ls only works locally".

Full explanation

Both dircolors and ls (when LS_COLORS is unset) behave similarly when it comes to the handling of TERM and COLORTERM, so I will only address ls in this explanation.

This is the source code of ls as of time of writing (permalink):

  if ((p = getenv ("LS_COLORS")) == nullptr || *p == '\0')
    {
      /* LS_COLORS takes precedence, but if that's not set then
         honor the COLORTERM and TERM env variables so that
         we only go with the internal ANSI color codes if the
         former is non empty or the latter is set to a known value.  */
      char const *colorterm = getenv ("COLORTERM");
      if (! (colorterm && *colorterm) && ! known_term_type ())
        print_with_color = false;
      return;
    }

As you can see, ls will always colourise its output when COLORTERM is not empty. Only when it's empty or absent will it check whether TERM's value is among the known terminals that support colours. Therefore as long as your terminal emulator sets the COLORTERM variable (as is the case with Alacritty for example), ls will colourise by default even when your TERM is not known to ls.

The problem is, SSH by default only propagates one variable to the server - TERM. For older and/or common terminals this is okay, because they are known to ls, but this breaks colourisation for terminals like Alacritty.

Solution #1

Add your terminal to the list of known terminals. dircolors will then set LS_COLORS based on your configuration, which will get picked up by ls.

This may be easier or harder depending on which distro you are on:

• On Fedora family (RHEL, CentOS, etc.), there is existing infrastructure (/etc/profile.d/colorls.sh) that loads /etc/DIR_COLORS. So you can simply add TERM alacritty (or whatever your TERM is) to this file.
• On Debian family, the default ~/.bashrc (defined by /etc/skel/.bashrc) contains scripting to load ~/.dircolors if it exists. So you can run dircolors --print-database > ~/.dircolors then add the aforementioned line.
• On Arch family, there is no existing scripting. So you have to add your own, probably in ~/.bashrc (or whatever shell you prefer). Here's what Debian has for reference:

if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
fi

Solution #2

Make SSH propagate COLORTERM.

On the machine you are trying to access (server), run:

# as root
echo "AcceptEnv COLORTERM" > /etc/ssh/sshd_config.d/50-accept-COLORTERM.conf
systemctl restart sshd.service # ssh.service on Debian family

On your machine you are connecting from (client), run:

# as root
echo "SendEnv COLORTERM" > /etc/ssh/ssh_config.d/50-send-COLORTERM.conf

This might be preferable if you use multiple different terminal emulators. On the flipside, it does require configuring both the SSH server and client. So pick your poison I guess.