Bug 1478175 - The UseDNS configuration option changed default behaviour between 7.3 and 7.4, this breaks existing configurations until manually corrected [NEEDINFO]
Summary: The UseDNS configuration option changed default behaviour between 7.3 and 7.4...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: Stefan Dordevic
Mirek Jahoda
: 1477846 (view as bug list)
Depends On:
Blocks: 1420851 1479259
TreeView+ depends on / blocked
Reported: 2017-08-03 19:37 UTC by Kyle Walker
Modified: 2020-09-10 11:06 UTC (History)
16 users (show)

Fixed In Version: openssh-7.4p1-12.el7
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
: 1479259 (view as bug list)
Last Closed: 2018-04-10 18:19:11 UTC
Target Upstream Version:
fkrska: needinfo? (jreznik)

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3139201 None None None 2017-08-03 20:10:18 UTC
Red Hat Product Errata RHSA-2018:0980 None None None 2018-04-10 18:20:29 UTC

Description Kyle Walker 2017-08-03 19:37:07 UTC
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):

How reproducible:

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:

Comment 5 Kamil Dudka 2017-08-04 05:43:34 UTC
*** Bug 1477846 has been marked as a duplicate of this bug. ***

Comment 6 Jakub Jelen 2017-08-04 06:36:41 UTC
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

Comment 7 Kamil Dudka 2017-08-04 08:00:42 UTC
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?

Comment 8 Jakub Jelen 2017-08-04 09:19:50 UTC
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.

Comment 9 Kamil Dudka 2017-08-04 10:08:07 UTC
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.

Comment 10 Kyle Walker 2017-08-04 12:19:44 UTC

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:
             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

Comment 27 errata-xmlrpc 2018-04-10 18:19:11 UTC
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.


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