18

I am trying to connect from my Gentoo to RHEL server. Both have mosh installed, however I get this error:

petanb@localhost ~/Documents $ mosh root@server 
mosh-server needs a UTF-8 native locale to run.

Unfortunately, the local environment ([no charset variables]) specifies
the character set "US-ASCII",

The client-supplied environment ([no charset variables]) specifies
the character set "US-ASCII".

LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
Connection to server closed.
/usr/bin/mosh: Did not find mosh server startup message.

On RHEL I have following locales:

# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

How can I fix this?

UPDATE: The problem seem to be on Gentoo side, connecting to debian server produces same error, connecting using other distros works.

UPDATE2: I fixed it by adding

LANG="en_US.UTF-8"
export LANG

into ~/.bashrc

Petr
  • 1,691
  • 4
  • 21
  • 31
  • For those using Ubuntu or any Debian like distro, [here](https://askubuntu.com/a/1116779/349837) may be a solution. – Pablo A Feb 09 '19 at 02:16

2 Answers2

5

mosh uses the locale environment supported by ssh. While mosh apparently has no verbose- or debug-options, you can tell it what ssh command to use when connecting and by adding a -vvv option can have ssh show what locale variables it sends.

For example, starting with

mosh -ssh='ssh -vvv' root@server

you might see

debug1: Sending env LC_ALL = C  
debug2: channel 0: request env confirm 0

for POSIX, and

debug1: Sending env LC_CTYPE = en_US.UTF-8
debug2: channel 0: request env confirm 0

which show that the server confirms variables which are used. The remote sshd may ignore some of your environment depending on the setting of AcceptEnv in the configuration for sshd — or your user's SendEnv settings (in your ssh configuration).

Not all servers accept your locale variables via ssh.

Even with the configuration setup permissively, it's still possible (particularly since you are connecting to the root user) that someone has decided that the locale for that user should be POSIX. For root, that makes some sense because you would get into less trouble by select/paste copying.

For example, some systems use /etc/profile.d/lang.sh to set the locale for interactive use. That script differs from one system to another, and is the second place (after the ssh/sshd configurations) to consider when looking for an explanation why locale information is not passed to a remote system. With Red Hat (CentOS) the script attempts to get information from system- and home-configuration, e.g.,

if [ -n "$LANG" ]; then
    saved_lang="$LANG"
    [ -f "$HOME/.i18n" ] && . "$HOME/.i18n" && sourced=1
    LANG="$saved_lang"
    unset saved_lang
else
    for langfile in /etc/locale.conf "$HOME/.i18n" ; do
        [ -f $langfile ] && . $langfile && sourced=1
    done
fi

SuSE is different, making assumptions about ssh and gdm before reading essentially the same files:

#
# lang.sh:      Set interactive language environment
#
# Used configuration files:
#
#     /etc/sysconfig/language
#     $HOME/.i18n
#

#
# Already done by the remote SSH side
#
test -z "$SSH_SENDS_LOCALE" || return

#
# Already done by the GDM
#
test -z "$GDM_LANG" || return

For your particular servers (version not specified), the script may differ from one release to another. My Debian servers do not have that file - and rely upon the default system locale and gdm (which can differ) to set the interactive locale. Your ssh connection could use a different value with the system locale than an interactive session using X (via gdm). In that case, the system locale is the place to fix (see Locale in the Debian wiki).

Thomas Dickey
  • 75,040
  • 9
  • 171
  • 268
0

I too ran into the error message. However, the work-around as provided by @Petr did not work for me. I had to set the value of the LC_ALL environment variable to en_US.UTF-8. Setting the LANG variable had no effect (as on my end it already had the correct value).

Also, I have a slight clarification:

You make this change in the client environment, i.e. where you run your mosh command. You do not make this change in the server environment, i.e. where you are connecting to.

This was not intuitively obvious to me, when I first found this post.

Also, to elaborate a bit further: as stated, in my situation LANG was already set to en_US.UTF-8. However, various other variables where set differently:

LANG=en_US.UTF-8
LC_ADDRESS=nl_NL.UTF-8
LC_IDENTIFICATION=nl_NL.UTF-8
LC_MEASUREMENT=nl_NL.UTF-8
LC_MONETARY=nl_NL.UTF-8
LC_NAME=nl_NL.UTF-8
LC_NUMERIC=nl_NL.UTF-8
LC_PAPER=nl_NL.UTF-8
LC_TELEPHONE=nl_NL.UTF-8
LC_TIME=nl_NL.UTF-8

Presumably this leads to some confusion in the mosh application, whereas ssh doesn't fuss about it.

On my end, I'm connecting from a Pop!_OS 22.04 client environment to an Unbuntu 22.04 server environment

Tip

Instead of changing the LC_ALL variable for the entire shell, you can also use the following alias:

alias mosh="export LC_ALL=\"en_US.UTF8\" && mosh"
DotMatrix
  • 1
  • 1
  • 1
  • 1