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?

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

15 Answers 15


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.

  • 17
    This is not sufficient in all cases. You should also export the following variable to your environment: NCURSES_NO_UTF8_ACS=1 [more info] Dec 14, 2014 at 22:53
  • 3
    in case locale returns POSIX you probably have usePAM disabled in the sshd config Jul 20, 2015 at 19:59
  • 6
    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, 2015 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, 2017 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, 2017 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, 2015 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, 2016 at 8:24
  • Excellent. Solved the problem for ncmpc on Ubuntu Artful.
    – weberjn
    Jan 8, 2018 at 23:19
  • Worked for me too. PuTTY on Win 10.
    – mikekehrli
    Feb 11 at 18:47

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.

  • For me, UTF-8 was already set but it didn't work, instead setting it to this did. Mar 5, 2021 at 14:51
  • 1
    When I set Use font encoding then for example armbian-config characters are OK but they are wrong in Midnight Commander and vice versa - when I set UTF-8 then characters in armbian-config are wrong but in Midnight Commader are OK.
    – Chupo_cro
    Jun 28, 2021 at 22:45
  • 1
    UTF-8 was set for me as well, but it didn't work when I was using "pm2 monit" which updates the screen continuously. Setting "use font encoding" instead fixed that process so I was happy for a few mins. But later on, I used the "pm2 status" command which draws a box on-screen only once... and it was now displaying the garbage characters instead of lines. It's like you can't have both working at the same time. No problem with a plain-old-linux shell terminal though.
    – BrentHarsh
    Apr 11, 2022 at 19:09

Window → Translation → "Enable VT100 line drawing even in UTF-8 mode".

This fixes the display of both mc and wavemon for me.

enter image description here

  • 1
    Yeah, this fixes aptitude, iptraf-ng without breaking mc. (with Terminal type string set to either xterm or xterm-256color). See also superuser.com/questions/278286/…
    – tehnicaorg
    Dec 27, 2020 at 20:44
  • 1
    THIS is the real answer. If you have it set as UTF8, vt100 line draw does NOT WORK. Sep 9, 2021 at 1:55
  • This worked for me when using pm2 and tmux (other answers would have it work for one but not the other).
    – Eric Mutta
    Dec 26, 2022 at 17:28
  • Only answer that works under Windows with pm2 monit
    – philk
    Mar 6, 2023 at 16:54

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


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

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

worked for me.


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.

  • 3
    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 Sep 12, 2018 at 20:07
  • NCURSES_NO_UTF8_ACS=1 is not needed anymore. See superuser.com/questions/278286/… on how to enable VT100 drawing characters in PuTTY 0.71+.
    – tehnicaorg
    Dec 27, 2020 at 20:47

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.

  • 1
    This fixed it for me.
    – Martin
    Dec 16, 2018 at 7:21

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.

  • 1
    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, 2017 at 22:15

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.


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


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.


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. Mar 10, 2017 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

Not the answer you're looking for? Browse other questions tagged .