Connecting from a Windows 7 PC via SSH to an Ubuntu server using PuTTY, I get some screen errors:

enter image description here

I.e. it:

  • "Double-draws" the selection inside Midnight Commander (MC).
  • Other characters like line elements are drawn as the wrong characters (e.g. "â" instead of "|").

I connected to the same Ubuntu server with a terminal and SHH from a Mac OS X and do not get these screen garbling (i.e. everything looks and works correctly). I've already tried to play with the font settings inside PuTTY, changing it from Courier New to Consolas but without luck.

My question therefore is:

How to configure PuTTY to correctly display special characters and not double-draw/overwrite screen lines?

  • 1
    With SecureCRT: Select Options -> Session Options -> Terminal -> Appearence -> Character encoding -> select: UTF-8. Hope help others like me! – Vunb Sep 3 at 9:16

14 Answers 14


You almost certainly have set the wrong character set in your PuTTY settings.

Verify the character set on the remote system by running the command:


This should return something like:


So check your PuTTY settings under Translation and ensure that you have UTF-8 set as the character set.

PuTTY Reconfiguration

You may need to tweak the line drawing setting as well, but it is probably not likely.

  • 14
    This is not sufficient in all cases. You should also export the following variable to your environment: NCURSES_NO_UTF8_ACS=1 [more info] – Piotr Jurkiewicz Dec 14 '14 at 22:53
  • 2
    in case locale returns POSIX you probably have usePAM disabled in the sshd config – user2693017 Jul 20 '15 at 19:59
  • 4
    If the locale returns something like POSIX, issue update-locale LANG=en_US.utf8 at the command line - see thomas-krenn.com/de/wiki/Locales_unter_Ubuntu_konfigurieren – koppor Dec 19 '15 at 11:05
  • @michael-hampton, my system is configured to use en_US.UTF-8. I see that different places say different things about locale. Some places mention I should use en_US while other places mention I should use de_DE. I saw before the grep and other core utils use the locale to set the character set, I believe. What are the implicaitons of changing this? – alpha_989 Nov 11 '17 at 21:00
  • @koppor, you mentioned about changing locale to en_US, while michael mentioned changing locale to de_DE. Which one is correct? – alpha_989 Nov 11 '17 at 21:02

I had an issue with Debian's aptitude program even though I had UTF-8 as my characters set. What worked for me was to set the 'Connection > Data > 'Terminal-type string' to 'putty' instead of 'xterm' - apparently Putty ignores the character sequence to switch into drawing mode: http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/utf8-plus-vt100.html

enter image description here

  • 2
    Excellent. Easy and it works. (At least it does on Debian/Ubuntu.) – Nate Apr 29 '15 at 22:46
  • 1
    This works well (on PuTTY) but then it introduces another (more minor) problem: remote-controlled window title changing no longer works. – ADTC Jun 19 '16 at 8:24
  • Excellent. Solved the problem for ncmpc on Ubuntu Artful. – weberjn Jan 8 '18 at 23:19

Also, if UTF-8 is not properly configured, you may run it as mc -ac.

Credits: http://blog.acsystem.sk/linux/midnight-commander-utf8-line-drawing-characters-problem


The two basic factors are Window/Translation UTF-8 in putty and locale settings in Linux, as instructed here and many other places.

In addition, it may help in putty to set Connection/Data/Terminal-type string to putty, and/or in Linux to export NCURSES_NO_UTF8_ACS=1. These two are also mentioned multiple places.

But: you may still get blocks for certain characters because the default fonts like Courier and Lucida Console don't have all Unicode chars. Download and install http://dejavu-fonts.org/wiki/Download, and set putty to use it.

This last trick was necessary for me to get noping (recommended!) to show all graphic characters.

  • 2
    export NCURSES_NO_UTF8_ACS=1 worked best for me. I just need to remember to use the -E option on sudo when I run iftop to keep that environment setting. sudo -E iftop – HeatfanJohn Sep 12 '18 at 20:07

In my case (Ubuntu 14.04) the issue was caused by missing

UsePAM yes    

entry in /etc/ssh/sshd_config as /etc/pam.d/sshd pam configuration is responsible by default for loading /etc/default/locale into users environment.

  • This fixed it for me. – Martin Dec 16 '18 at 7:21

For all you poor old VMS guys that end up here:

PuTTY → Window → Translation → Remote character set → DEC-MCS

worked for me.


I was looking for many solutions for this when using Docker machine (both locale and on machines set up by system administrator). In my Putty everything was fine (I had UTF-8), I was using also other SSH client and had exact same problem.


mc -ac

was solving the problem (but not completely) and I was looking for complete solution.

After reading many suggestions, I finally found the one that solved my issue.

In terminal when you run:


verify what locale you have set. I had by default C locale.

To verify all locale installed run locale -a

I have for example:


by default.

The solution is exporting LANG variable with C.UTF-8 locale like so:

export LANG="C.UTF-8"

You can obviously add it into .bashrc to have it automatically set in your profile.

  • What are the side-effects of changing LANG variable? If you already had C.UTF-8 as LANG, why export it again? – alpha_989 Nov 11 '17 at 22:15

Another reason somehow related to pam that may affect hosts with powerbroker/pbis/likewise authentication.

grep /etc/pam.d for the "lsass" occurance:

grep -r lsass /etc/pam.d

if you see in the output something like:

/etc/pam.d/common-session:session       sufficient        pam_lsass.so

then it's probably the root cause of the problem. The quick fix is to replace "sufficient" with "optional" next to pam_lsass module so it looks like:

/etc/pam.d/common-session:session       optional        pam_lsass.so

/etc/pam.d/common-session (or other file with similar entry - there might be few of them) is probably included by /etc/pam.d/sshd before pam_env is loaded so if the processing of pam modules is finished before it comes to pam_env, the /etc/default/locale is not loaded in the user environment and you have garbled characters.


After 15 years I got annoyed once more and googled around again, found this, chose

change settings → window → translation → remote char set → "use font encoding"

and that fixed it.


I had to set, on the WindowTranslation page, the character set to:

ISO-8859-1:1998 (Latin-1, West Europe)

Then, and only then, did the linedraw characters appear correctly.


Running mc this way (set locale to en) works for me:

$ LC_ALL=en mc

what worked for me was "Connection, Data, Terminal-type string = ansi" plus "Window, Translation, Remote character set = Use font encoding" then set TERM=ansi on the unix side.

PS. Remember to turn smart quotes OFF if you are forced to use MS-Word.

  • 1
    You should also mention that you're not connecting to a modern LInux system, but an older non-Linux system. – Michael Hampton Mar 10 '17 at 15:50

My problem was that putty is configured as UTF-8 but the remote system is a ISO-8859-1

west Europe, so I changed that on putty and anything worked fine.

Putty screenshot


As mentioned in many answers:

Putty > Window > Translation > Remote character set > UTF8

is the solution.

But then don't forget to go to Session > Default settings and hit Save. No message will be displayed to confirm success, but it will become the default indeed:

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.