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.
Bug 1401069 - USGCB/STIG Profile causes SSHD to not start
Summary: USGCB/STIG Profile causes SSHD to not start
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: scap-security-guide
Version: 7.3
Hardware: Unspecified
OS: Linux
Target Milestone: rc
: ---
Assignee: Watson Yuuma Sato
QA Contact: Marek Haicman
Mirek Jahoda
Depends On:
Blocks: 1415152
TreeView+ depends on / blocked
Reported: 2016-12-02 16:47 UTC by Brian Stinson
Modified: 2020-09-10 10:00 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Prior to this update, the OpenSCAP remediation function based on United States Government Configuration Baseline (USGCB) or Security Technical Implementation Guide (STIG) profiles from the SCAP Security Guide incorrectly changed the /etc/ssh/sshd_config file. Consequently, the SSH daemon failed to start and the system was not accessible using the SSH protocol. The remediation function has been fixed and a machine remediated using USGCB or STIG profiles is now accessible by SSH.
Clone Of:
: 1415152 (view as bug list)
Last Closed: 2017-08-01 12:23:38 UTC
Target Upstream Version:

Attachments (Terms of Use)
Log showing Cipher messages (11.42 KB, text/x-vhdl)
2016-12-02 16:47 UTC, Brian Stinson
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2064 0 normal SHIPPED_LIVE scap-security-guide bug fix and enhancement update 2017-08-01 16:05:50 UTC

Description Brian Stinson 2016-12-02 16:47:22 UTC
Created attachment 1227420 [details]
Log showing Cipher messages

Description of problem:
Installing RHEL 7.3 and selecting the 'United States Government Configuration Baseline (USGCB/STIG)' profile causes the sshd service to stop on a malformed configuration file.

Version-Release number of selected component (if applicable):
$ rpm -qa scap-security-guide

How reproducible:
Every new install with the USGCB/STIG profile applied

Steps to Reproduce:
1. Start a fresh RHEL 7.3 Install
2. Choose the 'United States Government Configuration Baseline' profile from the security profile spoke
3. Notice that journalctl -u sshd reports an error, and that the last line of /etc/ssh/sshd_config containing the ciphers is concatenated with another directive for the MACs

Actual results:
sshd.service is stopped, and a 'BAD SSH2 cipher spec' message appears in the journal (see attached sshd_log)

Expected results:
sshd.service should be running

Additional info:
I suspect that the sshd_config does not have a trailing newline after the 'Ciphers' directive which means that remediations/bash/sshd_use_approved_macs.sh concatenates the MACs directive onto the same line

Comment 10 Marek Haicman 2017-01-19 12:43:21 UTC
This PR should fix the issue:  https://github.com/OpenSCAP/scap-security-guide/pull/1471

Comment 13 Marek Haicman 2017-06-13 21:47:02 UTC
Verified fix in scap-security-guide-0.1.33-4.el7.noarch

State of /etc/ssh/sshd_config after full remediation of ospp (USGCB) profile:
OLD (scap-security-guide-0.1.30-3.el7.noarch):
# Per CCE: Set PermitEmptyPasswords no in /etc/ssh/sshd_config
PermitEmptyPasswords no
# Per CCE: Set PermitUserEnvironment no in /etc/ssh/sshd_config
PermitUserEnvironment no
# Per CCE: Set Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc in /etc/ssh/sshd_config
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbcMACs hmac-sha2-512,hmac-sha2-256,hmac-sha1

# Per CCE-CCE-27295-5: Set Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc in /etc/ssh/sshd_config
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

# Per CCE-CCE-27455-5: Set MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1,hmac-sha1-etm,hmac-sha2-256-etm,hmac-sha2-512-etm in /etc/ssh/sshd_config
MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1,hmac-sha1-etm,hmac-sha2-256-etm,hmac-sha2-512-etm

Comment 14 errata-xmlrpc 2017-08-01 12:23:38 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.