Latest revision as of 18:06, 4 January 2023

Restore stricter SSH hostkeys permissions

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: Dmitry Belyavskiy
Email: dbelyavs@redhat.com

Current status

Targeted release: Fedora Linux 38
Last updated: 2023-01-04
devel thread
FESCo issue: #2919
Tracker bug: #2158230
Release notes tracker: #941

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

Feedback

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

@@ Line 1: / Line 1: @@
-{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
-{{admon/tip | Guidance | For details on how to fill out this form, see the [https://docs.fedoraproject.org/en-US/program_management/changes_guide/ documentation].}}
-{{admon/tip | Report issues | To report an issue with this template, file an issue in the [https://pagure.io/fedora-pgm/pgm_docs pgm_docs repo].}}
-<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
 = Restore stricter SSH hostkeys permissions =
-{{Change_Proposal_Banner}}
 == Summary ==
@@ Line 26: / Line 16: @@
 == Current status ==
-[[Category:ChangeReadyForWrangler]]
+[[Category:ChangeAcceptedF38]]
 <!-- When your change proposal page is completed and ready for review and announcement -->
 <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
@@ Line 43: / Line 33: @@
 ON_QA -> change is fully code complete
 -->
-* FESCo issue: <will be assigned by the Wrangler>
+* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/W5RZVSRXH2OJEJIEND4S4NJUTNG2LV6B/ devel thread]
-* Tracker bug: <will be assigned by the Wrangler>
+* FESCo issue: [https://pagure.io/fesco/issue/2919 #2919]
-* Release notes tracker: <will be assigned by the Wrangler>
+* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2158230 #2158230]
+* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/941 #941]
 == Detailed Description ==
@@ Line 72: / Line 63: @@
 <!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
-* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Other developers: <Developers managing SSH host keys beyond the standard scenarios will be affected.
-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)
-* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-Not affected
-* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-Not affected
 * 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.
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
@@ Line 109: / Line 96: @@
 == Contingency Plan ==
-Revert the patch
-<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
+* Contingency mechanism: (What to do?  Who will do it?) Revert the patch
-* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
-* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency deadline: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
-* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Blocks release? <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Search

Changes/SSHKeySignSuidBit: Difference between revisions