|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>|
|Version:||32||CC:||crypto-team, dwalsh, jfch, jjelen, lkundrak, mattias.ellert, plautrba, tmraz|
|Fixed In Version:||openssh-8.2p1-2||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2020-03-05 10:33:54 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Vinícius Ferrão 2020-02-10 22:29:08 UTC
Description of problem: Permissions error are misleading when the SSH host keys does not comply with the required permissions. Note the error message saying: Permissions 0604. And not 0644: Feb 10 19:23:47 cabecudo sshd: error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Feb 10 19:23:47 cabecudo sshd: error: @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ Feb 10 19:23:47 cabecudo sshd: error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Feb 10 19:23:47 cabecudo sshd: error: Permissions 0604 for '/etc/ssh/ssh_host_ecdsa_key' are too open. Feb 10 19:23:47 cabecudo sshd: error: It is required that your private key files are NOT accessible by others. Feb 10 19:23:47 cabecudo sshd: error: This private key will be ignored. Feb 10 19:23:47 cabecudo sshd: error: key_load_private: bad permissions Feb 10 19:23:47 cabecudo sshd: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key Version-Release number of selected component (if applicable): openssh-7.4p1-21.el7.x86_64 openssh-server-7.4p1-21.el7.x86_64 openssh-clients-7.4p1-21.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Change the permission of any SSH host key to something higher than 640, like 644. 2. Restart sshd 3. Watch the error message on /var/log/messages Actual results: The error message says that the group is always -4. Expected results: Correct message with the right permissions to guide the user. Additional info: This is occasioned by this patch: https://src.fedoraproject.org/rpms/openssh/blob/master/f/openssh-6.6p1-keyperm.patch I came across this issue while trying to debug problems with SSH Hostbased Authentication and this error message got me really confused of what was happening. Another issue, that I don't know if it's relevant or not, is that the group is hardcoded on the code: ssh_keys. And I came across different systems with different gid for ssh_keys. This is extremely bad. I think ssh_keys should be a reserved group. More references: https://bugzilla.mindrot.org/show_bug.cgi?id=1893 https://src.fedoraproject.org/rpms/openssh/blob/master/f/openssh.spec https://bugzilla.redhat.com/show_bug.cgi?id=819896
Comment 2 Jakub Jelen 2020-02-11 09:49:31 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.
Comment 3 Vinícius Ferrão 2020-02-11 14:49:53 UTC
Hello, it's fine to move it to Fedora. It will come to RHEL anyway one day.
Comment 4 Vinícius Ferrão 2020-02-11 14:56:31 UTC
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.
Comment 5 Jakub Jelen 2020-02-11 15:46:01 UTC
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 .  https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
Comment 6 Ben Cotton 2020-02-11 16:30:28 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
Comment 7 Jakub Jelen 2020-03-05 10:33:54 UTC
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.
Comment 8 Vinícius Ferrão 2020-03-05 16:36:32 UTC
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?
Comment 9 Jakub Jelen 2020-03-06 10:05:09 UTC
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.