Dear colleagues,
Unfortunately, as it was 11 years ago, we can't find the exact explanation where the requirement came from. We think that we intended to increase security, but it probably caused more confusion than gain of the security over the years.
The patch allows more relaxed permissions for the private keys than upstream OpenSSH permits - 0640 instead of 0600, and the key file must belong to the ssh_keys group. The ssh_keysign utility was simultaneously changed from suid root to sgid ssh_keys.
The side effect of this solution is that ssh with host based auth (HBA) started to fail after changing group ID ( with newgrp, etc.). In the case of HBA ssh invokes ssh-keysign that does a lot of sanity checks including group checks. The workaround is returning setuid bit instead of sgid, and we recommend it to our clients.
Some more information is available in https://bugzilla.redhat.com/show_bug.cgi?id=1498845
As this problem affects several clients, and it is a deviation from upstream (the similar patch was rejected by upstream), we want to drop this downstream patch in Fedora. We also can get rid of a designated ssh_keys group
The problem we expect is that after reverting the patch we can lose the remote access to the hosts because sshd will reject starting because of group reading permissions. This should be covered by the upgrade scriptlet, though we still may come across some issues, especially if you use host keys in non-standard locations. How do we properly implement this feature to avoid customers' negative feedback? Current upgrade scriptlet covers standard key locations/names and works well enough at the 1st glance.
The proposed changes are available https://src.fedoraproject.org/rpms/openssh/pull-request/37
A separate question is whether we want to publish this announcement as a Fedora change and at what level. For me it looks like a self-contained change.
--
Many years ago we implemented the patch https://src.fedoraproject.org/rpms/openssh/c/1ddd0ee5
Unfortunately, as it was 11 years ago, we can't find the exact explanation where the requirement came from. We think that we intended to increase security, but it probably caused more confusion than gain of the security over the years.
The patch allows more relaxed permissions for the private keys than upstream OpenSSH permits - 0640 instead of 0600, and the key file must belong to the ssh_keys group. The ssh_keysign utility was simultaneously changed from suid root to sgid ssh_keys.
The side effect of this solution is that ssh with host based auth (HBA) started to fail after changing group ID ( with newgrp, etc.). In the case of HBA ssh invokes ssh-keysign that does a lot of sanity checks including group checks. The workaround is returning setuid bit instead of sgid, and we recommend it to our clients.
Some more information is available in https://bugzilla.redhat.com/show_bug.cgi?id=1498845
As this problem affects several clients, and it is a deviation from upstream (the similar patch was rejected by upstream), we want to drop this downstream patch in Fedora. We also can get rid of a designated ssh_keys group
The problem we expect is that after reverting the patch we can lose the remote access to the hosts because sshd will reject starting because of group reading permissions. This should be covered by the upgrade scriptlet, though we still may come across some issues, especially if you use host keys in non-standard locations. How do we properly implement this feature to avoid customers' negative feedback? Current upgrade scriptlet covers standard key locations/names and works well enough at the 1st glance.
The proposed changes are available https://src.fedoraproject.org/rpms/openssh/pull-request/37
A separate question is whether we want to publish this announcement as a Fedora change and at what level. For me it looks like a self-contained change.
Dmitry Belyavskiy
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
