Description of problem:
RHEL's /etc/ssh/sshd_config file differs from the upstream one, in that RHEL has added a number of AcceptEnv lines.
The lines mean that a large number of client environment variables may be copied into the environment on a server, and that may cause bad outcomes which may even be hard to catch and troubleshoot.
The server's system locale is iso88591.
The user's workstation uses UTF-8.
User is logged in to the server and working with a file with iso55891 encoding.
In the above situation, it's very easy for the user to forget that the file will be interpreted as an UTF-8 file by LANG aware tools, and if loading the file into a database, for example, it may result in wrong or lost data. I've seen this happen for co-workers and myself in two different workplaces. I believe many others may have been bitten by it, perhaps without noticing, leaving around subtly wrong data. Note how SAP recommends commenting out AcceptEnv on page 61 on this book:
In general, I think it's problematic when RHEL changes default settings from upstream software. - Especially when it may lead to subtle data manipulation issues.
RHEL 8 is a good chance to remove RHEL's adjustment of /etc/ssh/sshd_config, so that it is brought in line with upstream openssh.
AcceptEnv also means that on a given server, two users may use the exact same script manipulating the exact same data, but still get different results. And the differences may be easily overlooked, because it may only affect a small subset of the data being handled.
Of course, that may also happen for other reasons, but I believe that it's important to minimized the risk of it happening.
Specifically, I'm suggesting that the following section from openssh-7.7p1-redhat.patch in the source RPM file be removed (it's the last part of the patch file):
@@ -106,6 +126,12 @@ AuthorizedKeysFile .ssh/authorized_keys
# no default banner path
+# Accept locale-related environment variables
+AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
+AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
+AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server
This is in RHEL since 2006 (bug #179851) and from what I understood this was actually trying to resolve these issues in RHEL 5.
Maybe Tomas can comment on this:
* Mon Feb 6 2006 Tomas Mraz <email@example.com> - 4.3p1-2
- pass locale environment variables to server, accept them there (#179851)
I already saw this causing some issues (especially if the client sends language or encoding that is not supported by the server at all).
If we are supposed to remove it, it is probably last chance around this time.
Thanks to Jakub for tracing the origins for this.
The old bug #179851 has a fundamental problem. It states:
Ssh doesn't pass "local" locale-related envvars to remote host, as it should.
The "as is should" part is simply plain wrong, given that upstream OpenSSH behaviour is to prevent environment passing by default (except for the TERM variable).
This is just an opinion. Both passing and not passing the locale environment variables have its pros and cons.
Tomas: If in doubt, stick to what the upstream software does. Do you agree with that?
It is too late for changing this in RHEL8 after Beta. Passing and accepting environment variables related to locale and language are usually good user experience and avoids similar kind of issues as described in the referenced bug. The UTF8 encoding is quite standard these days so in case you need to run a server with different encoding (for whatever reason), the openssh has a configuration file, where you can adjust it. We are not convinced that changing this would solve more issues than it would cause.
If it is important for your business case, please contact your Red Hat support.