This would work... if the target system has a properly configured locale, which is not the case many times. E.g., [1] is still unresolved. [1] https://github.com/CentOS/sig-cloud-instance-images/issues/154

There is a movement towards C.UTF-8 for small images (containers and VMs). C.UTF-8 has both size and performance improvements over the more traditional en_US.UTF-8 locale. (The performance improvement is currently in upstream glibc only, but we plan to bring it to rawhide and Fedora 35 shortly.) However, in a world where glibc-langpack-en (or glibc-all-langpacks) is not installed on target systems, logging in over SSH does not result in a viable locale if the client use en_US.UTF-8 (or any other locale except C or C.UTF-8). This causes a severe degradation in user experience. It's not only that UTF-8 output does not work, there are also frequent warning messages from various tools. Some may even refuse to run completely. I tried to bring up this topic on the OpenSSH list to get some cross-distribution consensus, but the discussion didn't actually go anywhere: Phasing out forwarding of locale settings <https://lists.mindrot.org/pipermail/openssh-unix-dev/2021-September/03958... I think Fedora should do this unilaterally, dropping the downstream additions that enable locale forwarding in both the default client and server configurations. If we do that, the OpenSSH server will use the locale as configured with localectl for new interactive and non-interactive sessions, which is C.UTF-8 in many cases. At least that's what my testing on Fedora 33 suggests. Comments?