Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
In Red Hat Enterprise Linux 7.4, the default value of the UseDNS configuration option had been changed to "No". This change prevented OpenSSH from translating IP addresses to host names to be used in server configuration files and access rules of the authorized_keys files. However, it also broke existing installations until manually corrected. With this update, the default value of UseDNS has been changed to "Yes", and the default configuration is compatible with Red Hat Enterprise Linux 7.3 and older installations again.
Description of problem:
The openssh-server rebase for 7.4 pulled in the following commit:
commit 3cd5103c1e1aaa59bd66f7f52f6ebbcd5deb12f9
Author: deraadt <deraadt>
Date: Mon Feb 2 01:57:44 2015 +0000
upstream commit
increasing encounters with difficult DNS setups in
darknets has convinced me UseDNS off by default is better ok djm
This breaks existing system configurations when updating. Specifically where UseDNS=yes as a default was previously functional.
Version-Release number of selected component (if applicable):
openssh-server-7.4p1-11.el7.x86_64
How reproducible:
Easily
Steps to Reproduce:
1. Install RHEL 7.3 on a system
2. Verify the UseDNS configuration within /etc/ssh/sshd_config
$ grep UseDNS /etc/ssh/sshd_config
3. Update the openssh-server package
$ yum update openssh-server
4. Verify the UseDNS configuration within /etc/ssh/sshd_config
$ grep UseDNS /etc/ssh/sshd_config
Actual results:
The configuration infers that UseDNS no is the default
# grep UseDNS /etc/ssh/sshd_config
#UseDNS no
Expected results:
A configuration that infers that UseDNS yes is the default
# grep UseDNS /etc/ssh/sshd_config
#UseDNS yes
Additional info:
The documentation you refer to only states that the default has been changed. It does not explain why changing the default in a minor update of RHEL-7 was a good idea. Could you please summarize the reasoning behind?
It changes because upstream changes (the upstream reasoning is in the description of this bug). We did rebase to follow upstream and avoid downstream changes.
The change was known to be potentially disruptive and that is why it was broadly discussed and documented in several places. It was not considered disruptive enough to rationalize reverting.
I understand why it was changed upstream. But the added value of RHEL is that it protects users from upstream changes that could break existing setups. We should have a good reason when we change the default in a minor update of RHEL.
@Jakub,
The primary breakage I am seeing at this point is due to the defaults no longer being functional when paired with "from=" directives. But additional breakage has been noted for applications that make use of the /var/run/utmp file such as who.
Per the manpage:
~~~~
from="pattern-list"
Specifies that in addition to public key authentication, either the canonical name of the
remote host or its IP address must be present in the comma-separated list of patterns.
See PATTERNS in ssh_config(5) for more information on patterns.
In addition to the wildcard matching that may be applied to hostnames or addresses, a
from stanza may match IP addresses using CIDR address/masklen notation.
The purpose of this option is to optionally increase security: public key authentication
by itself does not trust the network or name servers or anything (but the key); however,
if somebody somehow steals the key, the key permits an intruder to log in from anywhere
in the world. This additional option makes using a stolen key more difficult (name
servers and/or routers would have to be compromised in addition to just the key).
~~~~
The former "canonical name of the remote host" requires "UseDNS yes" as was the default previously.
- Kyle Walker
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2018:0980
Comment 28Red Hat Bugzilla
2023-09-14 04:02:02 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Description of problem: The openssh-server rebase for 7.4 pulled in the following commit: commit 3cd5103c1e1aaa59bd66f7f52f6ebbcd5deb12f9 Author: deraadt <deraadt> Date: Mon Feb 2 01:57:44 2015 +0000 upstream commit increasing encounters with difficult DNS setups in darknets has convinced me UseDNS off by default is better ok djm This breaks existing system configurations when updating. Specifically where UseDNS=yes as a default was previously functional. Version-Release number of selected component (if applicable): openssh-server-7.4p1-11.el7.x86_64 How reproducible: Easily Steps to Reproduce: 1. Install RHEL 7.3 on a system 2. Verify the UseDNS configuration within /etc/ssh/sshd_config $ grep UseDNS /etc/ssh/sshd_config 3. Update the openssh-server package $ yum update openssh-server 4. Verify the UseDNS configuration within /etc/ssh/sshd_config $ grep UseDNS /etc/ssh/sshd_config Actual results: The configuration infers that UseDNS no is the default # grep UseDNS /etc/ssh/sshd_config #UseDNS no Expected results: A configuration that infers that UseDNS yes is the default # grep UseDNS /etc/ssh/sshd_config #UseDNS yes Additional info: