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

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days