Bug 1478175 - The UseDNS configuration option changed default behaviour between 7.3 and 7.4, this breaks existing configurations until manually corrected [NEEDINFO]
The UseDNS configuration option changed default behaviour between 7.3 and 7.4...
Status: MODIFIED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh (Show other bugs)
7.4
Unspecified Unspecified
urgent Severity urgent
: rc
: ---
Assigned To: Jakub Jelen
BaseOS QE Security Team
Mirek Jahoda
: Regression, ZStream
: 1477846 (view as bug list)
Depends On:
Blocks: 1420851 1479259
  Show dependency treegraph
 
Reported: 2017-08-03 15:37 EDT by Kyle Walker
Modified: 2017-09-04 11:47 EDT (History)
16 users (show)

See Also:
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.
Story Points: ---
Clone Of:
: 1479259 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
fkrska: needinfo? (jreznik)


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3139201 None None None 2017-08-03 16:10 EDT

  None (edit)
Description Kyle Walker 2017-08-03 15:37:07 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:
Comment 5 Kamil Dudka 2017-08-04 01:43:34 EDT
*** Bug 1477846 has been marked as a duplicate of this bug. ***
Comment 6 Jakub Jelen 2017-08-04 02:36:41 EDT
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 04:00:42 EDT
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 05:19:50 EDT
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 06:08:07 EDT
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 08:19:44 EDT
@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

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