RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1349015 - sshd_config should contain AcceptEnv TZ by default
Summary: sshd_config should contain AcceptEnv TZ by default
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.4
Hardware: All
OS: All
unspecified
low
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-22 13:55 UTC by ervin.nemeth
Modified: 2023-08-01 21:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-28 13:17:44 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description ervin.nemeth 2016-06-22 13:55:07 UTC 
Description of problem:
If a user is setting the TZ parameter in his environment, he can change how the date is displayed by commands. It would be especially useful to carry over that parameter when logging into a remote system. Unfortunately the default /etc/sshd_config does not allow the user to do so.

As I see, RedHat decided to whitelist the LANG and LC_* parameters with "AcceptEnv". Please consider adding TZ, too.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 Jakub Jelen 2016-06-23 08:03:37 UTC 
> As I see, RedHat decided to whitelist the LANG and LC_* parameters with "AcceptEnv". Please consider adding TZ, too.

The LANG and LC_* are send/accepted by the ssh/sshd based on the report in a bug #179851, 10 years ago. The arguments are mostly about the encoding, which might cause problems if not transferred to the remote session. But on the other hand requesting a language/locale/encoding that is not installed on the server causes problem in various tools unable to handle the errors.

Both the above LANG and LC_* environment variables are standard in shell and set by default, unlike the TZ. Once you configure TZ in your local system (and you have got a reason to set this up to something different than system-wide value), you should be able to configure also the server with the same TZ or to send/accept this configuration. I don't think this should come by default.

Thank you for the input and idea for improvement, but note that bugzilla is not a support tool. If you have a good reason and business requirement to see this in the next RHEL release, please get in touch with your Red Hat support: https://access.redhat.com/support/
Comment 3 Carl Ponder 2023-08-01 20:26:49 UTC 

I use a number of remote clusters with job-control systems like SLURM and PBS. When I look at the start-times and expected finish-times on running jobs, it's convenient to see them in my local time.
I do travel a lot, so propagating the TZ variable from my laptop would be a very simple & seamless to deal with this.
It's a pain to have to manually reset the TZ each time I log in, or manually edit my ~/.bash_profile each time I log on from a different timezone.

I get that there would be a problem if the remote cluster didn't have a current list of timezones and couldn't recognize the one I'm sending.
But none of this will happen if I don't use an explicit SendEnv in my ~/.ssh/config, anyway.
So if I see problems on one of the remote clusters, I'll either not send the TZ to that one, or try to find a more canonical setting (like GMT-relative or something).
Comment 4 Carl Ponder 2023-08-01 21:51:10 UTC 
Also, is this /etc/ssh/sshd_config inherited from the upstream Fedora development?
Note You need to log in before you can comment on or make changes to this bug.