Bug 1801459
Summary: | Misleading message about wrong permissions on sshd host keys. The group is always wrong. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Vinícius Ferrão <vinicius> |
Component: | openssh | Assignee: | Jakub Jelen <jjelen> |
Status: | CLOSED NEXTRELEASE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 32 | CC: | crypto-team, dwalsh, jfch, jjelen, lkundrak, mattias.ellert, plautrba, tmraz |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | openssh-8.2p1-2 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-03-05 10:33:54 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Vinícius Ferrão
2020-02-10 22:29:08 UTC
Thank you for the report. Indeed, this is misleading, but I do not think this issue is sever enough to be fixed in RHEL7 at this time. If you agree, I will move this bug to Fedora and fix it there. Otherwise, please, contact your Red Hat support to make sure this bug is properly triaged. Hello, it's fine to move it to Fedora. It will come to RHEL anyway one day. Sorry to comment again, there's a question about the GID of ssh_keys on the additional info part. Should this be another bug or can be handled here? In my case the server have GID 998 for ssh_keys but the images on the server had GID 997 for ssh_keys. And when a client boot with the image from the server, it end up with wrong permissions. -rw-r----- 1 root printadmin 668 Feb 8 13:26 ssh_host_dsa_key -rw-r--r-- 1 root root 622 Feb 8 13:26 ssh_host_dsa_key.pub -rw-r----- 1 root printadmin 227 Feb 8 13:26 ssh_host_ecdsa_key -rw-r--r-- 1 root root 194 Feb 8 13:26 ssh_host_ecdsa_key.pub -rw-r----- 1 root printadmin 432 Feb 8 13:26 ssh_host_ed25519_key -rw-r--r-- 1 root root 114 Feb 8 13:26 ssh_host_ed25519_key.pub -rw-r----- 1 root printadmin 1679 Feb 8 13:26 ssh_host_rsa_key -rw-r--r-- 1 root root 414 Feb 8 13:26 ssh_host_rsa_key.pub And again, SSH is broken since 640 with "printadmin" is not allowed. This sounds like some issue with the image creation or something that I can not handle inside of OpenSSH. The installation creates a ssh-keys group, the host keys are created during the first boot with this (named) group, but if there is something messing with the /etc/passwd or mounting /etc to different filesystem with different gids it is the place where to look. Using reserved gid for this use case seems like overkill [1]. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/ This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32. FYI, this should have been fixed with the latest update in Fedora 32/rawhide: https://src.fedoraproject.org/rpms/openssh/c/2b86acd3 Let me know if this is sufficient or I should add also a note about the ssh_keys group to the message. Jakub, that was extremely fast. Thank you. I don't have any machine here to test the changes, but reading the code appears to be OK. What is the error message after the patch? Do you have the output from the test pipeline? The message stays in the original wording from OpenSSH portable: https://github.com/openssh/openssh-portable/blob/master/authfile.c#L105 error("Permissions 0%3.3o for '%s' are too open.", (u_int)st.st_mode & 0777, filename); error("It is required that your private key files are NOT accessible by others."); error("This private key will be ignored."); The only confusion could happen in case the keys will be owned by different user than ssh_keys (which was the case for you), so it still does not give you the right hint to change the group of the key. But the message is same for client and server keys so I would probably like to avoid modifying the message itself. |