fix: set up the sdssh group before using it in ACLs
#7426
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Specifically, enroll the SecureDrop SSH user in the "sdssh" group before setting sshd's "AllowGroups" directive.
legoktm
approved these changes
Jan 24, 2025
There was a problem hiding this comment.
Thanks, this looks good. The noble staging failure is unrelated: test_unattended_upgrades_functional
I looked for other uses of the the SSH user since we're creating it at a different stage and the only use was in the reset-ssh-key playbook, which is an entirely separate thing.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Status
Ready for review
Description of Changes
Fixes #7425—I believe as non-invasively as possible.
Testing
I've successfully installed a Monitor Server from scratch with this change, following #7417. In addition, please consider:
create_userstask from the latercommonplaybook to the earlierrestrict-direct-accessplaybook?Deployment
Assuming that the above checks out, this change should have no deployment considerations: it changes the sequence of provisioning, not the final provisioned state.