Repository navigation
Conversation
Fedora sshd-keygen writes the host keys root:root 0600, and products that set dedicated_ssh_keyowner (Fedora, RHEL, OL, AlmaLinux, AL2023, RHCOS) only accepted the ssh_keys group, so a default Fedora install fails file_groupownership_sshd_private_key. The root group is as strict: file_permissions_sshd_private_key already accepts root:root 0600, and CIS asks for root or the dedicated group. The remediations still set the dedicated group on keys owned by neither, as it comes first in gid_or_name.
spnngl
requested review from
Mab879,
jan-cerny,
matusmarhefka and
vojtapolasek
as code owners
November 6, 2026 10:36
|
Hi @spnngl. Thanks for your PR. I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
spnngl
added a commit
to spnngl/images
that referenced
this pull request
Nov 6, 2026
A node of 44-v1.35 scored 94.19, 8 rules failed: - user init files: core's home files, 0644 from /etc/skel. The initramfs, rebuilt without dracut modules ignition-conf and ignition-conf-fcos, no longer creates the core user nor enables afterburn-sshkeys@core: rootless is the only login. - world-writable, unowned and ungrouped files: the containers' (image owners, kubelet's 0666 termination-log, emptyDir), and again through /sysroot. openscap.service hides /sysroot, containerd's storage and the pods' volumes; the rules still check the host. - rpcbind: removed with its NFSv3 dependants; NFSv4 needs none. - SSH host keys group: Fedora writes them root:root 0600, the check wants ssh_keys. A sshd-keygen@ drop-in sets it until ComplianceAsCode/content#15310 accepts root. - /boot/grub2 permissions: off, console.cfg and bootuuid.cfg are 0644 on a read-only /boot and hold nothing secret.
Member
|
I'm wondering that maybe this should be am XCCDF variable, not a build time one. I will need to double check the underlying policies to make sure this allowable as well. |
spnngl
added a commit
to spnngl/images
that referenced
this pull request
Nov 9, 2026
The node scan failed file_permissions_sshd_private_key on every node. Its check takes ssh_keys' GID from /etc/group only, and FCOS keeps the group in /usr/lib/group, so the root:ssh_keys keys the sshd-keygen@ drop-in made counted as offending. That drop-in only kept file_groupownership_sshd_private_key passing: the two rules can't both pass. - Drop 50-ssh-keys-group.conf: keys stay Fedora's root:root 0600. - Turn file_groupownership_sshd_private_key off in the node profile, until ComplianceAsCode/content#15310 accepts root. - Test for root:root 0600. Nodes made with the drop-in keep root:ssh_keys keys.
spnngl
added a commit
to spnngl/images
that referenced
this pull request
Nov 9, 2026
The node scan failed file_permissions_sshd_private_key on every node. Its check takes ssh_keys' GID from /etc/group only, and FCOS keeps the group in /usr/lib/group, so the root:ssh_keys keys the sshd-keygen@ drop-in made counted as offending. That drop-in only kept file_groupownership_sshd_private_key passing: the two rules can't both pass. - Drop 50-ssh-keys-group.conf: keys stay Fedora's root:root 0600. - Turn file_groupownership_sshd_private_key off in the node profile, until ComplianceAsCode/content#15310 accepts root. - Test for root:root 0600. Nodes made with the drop-in keep root:ssh_keys keys.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description:
file_groupownership_sshd_private_keyaccepts therootgroup beside the dedicated SSH key group (dedicated_ssh_keyowner,ssh_keys) for the products that set one. The description says so.root_groupowner.pass.sh.Rationale:
sshd-keygen(/usr/libexec/openssh/sshd-keygen, openssh-server 10.2p1 in Fedora 44) writes the host keysroot:rootwith mode 0600, withoutchgrp. Fedora's product setsdedicated_ssh_keyowner: ssh_keys, so the rule fails on a default install although the keys are as strict as can be.file_permissions_sshd_private_keyalready acceptsroot:root0600 (supercompliance.pass.sh), and CIS's audit acceptsrootor the SSH key group: the two rules of the same CIS control now agree.gid_or_name, sochgrpstill sets it.Review Hints:
./build_product fedora --datastream-only, then in a Fedora CoreOS 44 container (quay.io/fedora/fedora-coreos:44.20261023.3.1, withopenscap-scannerandscap-security-guide0.1.82 installed), after/usr/libexec/openssh/sshd-keygen ed25519:rootssh_keys