Hi Ingo, On 2022-04-25 14:23:06, Ingo Schwarze wrote:> Hi Harald, > > Harald Dunkel wrote on Mon, Apr 25, 2022 at 10:05:43AM +0200: > >> forwarding LANG and LC_* variables to the peer seems to be only >> reasonable, > > Absolutely not, what a terrible idea. >I couldn't agree more, but please see the xterm packages on Debian and RedHat, and my related question about how to *undo* the SendEnv LANG LC_* in Debian's /etc/ssh/ssh_config in my .ssh/config. Anyway, the problem here is that MacOS sets a locale "UTF-8" in LC_CTYPE instead of "en_US.UTF-8", which produces problems even though UTF-8 is available on all involved systems.> For an introduction to the topic, see > > https://undeadly.org/cgi?action=article&sid=20160308204011 > > The end of that article specifically discusses ssh(1). >I highly appreciate your link, but for a Linux package maintainer it is too easy to ignore the problem. Maybe you should consider to add some guidelines about how to handle locales into a README within the openssh source package, or in ssh_config(5), sshd_config(5), etc.? Thank you very much Harri
On 2022/04/27 12:14, Harald Dunkel wrote:> I couldn't agree more, but please see the xterm packages on Debian > and RedHat, and my related question about how to *undo* the > > SendEnv LANG LC_* > > in Debian's /etc/ssh/ssh_config in my .ssh/config.SendEnv is additive, it does not replace existing config when you list a new variable, instead it adds to the existing variables. So all you can do is add a variable, or remove a variable which was _already_ set earlier in parsing, not prevent one from being set in later parsing. According to the manual, the config files are parsed in this order: 1. command-line options 2. user's configuration file (~/.ssh/config) 3. system-wide configuration file (/etc/ssh/ssh_config) So, as far as I can tell, you will need to remove the existing entry from /etc/ssh/ssh_config, there's no other way to override it.
On Wed, 27 Apr 2022, Harald Dunkel wrote:> Anyway, the problem here is that MacOS sets a locale "UTF-8" in > LC_CTYPE instead of "en_US.UTF-8", which produces problems even > though UTF-8 is available on all involved systems.That?s the name of the UTF-8 locale on recent OSX, yeah. Caused quite a few ?WTF? looks. It loosely corresponds to ?C.UTF-8? ever since the Debian (e)glibc maintainers accepted my proposal for it (MirBSD also basically only has the UTF-8 and ASCII locales, so it was natural to propose a C.UTF-8 for GNU stuff) around 2013 or so. Some systems have ?en_US.UTF-8?, some ?en_US.utf8? (HP-sUX!), and again some only have, say, ?de_DE.UTF-8? but not the latter two (hence the introduction of C.UTF-8).> Maybe you should consider to add some guidelines about how to handle > locales into a README within the openssh source package, or in > ssh_config(5), sshd_config(5), etc.?Pretty easy: handle them on the server, period. There?s no way to do it otherwise. bye, //mirabilos -- Infrastrukturexperte ? tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/ Telephon +49 228 54881-393 ? Fax: +49 228 54881-235 HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /?\ The UTF-8 Ribbon ??? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ??? HTML eMail! Also, https://www.tarent.de/newsletter ??? header encryption! ****************************************************