The SSH client in MacOS X 10.7 (Lion) has broken(?) UTF8 support

I upgraded to 10.7 today, only to find that my IRC client (Irssi running in a screen on a remote server) suddenly had decided that it hated any and all non-ASCII characters, replacing them with ?’s instead. In the local terminal everything worked just fine. I use UTF-8 as the terminal charset on both the server and in the OS X terminal, and everything had worked just fine prior to the upgrade, both on the Mac, on my Windows box (using PuTTY) and on various other Unix machines.

I eventually traced the problem to the OS X built-in ssh client (/usr/bin/ssh), which for some reason badly mishandles UTF-8 in Lion. There are two three possible workarounds:

  1. install a different SSH client (OpenSSH installed via MacPorts is a good alternative), or
  2. do everything on the remote server in a screen launched with the -U flag. The defencoding and defutf8 flags in your screenrc will not help.
  3. new solution, reported to work but not tested by me: edit /etc/ssh_config and remove the LC_* part from the line that says SendEnv LANG LC_*.

A very late update, March 2012: the third solution is probably the best. Either remove the LC_* part, or comment out the entire line. The comments on this article have some more relevant information about why this is the correct solution; comments #21 and #22 are particularly helpful. Thank you, internet!

Comments (26)

  1. franz wrote:

    It works for me. Mostly the same test case, ssh to remote server, irssi, and utf-8 displays fine. Maybe you need a new screen session?

    The remote server is running 10.5 Leopard, if that matters.

    Thursday, July 21, 2011 at 15:42 #
  2. TheFluff wrote:

    Can you enter UTF-8 characters outside the screen though? Literally all of my OS X-using friends have the same issue, so it’s not just me.

    Thursday, July 21, 2011 at 15:45 #
  3. franz wrote:

    I can, both on my OS X server and on my Ubuntu one. Here’s a screenshot:


    Thursday, July 21, 2011 at 15:55 #
  4. TheFluff wrote:

    Is that zsh? Because that worked for me too for some reason. bash does not, and nor does zsh inside a screen launched without -U.

    Thursday, July 21, 2011 at 16:01 #
  5. franz wrote:

    bash on both machines.

    Thursday, July 21, 2011 at 16:06 #
  6. TheFluff wrote:

    That’s really odd. For me, trying to input any non-ASCII character in bash just makes it ring a bell. Before Lion this used to work just fine. I’ve never had to launch screen with -U before either.

    Thursday, July 21, 2011 at 16:13 #
  7. TheFluff wrote:

    Further investigation reveals that for some reason LC_CTYPE was set to UTF-8 instead of en_US.UTF-8 (and in some cases on friends’ machines, not set at all). Changing that setting makes things magically work.

    Thursday, July 21, 2011 at 16:27 #
  8. TheFluff wrote:

    Further further investigation: the above works on Ubuntu, but on an older Debian machine literally everything in a screen is ZOMG ULTRA LASER BORKED no matter what I try.

    Thursday, July 21, 2011 at 19:14 #
  9. Snakeye wrote:

    The same issue for me. The temporary cure is to execute ‘export LC_ALL=en_US.UTF-8′ before ssh

    Thursday, July 21, 2011 at 19:25 #
  10. Trellmor wrote:

    Could it be that the SSH client sends the LANG and LC_* to the server? I had a similar problem on Linux (server and client, OpenSSH). Removing SendEnv LANG LC_* from the ssh_config file fixed it.

    The server has a similar setting: AcceptEnv LANG LC_*

    Thursday, July 21, 2011 at 19:51 #
  11. vp wrote:

    It didn’t broke my terminal / ssh / screen / irssi combination. Maybe it gets broken only on a certain hardware (hint: I have MBP, what do you have?). My friend has the same problem and he is running on Air.

    Friday, July 22, 2011 at 07:53 #
  12. TheFluff wrote:

    MBP here too. I think it’s dependent on the target system though, not on the hardware on the Mac.

    Friday, July 22, 2011 at 12:19 #
  13. ondratoral wrote:

    Hi guys, the same problem here – MacMini connecting to Ubuntu server 10.04. The first connection after Mac restart is ok, the rest broken. From win machine (putty portable) works ok, though.

    Saturday, July 23, 2011 at 08:50 #
  14. loeschg wrote:

    ssh and Lion problems here, too (MBP).

    PTY allocation request failed on channel 0

    Works fine on all other machines/SSH clients. GARBAGE.

    Wednesday, July 27, 2011 at 03:44 #
  15. Sarah wrote:

    Looks like the problem is related to and not SSH – it works fine in iTerm.

    Monday, August 1, 2011 at 08:09 #
  16. Sarah wrote:

    Also, disabling the forwarding of LC variables in /etc/ssh_config on the Lion client seems to fix this issue.

    Monday, August 1, 2011 at 08:13 #
  17. bbb wrote:

    hi, I think my problem is related to yours.
    On a OSx 10.6 laptop using ssh to another machine gives me a colored screen. Doing ssh on my OSx 10.7 laptop to the same machine gives me black and white screen and also a lot of key combinations behave differently.
    I tried the suggestions you mentioned but it does not solve this situation.
    I compared /etc/ssh_config, locale and locale -a on both machines and they are the same. Do you have any suggestions?

    Sunday, August 7, 2011 at 12:11 #
  18. pjm wrote:

    I have the same issue, but with SSH/iOS/weechat.

    Tuesday, August 9, 2011 at 22:44 #
  19. starak wrote:

    The third solution worked for me. From Mac OS X 10.7 ssh to Ubuntu Server 10.10.


    Tuesday, August 30, 2011 at 00:09 #
  20. MLaZz wrote:

    Same here… and the 3rd solution works! Thanks for sharing!

    Thursday, September 8, 2011 at 14:23 #
  21. tjac wrote:

    Actually the real problem that’s causing this is that Mac OS 10.7 sets totally non-standard locale values, at least when you tweak some of the formats in SysPrefs/Language&Text as I did.

    If you type “locale” on your Mac terminal you should see pretty much the same as on other Unices (e.g. lots of en_US.UTF-8s if you prefer US English), but you don’t. If these garbled settings get transferred to other Unix hosts by the SendEnv option they naturally do not know what’s going on.

    So if you want to fix it cleanly to allow for sshing to all kinds of remote hosts, including those with older character sets, put the following
    lines in your ~/.bash_profile on your Mac client machine.

    export LC_ALL=en_US.UTF-8
    export LANG=en_US.UTF-8

    Monday, September 12, 2011 at 22:54 #
  22. styx wrote:

    Remote machine uses UTF8 locale, Terminal profile encoding is ISO Latin 1. When I start mc in the remote shell, shows crappy half tablescreen (with expected weird characters) but Terminal generates a huge load on my MBP. Have to force quitting.
    Changing to UTF8 in Terminal before starting mc solves this but it was working fine on SL :\
    Very annoying cause I have to work on several remote machines with vary locales, and I have to keep in mind this not to kill my Terminal process.

    Thursday, October 6, 2011 at 09:35 #
  23. Try iTerm2 wrote:

    I’ve seen a similar problem when SSHing into my cloud servers and editing text files with nano or vim. At first I thought it was AWS but for the problem is OSX terminal. I’ve replaced it with iTerm2, which is just plain better anyways.

    Tuesday, November 8, 2011 at 15:18 #
  24. If you are using ssh v 5.6 or newer, you can also use:
    ssh -T usr@url
    The “-T” fixes it….

    Tuesday, May 22, 2012 at 04:40 #
  25. Hi! Thank you, the third workaround solved the problem. I have Mac OS X Lion and IRC shell (screen + irssi) running on Ubuntu 12.04.


    Monday, September 17, 2012 at 18:13 #
  26. Lisko wrote:

    Thank you, the /etc/wtf solution worked perfectly!

    Tuesday, October 23, 2012 at 19:03 #

Trackback/Pingback (1)

  1. Terminal in OS X Lion: can't write åäö on remote machine on Tuesday, February 7, 2012 at 13:01

    […] related thread on this topic: Answered by Jonatan […]