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: opensshAssignee: Jakub Jelen <jjelen>
Status: CLOSED NEXTRELEASE QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: low    
Version: 32CC: crypto-team, dwalsh, jfch, jjelen, lkundrak, mattias.ellert, plautrba, tmraz
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
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:

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[14070]: error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Feb 10 19:23:47 cabecudo sshd[14070]: error: @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
Feb 10 19:23:47 cabecudo sshd[14070]: error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Feb 10 19:23:47 cabecudo sshd[14070]: error: Permissions 0604 for '/etc/ssh/ssh_host_ecdsa_key' are too open.
Feb 10 19:23:47 cabecudo sshd[14070]: error: It is required that your private key files are NOT accessible by others.
Feb 10 19:23:47 cabecudo sshd[14070]: error: This private key will be ignored.
Feb 10 19:23:47 cabecudo sshd[14070]: error: key_load_private: bad permissions
Feb 10 19:23:47 cabecudo sshd[14070]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key

Version-Release number of selected component (if applicable):

How reproducible:

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:

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:

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 [1].

[1] 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:


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:


		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.