F38 proposal: Restore stricter SSH hostkeys permissions (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/SSHKeySignSuidBit
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
We want to
- drop a downstream-only patch to ssh permitting group-readable ssh host keys
- drop a ssh_keys group
- restore suid bit instead of sgid on a helper utility ssh-keysign
== Owner ==
* Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
* Email: dbelyavs(a)redhat.com
== Detailed Description ==
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 did the requirement come 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 have 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 hostbased auth (HBA)
started to fail after changing group ID ( with newgrp, etc.). In case
of HBA ssh invokes ssh-keysign that does a lot of sanity checks
including groups 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 proposed changes are available
https://src.fedoraproject.org/rpms/openssh/pull-request/37
== Benefit to Fedora ==
We reduce deviation from upstream and reduce maintenance cost for customers.
== Scope ==
* Proposal owners:
* Other developers: <Developers managing SSH host keys beyond the
standard scenarios will be affected.
* Release engineering: Not affected
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The problem we expect is that after implementing the change we can
lose the remote access to the hosts because sshd will reject starting
because of group reading permissions. This should be covered by
upgrade script, though we still may come across some issues,
especially if you use host keys in non-standard location.
There is possible risk with config mgmt tools like puppet/ansible,
that might be managing SSH host keys and their permissions/ownership.
== How To Test ==
sshd successfully starts on the freshly installed systems and systems
remain remotely accessable via SSH.
sshd successfully restarts on the upgraded systems and systems remain
remotely accessable via SSH.
== User Experience ==
This change shouldn't be noticeable by users.
== Dependencies ==
No other changes may affect this change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the patch
* Contingency deadline:
* Blocks release?
== Documentation ==
https://src.fedoraproject.org/rpms/openssh/pull-request/37 is a patch,
and there should be a some RN item describing the change in details.
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis