New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot connect (MacOSX client, Debian server) #98

Closed
ErikDeBruijn opened this Issue Apr 9, 2012 · 69 comments

Comments

Projects
None yet
@ErikDeBruijn

ErikDeBruijn commented Apr 9, 2012

Hi,

I just wanted to say that this is a long awaited feature... a client that is robust to roaming around, as many of us do.

I compiled the recent version from git for the server (a Debian Squeeze/sid machine) and am using the MacPorts version of mosh.

When running It I get the following error:

mosh root@server4

mosh requires a UTF-8 locale.
Connection to server4 closed.
/opt/local/bin/mosh: Did not find mosh server startup message.

I fiddled around with my client's /etc/ssh_config but this didn't help. What can I do to resolve this and start using mosh?

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 9, 2012

Member

Hello. Please run "locale" and then "ssh root@server4 locale". Do both show a UTF-8 LC_CTYPE?

If the latter doesn't, you have some options. Make sure that SendEnv LANG LC_* is on your local /etc/ssh_config (this is the default configuration on OS X) and AcceptEnv LANG LC_* is in the server's /etc/ssh/sshd_config (this has been the default on Debian for the last few releases, but not forever).

If you can't arrange that, you can try running:

mosh root@server4 --server="LANG=$LANG mosh-server"

That will explicitly pass the LANG environment variable.

Member

keithw commented Apr 9, 2012

Hello. Please run "locale" and then "ssh root@server4 locale". Do both show a UTF-8 LC_CTYPE?

If the latter doesn't, you have some options. Make sure that SendEnv LANG LC_* is on your local /etc/ssh_config (this is the default configuration on OS X) and AcceptEnv LANG LC_* is in the server's /etc/ssh/sshd_config (this has been the default on Debian for the last few releases, but not forever).

If you can't arrange that, you can try running:

mosh root@server4 --server="LANG=$LANG mosh-server"

That will explicitly pass the LANG environment variable.

@keithw keithw closed this Apr 9, 2012

@ErikDeBruijn

This comment has been minimized.

Show comment
Hide comment
@ErikDeBruijn

ErikDeBruijn Apr 9, 2012

Thanks for your response. I still can't get it to work, though. Tried setting LANG to various values, to no avail.

I had the SendEnv and AcceptEnv in place on client and server (respectively), reloaded the sshd config. But I still get the same response.
Just a thought: If it's not going to work without UTF-8, why allow the user to configure this and allow for more room for error? It would be nice if figuring out what locales are would not be required to use this, just like you don't need to understand it before you can use ordinary SSH.

Running locale on the client gives me:

locale

LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

ErikDeBruijn commented Apr 9, 2012

Thanks for your response. I still can't get it to work, though. Tried setting LANG to various values, to no avail.

I had the SendEnv and AcceptEnv in place on client and server (respectively), reloaded the sshd config. But I still get the same response.
Just a thought: If it's not going to work without UTF-8, why allow the user to configure this and allow for more room for error? It would be nice if figuring out what locales are would not be required to use this, just like you don't need to understand it before you can use ordinary SSH.

Running locale on the client gives me:

locale

LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 9, 2012

Member

Unfortunately, it's not exactly an install-time concern -- the choice of locale is the user's, in setting their environment variables. I agree it's not a concern with SSH, but SSH also doesn't correctly handle UTF-8 (you will get garbage in your buffers if you try to use delete in cooked mode), so that's not really much consolation for us!

On your Mac, can you set LANG=en_US.UTF-8 (or whatever your choice of language is, .UTF-8) and then run "locale"? If that doesn't work, we may need to figure out how to build the right locales for you...

Member

keithw commented Apr 9, 2012

Unfortunately, it's not exactly an install-time concern -- the choice of locale is the user's, in setting their environment variables. I agree it's not a concern with SSH, but SSH also doesn't correctly handle UTF-8 (you will get garbage in your buffers if you try to use delete in cooked mode), so that's not really much consolation for us!

On your Mac, can you set LANG=en_US.UTF-8 (or whatever your choice of language is, .UTF-8) and then run "locale"? If that doesn't work, we may need to figure out how to build the right locales for you...

@udp

This comment has been minimized.

Show comment
Hide comment
@udp

udp Apr 9, 2012

Same problem here (Arch Linux client, FreeBSD server).

[james@james-desktop mosh]$ locale
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=

[james@james-desktop mosh]$ ssh root@95.211.73.134 locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=

[james@james-desktop mosh]$ mosh root@95.211.73.134
bash: mosh-server: command not found
Connection to 95.211.73.134 closed.
/usr/local/bin/mosh: Did not find mosh server startup message.

udp commented Apr 9, 2012

Same problem here (Arch Linux client, FreeBSD server).

[james@james-desktop mosh]$ locale
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=

[james@james-desktop mosh]$ ssh root@95.211.73.134 locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=

[james@james-desktop mosh]$ mosh root@95.211.73.134
bash: mosh-server: command not found
Connection to 95.211.73.134 closed.
/usr/local/bin/mosh: Did not find mosh server startup message.
@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 9, 2012

Member

Hi udp,

You'll need to be using a UTF-8 locale to use Mosh. Can you set LANG=en_US.UTF-8 on your local machine? (You may have to build that locale with localegen...)

Member

keithw commented Apr 9, 2012

Hi udp,

You'll need to be using a UTF-8 locale to use Mosh. Can you set LANG=en_US.UTF-8 on your local machine? (You may have to build that locale with localegen...)

@BinaryPaean

This comment has been minimized.

Show comment
Hide comment
@BinaryPaean

BinaryPaean Apr 10, 2012

I'm also getting the same error, but with UTF-8 locales (apparently) set.
mosh installed locally via mac ports, installed remotely via apt-get ppa.

result of local locale command:

locale
LANG="en_US.utf-8"
LC_COLLATE="en_US.utf-8"
LC_CTYPE="en_US.utf-8"
LC_MESSAGES="en_US.utf-8"
LC_MONETARY="en_US.utf-8"
LC_NUMERIC="en_US.utf-8"
LC_TIME="en_US.utf-8"
LC_ALL=

remote machine locale:

locale
LANG=en_US.UTF-8
LANGUAGE=
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=

adding the --server="LANG=$LANG mosh-server" flag worked. Is there an expectation that the locale string be quoted?

BinaryPaean commented Apr 10, 2012

I'm also getting the same error, but with UTF-8 locales (apparently) set.
mosh installed locally via mac ports, installed remotely via apt-get ppa.

result of local locale command:

locale
LANG="en_US.utf-8"
LC_COLLATE="en_US.utf-8"
LC_CTYPE="en_US.utf-8"
LC_MESSAGES="en_US.utf-8"
LC_MONETARY="en_US.utf-8"
LC_NUMERIC="en_US.utf-8"
LC_TIME="en_US.utf-8"
LC_ALL=

remote machine locale:

locale
LANG=en_US.UTF-8
LANGUAGE=
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=

adding the --server="LANG=$LANG mosh-server" flag worked. Is there an expectation that the locale string be quoted?

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 10, 2012

Member

Quotes shouldn't matter, but we do have trouble right now with lowercase "utf-8". (Bug #104). Glad you got it working.

Member

keithw commented Apr 10, 2012

Quotes shouldn't matter, but we do have trouble right now with lowercase "utf-8". (Bug #104). Glad you got it working.

@ErikDeBruijn

This comment has been minimized.

Show comment
Hide comment
@ErikDeBruijn

ErikDeBruijn Apr 10, 2012

I've also added export LANG=en_US.UTF-8 to ~/.bashrc on the server, to no avail.

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"

I also ran locale-gen.

Still, I get the following:

 # mosh root@server4
mosh requires a UTF-8 locale.
Connection to server4 closed.
/opt/local/bin/mosh: Did not find mosh server startup message.

Is the UTF-8 really the reason why it's not working? Or could there be something else. I found no flag to make mosh verbose... If an error message points me in the right direction, usually I don't need to ask any developers. I'm sorry to take up so much of your time.

ErikDeBruijn commented Apr 10, 2012

I've also added export LANG=en_US.UTF-8 to ~/.bashrc on the server, to no avail.

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"

I also ran locale-gen.

Still, I get the following:

 # mosh root@server4
mosh requires a UTF-8 locale.
Connection to server4 closed.
/opt/local/bin/mosh: Did not find mosh server startup message.

Is the UTF-8 really the reason why it's not working? Or could there be something else. I found no flag to make mosh verbose... If an error message points me in the right direction, usually I don't need to ask any developers. I'm sorry to take up so much of your time.

@srmadden

This comment has been minimized.

Show comment
Hide comment
@srmadden

srmadden Apr 10, 2012

I managed to get this to work after seeing issues liked those above. There were a couple of things that confused me. First, on my Mac running Lion (10.7), /etc/ssh_config definitely doesn't have the SendEnv flags set (although the Linux machine I was trying to mosh too did have them set.) Second, when Keith says SendEnv LC_* above, you have to explicitly type out all of the LC_.... variables that need to be sent and received.

To be precise, in /etc/ssh_config on the client (a Mac), I added:

SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE

And on the server, in /etc/ssh/sshd_config, I made sure I had:

Accept locale-related environment variables

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE

srmadden commented Apr 10, 2012

I managed to get this to work after seeing issues liked those above. There were a couple of things that confused me. First, on my Mac running Lion (10.7), /etc/ssh_config definitely doesn't have the SendEnv flags set (although the Linux machine I was trying to mosh too did have them set.) Second, when Keith says SendEnv LC_* above, you have to explicitly type out all of the LC_.... variables that need to be sent and received.

To be precise, in /etc/ssh_config on the client (a Mac), I added:

SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE

And on the server, in /etc/ssh/sshd_config, I made sure I had:

Accept locale-related environment variables

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE

@ErikDeBruijn

This comment has been minimized.

Show comment
Hide comment
@ErikDeBruijn

ErikDeBruijn Apr 10, 2012

Thanks, srmadden, for adding your solution. I also added these to the configuration(s) of client and server. It's still not working. I'm wondering whether there could be other reasons why it's not working. Is there a verbose mode? Is there something else I can test? Can it display the server message that it's getting and can I manually diagnose that?

ErikDeBruijn commented Apr 10, 2012

Thanks, srmadden, for adding your solution. I also added these to the configuration(s) of client and server. It's still not working. I'm wondering whether there could be other reasons why it's not working. Is there a verbose mode? Is there something else I can test? Can it display the server message that it's getting and can I manually diagnose that?

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 10, 2012

Member

Thanks Sam. Unfortunately I don't have a great handle on when this became the default -- there may be a difference between new installs and upgrades. I have also seen somebody on OS X 10.6 who did not have the /etc/ssh_config line but was still passing the env vars.

On Debian/Ubuntu (and some [recent?] OS X installations...) the line really is just "SendEnv LANG LC_*" with a literal star, but if you have to type it all out somewhere, hmm. I just don't know. Thanks for tracking this down and glad you got it working eventually. We obviously do not totally understand the landscape here.

Member

keithw commented Apr 10, 2012

Thanks Sam. Unfortunately I don't have a great handle on when this became the default -- there may be a difference between new installs and upgrades. I have also seen somebody on OS X 10.6 who did not have the /etc/ssh_config line but was still passing the env vars.

On Debian/Ubuntu (and some [recent?] OS X installations...) the line really is just "SendEnv LANG LC_*" with a literal star, but if you have to type it all out somewhere, hmm. I just don't know. Thanks for tracking this down and glad you got it working eventually. We obviously do not totally understand the landscape here.

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 10, 2012

Member

Erik: Just to make sure.

(1) When you run plain "locale" at the local command line, do you see "LC_CTYPE="en_US.UTF-8"" but also no error messages complaining about "Cannot set LC_CTYPE..."?

(2) When you run "ssh remotehost locale", ditto? No error messages?

(3) When you run the mosh-client and mosh-server separately as detailed on mosh.mit.edu, does it work properly or not work?

(4) If you do get an error, you may have to run "locale-gen en_US.UTF-8" with the argument, not just by itself.

Thanks for your patience,
Keith

Member

keithw commented Apr 10, 2012

Erik: Just to make sure.

(1) When you run plain "locale" at the local command line, do you see "LC_CTYPE="en_US.UTF-8"" but also no error messages complaining about "Cannot set LC_CTYPE..."?

(2) When you run "ssh remotehost locale", ditto? No error messages?

(3) When you run the mosh-client and mosh-server separately as detailed on mosh.mit.edu, does it work properly or not work?

(4) If you do get an error, you may have to run "locale-gen en_US.UTF-8" with the argument, not just by itself.

Thanks for your patience,
Keith

@ErikDeBruijn

This comment has been minimized.

Show comment
Hide comment
@ErikDeBruijn

ErikDeBruijn Apr 10, 2012

Strange... it still reads the following:

# ssh root@server4 locale
\LANG=
LANGUAGE=
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=

Even though I've set /etc/profile and ~/.bashrc and ~/.bash_profile to export LANG=en_US.UTF-8....

ErikDeBruijn commented Apr 10, 2012

Strange... it still reads the following:

# ssh root@server4 locale
\LANG=
LANGUAGE=
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=

Even though I've set /etc/profile and ~/.bashrc and ~/.bash_profile to export LANG=en_US.UTF-8....

@jaredrichardson

This comment has been minimized.

Show comment
Hide comment
@jaredrichardson

jaredrichardson Apr 10, 2012

I also can't connect. I'm coming from Lion (on 2 different installs) to a Linux Mint box. locale returns the correct settings and both client and server, and I tried srmadden's solution. I'd love to use mosh, but I can't even connect w/the explicit mosh-client and mosh-server settings.

I wish there was some level of logging or debug messaging we could see.

jaredrichardson commented Apr 10, 2012

I also can't connect. I'm coming from Lion (on 2 different installs) to a Linux Mint box. locale returns the correct settings and both client and server, and I tried srmadden's solution. I'd love to use mosh, but I can't even connect w/the explicit mosh-client and mosh-server settings.

I wish there was some level of logging or debug messaging we could see.

@jinnko

This comment has been minimized.

Show comment
Hide comment
@jinnko

jinnko Apr 10, 2012

srmadden's solution worked for me from OSX 10.7 to debian squeeze with only the change applied on the client.

I confirmed that the wildcard SendEnv and AcceptEnv configs are in place on the client and server respectively and I kept receiving the "mosh requires a UTF-8 locale" message.

Running a shell on each the client and server confirmed the locales were UTF-8, however running the "ssh remotehost locale" command resulted in a POSIX locale for the duration of the session.

After entering the full SendEnv lines in ~/.ssh/config the connection (almost) works. Seems like a UDP problem at this point with the blue/white connecting message at the top.

Edit: I've put all the steps to get this running on Debian together in one place: http://jinntech.blogspot.co.uk/2012/04/mosh-great-new-ssh-replacement.html

jinnko commented Apr 10, 2012

srmadden's solution worked for me from OSX 10.7 to debian squeeze with only the change applied on the client.

I confirmed that the wildcard SendEnv and AcceptEnv configs are in place on the client and server respectively and I kept receiving the "mosh requires a UTF-8 locale" message.

Running a shell on each the client and server confirmed the locales were UTF-8, however running the "ssh remotehost locale" command resulted in a POSIX locale for the duration of the session.

After entering the full SendEnv lines in ~/.ssh/config the connection (almost) works. Seems like a UDP problem at this point with the blue/white connecting message at the top.

Edit: I've put all the steps to get this running on Debian together in one place: http://jinntech.blogspot.co.uk/2012/04/mosh-great-new-ssh-replacement.html

@jaredrichardson

This comment has been minimized.

Show comment
Hide comment
@jaredrichardson

jaredrichardson Apr 11, 2012

I feel dumb... the linux box had it's firewall enabled... turned it off and it connected immediately.

jaredrichardson commented Apr 11, 2012

I feel dumb... the linux box had it's firewall enabled... turned it off and it connected immediately.

@cbbrowne

This comment has been minimized.

Show comment
Hide comment
@cbbrowne

cbbrowne Apr 11, 2012

I'm running into this problem; it appears that I have a suitable LANG value, I at least imagine that "LANG=en_CA.UTF-8" ought to possibly work. (Note, server on Debian/testing. Laptop on Ubuntu 11.10.)

Would it be possible to augment the error message to be something like:

mosh requires a UTF-8 locale. [C] found instead.
mosh requires a UTF-8 locale. [] found instead.

Having some debugging output to help diagnose things would be mighty useful. Perhaps we need a "--verbose" option?

cbbrowne-ThinkPad-X60s% mosh --server="LANG=en_CA.UTF-8 mosh-server" 10.10.68.46
cbbrowne@10.10.68.46's password:
mosh requires a UTF-8 locale.
Connection to 10.10.68.46 closed.
/usr/bin/mosh: Did not find mosh server startup message.

For good measure, here's all the plausibly relevant locale outputs:

cbbrowne-ThinkPad-X60s% locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
cbbrowne-ThinkPad-X60s% ssh root@10.10.68.46 locale
root@10.10.68.46's password:
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
cbbrowne-ThinkPad-X60s% ssh cbbrowne@10.10.68.46 locale
cbbrowne@10.10.68.46's password:
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

Oh, and I have read jinnko's material above; I'm sure my sshd configuration accepts LC_* value overrides.

cbbrowne commented Apr 11, 2012

I'm running into this problem; it appears that I have a suitable LANG value, I at least imagine that "LANG=en_CA.UTF-8" ought to possibly work. (Note, server on Debian/testing. Laptop on Ubuntu 11.10.)

Would it be possible to augment the error message to be something like:

mosh requires a UTF-8 locale. [C] found instead.
mosh requires a UTF-8 locale. [] found instead.

Having some debugging output to help diagnose things would be mighty useful. Perhaps we need a "--verbose" option?

cbbrowne-ThinkPad-X60s% mosh --server="LANG=en_CA.UTF-8 mosh-server" 10.10.68.46
cbbrowne@10.10.68.46's password:
mosh requires a UTF-8 locale.
Connection to 10.10.68.46 closed.
/usr/bin/mosh: Did not find mosh server startup message.

For good measure, here's all the plausibly relevant locale outputs:

cbbrowne-ThinkPad-X60s% locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
cbbrowne-ThinkPad-X60s% ssh root@10.10.68.46 locale
root@10.10.68.46's password:
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
cbbrowne-ThinkPad-X60s% ssh cbbrowne@10.10.68.46 locale
cbbrowne@10.10.68.46's password:
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

Oh, and I have read jinnko's material above; I'm sure my sshd configuration accepts LC_* value overrides.

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 12, 2012

Member

Hi,

The problem in all these cases seems to be that you have an LC_ALL=C that is overriding everything. (The one that's important to mosh and dictates the character set is the LC_CTYPE, and that's "C" here, not en_US.UTF-8.) LC_ALL has the highest precedence and LANG the lowest.

Can you either set LC_ALL to en_CA.UTF-8 or just unset it?

As a general note, we have heard the community loud and clear on making this more verbose and helpful! We have worked out a pretty good scheme to pass the environment variables through mosh itself, making it much more likely to work even on SSH configurations that don't. Thank you for your patience.

Member

keithw commented Apr 12, 2012

Hi,

The problem in all these cases seems to be that you have an LC_ALL=C that is overriding everything. (The one that's important to mosh and dictates the character set is the LC_CTYPE, and that's "C" here, not en_US.UTF-8.) LC_ALL has the highest precedence and LANG the lowest.

Can you either set LC_ALL to en_CA.UTF-8 or just unset it?

As a general note, we have heard the community loud and clear on making this more verbose and helpful! We have worked out a pretty good scheme to pass the environment variables through mosh itself, making it much more likely to work even on SSH configurations that don't. Thank you for your patience.

@cbbrowne

This comment has been minimized.

Show comment
Hide comment
@cbbrowne

cbbrowne Apr 12, 2012

In a slightly different (no Ubuntu, just Debian involved) environment, it "did the trick" to run:
% LC_ALL=C.UTF-8 mosh --server="LANG=C.UTF-8 mosh-server" wolfe

I expect that similar should work out in my other environment of interest.

I hope that some better answers fall out of this; I'm not sure what The Right Solution is, except that it shouldn't involve shoving a bunch of opaque AI-ish code into place to "do magical right things," that's probably not good :-(. If you wind up having to implement something akin to autoconf as part of the login process, I expect you've hit on the wrong answer! :-)

cbbrowne commented Apr 12, 2012

In a slightly different (no Ubuntu, just Debian involved) environment, it "did the trick" to run:
% LC_ALL=C.UTF-8 mosh --server="LANG=C.UTF-8 mosh-server" wolfe

I expect that similar should work out in my other environment of interest.

I hope that some better answers fall out of this; I'm not sure what The Right Solution is, except that it shouldn't involve shoving a bunch of opaque AI-ish code into place to "do magical right things," that's probably not good :-(. If you wind up having to implement something akin to autoconf as part of the login process, I expect you've hit on the wrong answer! :-)

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 16, 2012

Member

The current git master has code to do the locale-passing in a nice way (as a backup to the system environment and SSH env-passing), so mosh 1.2 will make this considerably smoother.

Member

keithw commented Apr 16, 2012

The current git master has code to do the locale-passing in a nice way (as a backup to the system environment and SSH env-passing), so mosh 1.2 will make this considerably smoother.

@tony3

This comment has been minimized.

Show comment
Hide comment
@tony3

tony3 Apr 17, 2012

The solution for connecting to a FreeBSD server (and I assume OSX) is:

On the server:

vi /etc/ssh/sshd
# Add this to the end
# Allow new locale for mosh
AcceptEnv LANG
# save
/etc/rc.d/sshd restart

On the client:

vi ~/.ssh/config
# Add a host entry if you don't have one
Host <anyNameYouLikeWithoutSpaces>
HostName <remoteHostName>
SendEnv LANG
# save

# You should see some sort of UTF-8 with
ssh <anyNameYouLikeWithoutSpaces> locale
# If not, it's still broken, set your local locale correctly first

It shouldn't matter, but I'm using a recent Ubuntu client.

tony3 commented Apr 17, 2012

The solution for connecting to a FreeBSD server (and I assume OSX) is:

On the server:

vi /etc/ssh/sshd
# Add this to the end
# Allow new locale for mosh
AcceptEnv LANG
# save
/etc/rc.d/sshd restart

On the client:

vi ~/.ssh/config
# Add a host entry if you don't have one
Host <anyNameYouLikeWithoutSpaces>
HostName <remoteHostName>
SendEnv LANG
# save

# You should see some sort of UTF-8 with
ssh <anyNameYouLikeWithoutSpaces> locale
# If not, it's still broken, set your local locale correctly first

It shouldn't matter, but I'm using a recent Ubuntu client.

@lumaxis

This comment has been minimized.

Show comment
Hide comment
@lumaxis

lumaxis Apr 18, 2012

A short
dpkg-reconfigure locale
fixed it for me.

lumaxis commented Apr 18, 2012

A short
dpkg-reconfigure locale
fixed it for me.

@cliff1976

This comment has been minimized.

Show comment
Hide comment
@cliff1976

cliff1976 Jun 9, 2012

I struggled a bit, but in the end, the only way I could get it to work was to duplicate ALL the environment variables between client and server (after setting my sshd_config on the server to accept them from clients; my client's ssh_config was already sending them along).

All of the variables on both sides (server and client) were all en_US.UTF-8, but not all the variables were in use on the client side (I had a few blanks, like LC_ALL and LANG and LANGUAGE). Once I set all the environment variables to be the same between server and client, things started working beautifully.

One weird thing I noticed: the environment variable discrepancies didn't seem to be a problem when starting mosh-server and mosh-client separately.

This is the mosh package 1.2.1 in the PPA on the server side and a built-from-source client 1.2.1.

cliff1976 commented Jun 9, 2012

I struggled a bit, but in the end, the only way I could get it to work was to duplicate ALL the environment variables between client and server (after setting my sshd_config on the server to accept them from clients; my client's ssh_config was already sending them along).

All of the variables on both sides (server and client) were all en_US.UTF-8, but not all the variables were in use on the client side (I had a few blanks, like LC_ALL and LANG and LANGUAGE). Once I set all the environment variables to be the same between server and client, things started working beautifully.

One weird thing I noticed: the environment variable discrepancies didn't seem to be a problem when starting mosh-server and mosh-client separately.

This is the mosh package 1.2.1 in the PPA on the server side and a built-from-source client 1.2.1.

@mkowalczuk

This comment has been minimized.

Show comment
Hide comment
@mkowalczuk

mkowalczuk Jul 16, 2012

It started to work for me after setting:
LANG="en_US.UTF-8"
in /etc/default/locale on m Ubuntu server.

mosh 1.1.3 on both client (MacOS X) and server (Ubuntu)

mkowalczuk commented Jul 16, 2012

It started to work for me after setting:
LANG="en_US.UTF-8"
in /etc/default/locale on m Ubuntu server.

mosh 1.1.3 on both client (MacOS X) and server (Ubuntu)

@guerrerocarlos

This comment has been minimized.

Show comment
Hide comment
@guerrerocarlos

guerrerocarlos Jul 26, 2012

I had same problems, running Ubuntu Server and MacOSX Lion Client (brew 0.9) , the fastest solution was to set the server to the same locales of my machine.

Since I have it in spanish, running 'locale' in my machine says:
LANG="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_CTYPE="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_ALL="es_ES.UTF-8"

So I configured the same locale in the server running the following:
export LANGUAGE=es_ES.UTF-8
export LANG=es_ES.UTF-8
export LC_ALL=es_ES.UTF-8
locale-gen es_ES.UTF-8
dpkg-reconfigure locales

And it finally connected :)

guerrerocarlos commented Jul 26, 2012

I had same problems, running Ubuntu Server and MacOSX Lion Client (brew 0.9) , the fastest solution was to set the server to the same locales of my machine.

Since I have it in spanish, running 'locale' in my machine says:
LANG="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_CTYPE="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_ALL="es_ES.UTF-8"

So I configured the same locale in the server running the following:
export LANGUAGE=es_ES.UTF-8
export LANG=es_ES.UTF-8
export LC_ALL=es_ES.UTF-8
locale-gen es_ES.UTF-8
dpkg-reconfigure locales

And it finally connected :)

@giacecco

This comment has been minimized.

Show comment
Hide comment
@giacecco

giacecco Feb 3, 2013

This post worked for me instead #102 (comment).

My client is an Ubuntu 12.04 and my server a MacOS Mountain Lion. Mosh connections failed because .profile, where the PATH variable was changed to find mosh-server., was not being read. I solved the problem by creating on the server a link to .profile called .bashrc.

G.

giacecco commented Feb 3, 2013

This post worked for me instead #102 (comment).

My client is an Ubuntu 12.04 and my server a MacOS Mountain Lion. Mosh connections failed because .profile, where the PATH variable was changed to find mosh-server., was not being read. I solved the problem by creating on the server a link to .profile called .bashrc.

G.

@odinho

This comment has been minimized.

Show comment
Hide comment
@odinho

odinho Feb 18, 2013

Anyone who has this problem now (in 10.8), you might want to actually disable this fix. Go into /etc/ssh/ssh_configand comment out the SendEnv line:

# SendEnv LC_*

My problem was actually that OS X a UTF-8 locale, but only some that the Linux machines did'nt have (OSX doesn't have a nn_NO locale), so to get away that error, commenting out the sending of OSX-locales to Linux worked well.

You of course have to have your server locale set to a local UTF-8 locale there.

odinho commented Feb 18, 2013

Anyone who has this problem now (in 10.8), you might want to actually disable this fix. Go into /etc/ssh/ssh_configand comment out the SendEnv line:

# SendEnv LC_*

My problem was actually that OS X a UTF-8 locale, but only some that the Linux machines did'nt have (OSX doesn't have a nn_NO locale), so to get away that error, commenting out the sending of OSX-locales to Linux worked well.

You of course have to have your server locale set to a local UTF-8 locale there.

@jakub-m

This comment has been minimized.

Show comment
Hide comment
@jakub-m

jakub-m Jul 15, 2013

For me with version 1.2.2 worked

sudo aptitude install locales locales-all

jakub-m commented Jul 15, 2013

For me with version 1.2.2 worked

sudo aptitude install locales locales-all
@unclelim

This comment has been minimized.

Show comment
Hide comment
@unclelim

unclelim Sep 9, 2013

Jakud-m's solution works. I tried on Debian 7 wheezy and linuxmint 15.

unclelim commented Sep 9, 2013

Jakud-m's solution works. I tried on Debian 7 wheezy and linuxmint 15.

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 11, 2015

Member

Also please try running:

ssh -p xxxx root@SERVER perl -e 1

and let us know the output (if any).

Member

keithw commented Apr 11, 2015

Also please try running:

ssh -p xxxx root@SERVER perl -e 1

and let us know the output (if any).

@ovizii

This comment has been minimized.

Show comment
Hide comment
@ovizii

ovizii Apr 11, 2015

yes, only those 2 lines:

shiny:~ ovi$ mosh --ssh="ssh -p xxxx" --server="LANG=$LANG mosh-server" root@162.xxx.xxx.xxx
Connection to 162.xxx.xxx.xxx closed.
/usr/bin/mosh: Did not find mosh server startup message.
shiny:~ ovi$

The next suggestion resulted in weird results:
shiny:~ ovi$ ssh -t -p xxx root@162.xxx.xxx.xxx -l LANG=en_GB.UTF-8
LANG=en_GB.UTF-8@162.xxx.xxx.xxx's password:
Permission denied, please try again.
LANG=en_GB.UTF-8@162.xxx.xxx.xxx's password:
Permission denied, please try again.
LANG=en_GB.UTF-8@162.xxx.xxx.xxx's password:
Permission denied (publickey,password).
shiny:~ ovi$

Why is it not using root as user name?

shiny:~ ovi$ ssh -p xxx root@162.xxx.xxx.xxx perl -e 1
shiny:~ ovi$

no output.

ovizii commented Apr 11, 2015

yes, only those 2 lines:

shiny:~ ovi$ mosh --ssh="ssh -p xxxx" --server="LANG=$LANG mosh-server" root@162.xxx.xxx.xxx
Connection to 162.xxx.xxx.xxx closed.
/usr/bin/mosh: Did not find mosh server startup message.
shiny:~ ovi$

The next suggestion resulted in weird results:
shiny:~ ovi$ ssh -t -p xxx root@162.xxx.xxx.xxx -l LANG=en_GB.UTF-8
LANG=en_GB.UTF-8@162.xxx.xxx.xxx's password:
Permission denied, please try again.
LANG=en_GB.UTF-8@162.xxx.xxx.xxx's password:
Permission denied, please try again.
LANG=en_GB.UTF-8@162.xxx.xxx.xxx's password:
Permission denied (publickey,password).
shiny:~ ovi$

Why is it not using root as user name?

shiny:~ ovi$ ssh -p xxx root@162.xxx.xxx.xxx perl -e 1
shiny:~ ovi$

no output.

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 11, 2015

Member

Please double-check the command you're running. It looks like you omitted the "mosh-server".

Member

keithw commented Apr 11, 2015

Please double-check the command you're running. It looks like you omitted the "mosh-server".

@ovizii

This comment has been minimized.

Show comment
Hide comment
@ovizii

ovizii Apr 11, 2015

sorry, my bad, I was typing not copy/pasting and missed it.

shiny:~ ovi$ ssh -t -p xxxx root@162.xxx.xxx.xxx mosh-server -l LANG=en_GB.UTF-8

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
mosh-server: Bad IP address (-l)
Usage: mosh-server new [-s] [-v] [-i LOCALADDR] [-p PORT] [-c COLORS] [-l NAME=VALUE] [-- COMMAND...]
Connection to 162.xxx.xxx.xxx closed.
shiny:~ ovi$

ovizii commented Apr 11, 2015

sorry, my bad, I was typing not copy/pasting and missed it.

shiny:~ ovi$ ssh -t -p xxxx root@162.xxx.xxx.xxx mosh-server -l LANG=en_GB.UTF-8

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
mosh-server: Bad IP address (-l)
Usage: mosh-server new [-s] [-v] [-i LOCALADDR] [-p PORT] [-c COLORS] [-l NAME=VALUE] [-- COMMAND...]
Connection to 162.xxx.xxx.xxx closed.
shiny:~ ovi$

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 11, 2015

Member

Sorry, now it is my fault! Please make it "mosh-server new -l LANG=en_GB.UTF-8" and try again. (Just insert the "new" into what you have now.)

Member

keithw commented Apr 11, 2015

Sorry, now it is my fault! Please make it "mosh-server new -l LANG=en_GB.UTF-8" and try again. (Just insert the "new" into what you have now.)

@ovizii

This comment has been minimized.

Show comment
Hide comment
@ovizii

ovizii Apr 11, 2015

hmmmm

shiny:~ ovi$ ssh -t -p xxx root@162.xxx.xxx.xxx mosh-server new -l LANG=en_GB.UTF-8

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

MOSH CONNECT 60001 VQ22h6LvhnEuRNmV0Fb+Zg
Connection to 162.xxx.xxx.xxx closed.
shiny:~ ovi$

ovizii commented Apr 11, 2015

hmmmm

shiny:~ ovi$ ssh -t -p xxx root@162.xxx.xxx.xxx mosh-server new -l LANG=en_GB.UTF-8

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

MOSH CONNECT 60001 VQ22h6LvhnEuRNmV0Fb+Zg
Connection to 162.xxx.xxx.xxx closed.
shiny:~ ovi$

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 11, 2015

Member

Ok, the problem is that your client wants to speak American, and the server with the problem only speaks British. (The other server apparently has an American locale available.) This is a basic weakness in the way POSIX does locales (not particular to Mosh, but Mosh is aggressive with detecting it).

Please try setting your LANG to en_GB.UTF-8 on the client before running mosh or ssh.

LANG=en_GB.UTF-8 mosh --ssh='ssh -p xxxx' user@host

You should not need a --server argument.

Member

keithw commented Apr 11, 2015

Ok, the problem is that your client wants to speak American, and the server with the problem only speaks British. (The other server apparently has an American locale available.) This is a basic weakness in the way POSIX does locales (not particular to Mosh, but Mosh is aggressive with detecting it).

Please try setting your LANG to en_GB.UTF-8 on the client before running mosh or ssh.

LANG=en_GB.UTF-8 mosh --ssh='ssh -p xxxx' user@host

You should not need a --server argument.

@ovizii

This comment has been minimized.

Show comment
Hide comment
@ovizii

ovizii Apr 12, 2015

Both servers have the American locale available, I double checked and reconfigured locales on the problematic machine, still no-go.

Your command yields this:

shiny:~ ovi$ LANG=en_GB.UTF-8 mosh --ssh='ssh -p xxxx' root@162.xxx.xxx.xxx
Connection to 162.xxx.xxx.xxx closed.
/usr/bin/mosh: Did not find mosh server startup message.
shiny:~ ovi$

P.S. THanks for all the help, mosh is awesome, I just wish I could get it to work with all my usual servers.

ovizii commented Apr 12, 2015

Both servers have the American locale available, I double checked and reconfigured locales on the problematic machine, still no-go.

Your command yields this:

shiny:~ ovi$ LANG=en_GB.UTF-8 mosh --ssh='ssh -p xxxx' root@162.xxx.xxx.xxx
Connection to 162.xxx.xxx.xxx closed.
/usr/bin/mosh: Did not find mosh server startup message.
shiny:~ ovi$

P.S. THanks for all the help, mosh is awesome, I just wish I could get it to work with all my usual servers.

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 12, 2015

Member

Aha, looking closer, why do you have LC_CTYPE="UTF-8" on the client machine? Are you setting this manually? Generally LC_CTYPE needs to be the name of a locale, e.g. en_US.UTF-8.

Can you please try unsetting LC_CTYPE and rerunning the mosh commands?

Member

keithw commented Apr 12, 2015

Aha, looking closer, why do you have LC_CTYPE="UTF-8" on the client machine? Are you setting this manually? Generally LC_CTYPE needs to be the name of a locale, e.g. en_US.UTF-8.

Can you please try unsetting LC_CTYPE and rerunning the mosh commands?

@ovizii

This comment has been minimized.

Show comment
Hide comment
@ovizii

ovizii Apr 12, 2015

No idea where that came from and I couldn'T figure out how to unset it even after googling so I edited my .bash_profile and inserted
export LC_CTYPE="en_US.UTF-8"

And now everything works perfect, with both servers!!!

Thank you so much!

ovizii commented Apr 12, 2015

No idea where that came from and I couldn'T figure out how to unset it even after googling so I edited my .bash_profile and inserted
export LC_CTYPE="en_US.UTF-8"

And now everything works perfect, with both servers!!!

Thank you so much!

@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Apr 12, 2015

Member

You're welcome, and I'm glad we fixed it, but I don't understand is why you weren't seeing mosh's (very verbose) error message that would have identified this as the problem straight out.

Member

keithw commented Apr 12, 2015

You're welcome, and I'm glad we fixed it, but I don't understand is why you weren't seeing mosh's (very verbose) error message that would have identified this as the problem straight out.

@ovizii

This comment has been minimized.

Show comment
Hide comment
@ovizii

ovizii Apr 12, 2015

No idea, I copy/pasted all errors straight in here :-(

ovizii commented Apr 12, 2015

No idea, I copy/pasted all errors straight in here :-(

@proteusvacuum

This comment has been minimized.

Show comment
Hide comment
@proteusvacuum

proteusvacuum Aug 29, 2015

For me, this error was happening because my remote locale wasn't being properly generated when calling locale-gen on arch, even though it was listed properly when calling locale
To fix it, I had to uncomment the locale I was trying to use (en_CA.UTF8) in /etc/locale.gen, then running locale-gen again.

proteusvacuum commented Aug 29, 2015

For me, this error was happening because my remote locale wasn't being properly generated when calling locale-gen on arch, even though it was listed properly when calling locale
To fix it, I had to uncomment the locale I was trying to use (en_CA.UTF8) in /etc/locale.gen, then running locale-gen again.

@prodeveloper

This comment has been minimized.

Show comment
Hide comment
@prodeveloper

prodeveloper May 12, 2016

For me, what worked was adding the lines
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

to my .zshrc file

prodeveloper commented May 12, 2016

For me, what worked was adding the lines
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

to my .zshrc file

@larryhu

This comment has been minimized.

Show comment
Hide comment
@larryhu

larryhu Jun 1, 2016

@prodeveloper THX! Your code worked for me

larryhu commented Jun 1, 2016

@prodeveloper THX! Your code worked for me

@ts95

This comment has been minimized.

Show comment
Hide comment
@ts95

ts95 Sep 15, 2016

Thanks @prodeveloper That did it for me

ts95 commented Sep 15, 2016

Thanks @prodeveloper That did it for me

@amedee

This comment has been minimized.

Show comment
Hide comment
@amedee

amedee Dec 27, 2016

@cbbrowne' s #98 (comment) was the only thing that worked for me, and I agree that it's ugly as hack. All the other things, exporting languages, localegens etc didn't work.

amedee commented Dec 27, 2016

@cbbrowne' s #98 (comment) was the only thing that worked for me, and I agree that it's ugly as hack. All the other things, exporting languages, localegens etc didn't work.

@Huang-Libo

This comment has been minimized.

Show comment
Hide comment
@Huang-Libo

Huang-Libo Apr 28, 2017

This works for me, and I use it in iTerm2's profile
sh -c "export LANG=\"en_US.UTF-8\"; /usr/local/bin/mosh user@example.com"

Huang-Libo commented Apr 28, 2017

This works for me, and I use it in iTerm2's profile
sh -c "export LANG=\"en_US.UTF-8\"; /usr/local/bin/mosh user@example.com"

@junaid-ali

This comment has been minimized.

Show comment
Hide comment
@junaid-ali

junaid-ali Aug 3, 2017

This worked for me:
set LC_ALL="en_US.UTF-8"

junaid-ali commented Aug 3, 2017

This worked for me:
set LC_ALL="en_US.UTF-8"

@WeirdCircumstances

This comment has been minimized.

Show comment
Hide comment
@WeirdCircumstances

WeirdCircumstances Oct 5, 2017

Got a fix to this on MacOS 10.13:
I tried serval things posted here, connecting MacOS 10.13 to a Debian server. The connection was working for years. Lastly I changed my desktop language to english and installed the last version of mosh via brew. Now I'm also getting those errors and nothing posted here helped me yet.

mosh mc3
The locale requested by LC_CTYPE=UTF-8 isn't available here.
Running `locale-gen UTF-8' may be necessary.

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 (LC_CTYPE=UTF-8) specifies
the character set "US-ASCII".

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=
LANGUAGE=
LC_CTYPE=UTF-8
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/local/bin/mosh: Did not find mosh server startup message. (Have you installed mosh on your server?)

But it is working by using
mosh mc3 --server="LANG=en_US.UTF-8 mosh-server"

My server (Debian) says:

LANG=en_US.UTF-8
LANGUAGE=
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=en_US.UTF-8```

And the local machine:

locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

**Got a fix: Set "export LC_ALL=en_US.UTF-8" in bash_profile and reload bash ". ~/.bash_profile"
Now it looks like this and works!**

`locale
LANG=
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"`


WeirdCircumstances commented Oct 5, 2017

Got a fix to this on MacOS 10.13:
I tried serval things posted here, connecting MacOS 10.13 to a Debian server. The connection was working for years. Lastly I changed my desktop language to english and installed the last version of mosh via brew. Now I'm also getting those errors and nothing posted here helped me yet.

mosh mc3
The locale requested by LC_CTYPE=UTF-8 isn't available here.
Running `locale-gen UTF-8' may be necessary.

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 (LC_CTYPE=UTF-8) specifies
the character set "US-ASCII".

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=
LANGUAGE=
LC_CTYPE=UTF-8
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/local/bin/mosh: Did not find mosh server startup message. (Have you installed mosh on your server?)

But it is working by using
mosh mc3 --server="LANG=en_US.UTF-8 mosh-server"

My server (Debian) says:

LANG=en_US.UTF-8
LANGUAGE=
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=en_US.UTF-8```

And the local machine:

locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

**Got a fix: Set "export LC_ALL=en_US.UTF-8" in bash_profile and reload bash ". ~/.bash_profile"
Now it looks like this and works!**

`locale
LANG=
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"`


@keithw

This comment has been minimized.

Show comment
Hide comment
@keithw

keithw Oct 5, 2017

Member

Your client-side environment has LC_CTYPE of UTF-8, which is not a valid locale/language on your Debian server. You will have the same problem with SSH, except it will be more annoying because SSH will just let programs randomly fail instead of flagging the mismatch and bombing out.

Please try setting the local LC_CTYPE (or LANG) environment variables to something that the server understands (e.g. en_US.UTF-8), and that ought to fix the problem. You do not need to modify the command-line to mosh if your system is set up properly and in a way that's compatible with the server. You may need to navigate the system preferences on your macOS machine to do this.

Member

keithw commented Oct 5, 2017

Your client-side environment has LC_CTYPE of UTF-8, which is not a valid locale/language on your Debian server. You will have the same problem with SSH, except it will be more annoying because SSH will just let programs randomly fail instead of flagging the mismatch and bombing out.

Please try setting the local LC_CTYPE (or LANG) environment variables to something that the server understands (e.g. en_US.UTF-8), and that ought to fix the problem. You do not need to modify the command-line to mosh if your system is set up properly and in a way that's compatible with the server. You may need to navigate the system preferences on your macOS machine to do this.

@eminence eminence added the support label Oct 8, 2017

@hagabla

This comment has been minimized.

Show comment
Hide comment
@hagabla

hagabla Nov 28, 2017

2017, fresh macOS, vanilla Debian Jessie, with all locales generated on the server.
Does not work out of the box, neither with Terminal.app nor with iTerm.
Suggested workarounds in this thread do not work.

hagabla commented Nov 28, 2017

2017, fresh macOS, vanilla Debian Jessie, with all locales generated on the server.
Does not work out of the box, neither with Terminal.app nor with iTerm.
Suggested workarounds in this thread do not work.

@kevinwaddle

This comment has been minimized.

Show comment
Hide comment
@kevinwaddle

kevinwaddle Nov 29, 2017

I have a 2016 Macbook Pro 13" that I was using to mosh to an Ubuntu 14.04 server over VPN. Always worked fine.

I just 'downgraded' to a 2015 Macbook Pro 15" and after I having gotten it set back up, as close to the same as MBP13, I am getting this same/similar error message when i try to mosh to the same Ubuntu 14.04 server.

The 13" is running Sierra, the 15" came with High Sierra.

I can still mosh into the server from the MBP13 with no problems.

The locale requested by LC_CTYPE=UTF-8 isn't available here.
Running `locale-gen UTF-8' may be necessary.

mosh-server needs a UTF-8 native locale to run.

Unfortunately, the local environment (LC_CTYPE=UTF-8) specifies
the character set "US-ASCII",

The client-supplied environment (LC_CTYPE=UTF-8) specifies
the character set "US-ASCII".

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=
LANGUAGE=
LC_CTYPE=UTF-8
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 ubuntuserver closed.
/usr/local/bin/mosh: Did not find mosh server startup message. (Have you installed mosh on your server?)```

kevinwaddle commented Nov 29, 2017

I have a 2016 Macbook Pro 13" that I was using to mosh to an Ubuntu 14.04 server over VPN. Always worked fine.

I just 'downgraded' to a 2015 Macbook Pro 15" and after I having gotten it set back up, as close to the same as MBP13, I am getting this same/similar error message when i try to mosh to the same Ubuntu 14.04 server.

The 13" is running Sierra, the 15" came with High Sierra.

I can still mosh into the server from the MBP13 with no problems.

The locale requested by LC_CTYPE=UTF-8 isn't available here.
Running `locale-gen UTF-8' may be necessary.

mosh-server needs a UTF-8 native locale to run.

Unfortunately, the local environment (LC_CTYPE=UTF-8) specifies
the character set "US-ASCII",

The client-supplied environment (LC_CTYPE=UTF-8) specifies
the character set "US-ASCII".

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=
LANGUAGE=
LC_CTYPE=UTF-8
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 ubuntuserver closed.
/usr/local/bin/mosh: Did not find mosh server startup message. (Have you installed mosh on your server?)```
@andersk

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk Nov 29, 2017

Member

It seems that macOS sets LC_CTYPE=UTF-8 as a fallback when the combination of the system language/region settings aren’t recognized. (For example, English/United States is okay, German/Germany is okay, English/Germany is not.) This nonstandard setting of LC_CTYPE is recognized by macOS but not by Linux.

https://bugs.python.org/issue18378#msg215215
https://gitlab.com/gnachman/iterm2/issues/5478

Workarounds: either change the language/region settings to a recognized combination, or manually set LC_CTYPE to something like en_US.UTF-8. (Run locale -a for a list of accepted values.)

Member

andersk commented Nov 29, 2017

It seems that macOS sets LC_CTYPE=UTF-8 as a fallback when the combination of the system language/region settings aren’t recognized. (For example, English/United States is okay, German/Germany is okay, English/Germany is not.) This nonstandard setting of LC_CTYPE is recognized by macOS but not by Linux.

https://bugs.python.org/issue18378#msg215215
https://gitlab.com/gnachman/iterm2/issues/5478

Workarounds: either change the language/region settings to a recognized combination, or manually set LC_CTYPE to something like en_US.UTF-8. (Run locale -a for a list of accepted values.)

@kevinwaddle

This comment has been minimized.

Show comment
Hide comment
@kevinwaddle

kevinwaddle Nov 29, 2017

What I can't figure out is why my MBP13 has no problems connecting with mosh, but this new MBP15 does.

They are almost identical in the Language & Region settings. The only difference I can see in the Region & Language screens is that in Date & Time > [Advanced] > Times the Timezone on the working MBP13 shows GMT+1 and on the non-working MBP15 it shows CEST

And locale definitely shows the same for both when run from the Terminal.

--MBP15--

LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
--MBP13--

LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

The other difference between the two machines is that I bought the MBP13 in the US, but changed it to Region Denmark when I moved here.

This new MBP15 I bought here and I set the Region to Denmark during the initial setup.

If I switch the Region on the MBP15, that has the problem connection with mosh, to United State, then mosh works. It gets the LC_CTYPE="en_US.UTF-8" as you suggest manually setting it to. But the MBP13 does not have this, and it works.

--MBP15 (Region set to United States)--

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

kevinwaddle commented Nov 29, 2017

What I can't figure out is why my MBP13 has no problems connecting with mosh, but this new MBP15 does.

They are almost identical in the Language & Region settings. The only difference I can see in the Region & Language screens is that in Date & Time > [Advanced] > Times the Timezone on the working MBP13 shows GMT+1 and on the non-working MBP15 it shows CEST

And locale definitely shows the same for both when run from the Terminal.

--MBP15--

LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
--MBP13--

LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

The other difference between the two machines is that I bought the MBP13 in the US, but changed it to Region Denmark when I moved here.

This new MBP15 I bought here and I set the Region to Denmark during the initial setup.

If I switch the Region on the MBP15, that has the problem connection with mosh, to United State, then mosh works. It gets the LC_CTYPE="en_US.UTF-8" as you suggest manually setting it to. But the MBP13 does not have this, and it works.

--MBP15 (Region set to United States)--

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=
@rthouvenin

This comment has been minimized.

Show comment
Hide comment
@rthouvenin

rthouvenin Mar 12, 2018

I think I am facing a similar problem as @kevinwaddle: unusual mix of language and region.

I regularly connect to a handful of Ubuntu 16.04 servers, this was working fine with my previous system which was set with French language in region France.
I recently switched to a new system, and this time set the language to US English and the region still to France. Locale output:

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

Since then, mosh accepts to connect to only some of the servers. All servers have the same locale (en_US.UTF-8), and the same AcceptEnv LANG LC_* directive in sshd config. The only difference I can see is that those that work are servers that were directly installed with Ubuntu 16.04 while those that don't are Ubuntu 14.04 migrated to 16.04.

I worked around the problem by changing the ssd config to AcceptEnv LANG.

Note: Even if SSH does not handle character sets as well as MOSH, SSH handles this problem in a superior way I think: it does let me connect. I do get a warning that something's wrong with locales, but at least I can work.

rthouvenin commented Mar 12, 2018

I think I am facing a similar problem as @kevinwaddle: unusual mix of language and region.

I regularly connect to a handful of Ubuntu 16.04 servers, this was working fine with my previous system which was set with French language in region France.
I recently switched to a new system, and this time set the language to US English and the region still to France. Locale output:

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

Since then, mosh accepts to connect to only some of the servers. All servers have the same locale (en_US.UTF-8), and the same AcceptEnv LANG LC_* directive in sshd config. The only difference I can see is that those that work are servers that were directly installed with Ubuntu 16.04 while those that don't are Ubuntu 14.04 migrated to 16.04.

I worked around the problem by changing the ssd config to AcceptEnv LANG.

Note: Even if SSH does not handle character sets as well as MOSH, SSH handles this problem in a superior way I think: it does let me connect. I do get a warning that something's wrong with locales, but at least I can work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment