Repository navigation
How to get UTF-8 to work properly from a Linux SSH client #2468
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest version
- Search the existing issues.
Steps to reproduce
How do I get UTF-8 to work properly from a Linux SSH client?
$ ssh MyWindowsPC "echo ä"
\204
Octal 204 = decimal 132 = hexadecimal 84 is the code for 'ä' in Code Page 437.
UTF-8 works fine on my Linux box. Environment variable LANG is set to "en_US.UTF-8".
Expected behavior
$ ssh MyWindowsPC "echo ä"
äActual behavior
$ ssh MyWindowsPC "echo ä"
\204Error details
Environment data
Name Value
---- -----
PSVersion 5.1.20348.5386
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.20348.5386
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1Version
OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2
Visuals
No response
Activity
github-actions commentedon Oct 11, 2026
This looks like a Windows-specific UTF-8/codepage handling issue for remote commands executed through
sshd, so I’m marking it for maintainer investigation.For maintainers
äto CP437 (0x84) and the server side is OpenSSH_for_Windows running PowerShell 5.1 on Windows build 10.0.20348, so the likely fix area is Windows process/console/codepage handling in PowerShell/openssh-portable. Confidence: medium-high.ssh MyWindowsPC "echo ä"), expected/actual output, and OpenSSH_for_Windows version (9.5p2). It does not name the Linux client distribution/version or the exact remote shell/codepage settings, but the core repro is specific enough for initial investigation. Confidence: medium.Area-sshdandArea-Terminalbecause the symptom occurs when a Linux SSH client invokes a command on the Windowssshdserver and receives escaped/non-UTF-8 output from the remote command path.Related issues checked
sshclient, not Linux-client-to-Windows-server remote command output.Add this agentic workflows to your repo
To install this agentic workflow, run
jborean93 commentedon Oct 12, 2026
It really depends on what the target default shell is and the configured console codepage. For example my target
DefautlShellispowershell.exeso I need to explicitly change the codepage withchcp 65001or[Console]::OutputEncoding = [Text.UTF8Encoding]::new()to tell PowerShell it can emit characters using UTF-8 bytes.Windows does not set the console output codepage to UTF-8 by default for compatibility issues so you essentially need to tell it that UTF-8 is ok.
If your default shell is cmd (the default if not configured) then doing
chcp 65001 && echo äshould work but I've not tested that.rdiez commentedon Oct 12, 2026
I think the default shell on my Windows Server target is cmd. I tested it like this:
This does not work:
However, this does work:
But that trick does not always work:
The
\201on the last line should actually be 'ü'.So it looks like the
chcp 65001is not been set or propagated properly in all cases.jborean93 commentedon Oct 12, 2026
I do see that when cmd is the default shell the chcp command didn't apply to the current process and I had to spawn a new one so it saw the new console codepage changes.
As for why
quserstill returns the\201escape sequence I am not sure sorry. It could be thatquserdoesn't respect the console code page and always returns it in some other encoding. You could rule this out by opening cmd interactively on the Windows host and run the samechcp 65001then thequser ...and redirect stdout/stderr to a file. From there you can inspect the raw bytes or useFormat-Hex -Path ...in PowerShell to see whether theüis UTF-8 encoded (quser respects the codepage) or something else (quser does not).Ultimately this is a tricky thing, SSH just returns back the raw bytes it receives on the stdout/stderr so it is up to the applications that write to stdout/stderr to emit using the expected encoding. If there is a misalignment then you get issues like this where your client cannot render what the remote had emitted.