Bug 1660166 - RHEL 8 should stop adding AccetEnv to /etc/ssh/sshd_config
Summary: RHEL 8 should stop adding AccetEnv to /etc/ssh/sshd_config
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: openssh
Version: 8.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 8.0
Assignee: Jakub Jelen
QA Contact: BaseOS QE Security Team
Depends On:
TreeView+ depends on / blocked
Reported: 2018-12-17 16:45 UTC by Troels Arvin
Modified: 2018-12-19 10:58 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-12-19 10:58:30 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

Description Troels Arvin 2018-12-17 16:45:48 UTC
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.

Example situation:
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.

Comment 1 Troels Arvin 2018-12-17 18:09:04 UTC
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
 #Banner none

+# Accept locale-related environment variables
 # override default of no subsystems
 Subsystem  sftp    /usr/libexec/sftp-server

Comment 2 Jakub Jelen 2018-12-18 09:42:12 UTC
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 <tmraz@redhat.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.

Comment 4 Troels Arvin 2018-12-18 10:23:45 UTC
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).

Comment 5 Tomas Mraz 2018-12-18 10:37:18 UTC
This is just an opinion. Both passing and not passing the locale environment variables have its pros and cons.

Comment 6 Troels Arvin 2018-12-18 10:56:09 UTC
Tomas: If in doubt, stick to what the upstream software does. Do you agree with that?

Comment 7 Tomas Mraz 2018-12-18 11:03:28 UTC
Not necessarily.

Comment 8 Jakub Jelen 2018-12-19 10:58:30 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.