Red Hat Bugzilla – Bug 1478175
The UseDNS configuration option changed default behaviour between 7.3 and 7.4, this breaks existing configurations until manually corrected
Last modified: 2018-04-10 14:20:29 EDT
Description of problem: The openssh-server rebase for 7.4 pulled in the following commit: commit 3cd5103c1e1aaa59bd66f7f52f6ebbcd5deb12f9 Author: deraadt@openbsd.org <deraadt@openbsd.org> 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:
*** Bug 1477846 has been marked as a duplicate of this bug. ***
The change was broadly discussed during last half year and rather than reverting it from upstream, it was kept and documented in the Release notes [1] to make everyone aware of that change. This is also covered in the Migration guide for RHEL7 [2]. I am really sorry that it is causing some problems (and that it was not discovered earlier in internal products), but we really tried hard to update the documentation and make everyone aware of that. Can you clarify "breaking existing configurations" or "Atomic installation issue"? [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/new_features_security.html [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Migration_Planning_Guide/sect-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Security_and_Access_Control.html#sect-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Security-Changes-to-defaults
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