-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSH rootkey configuration is too open #16
Comments
I'd vote for removing the root key support alltogether. I've had good results with a combination of the I also would not expect a hardening cookbook to manage authorized_keys, except for fixing its permissions or removing non-compliant entries or that kind of stuff. my 2ct anyway. |
From my perspective, we should be focussing on ssh. The current setup is confusing for users (I had discussions about this topic). Instead we should remove this support and ensure that it works well with the other user management modules like fnichol/chef-user. +1 from my side |
Since this is a breaking change, we should schedule it for the next version. As an intermediate solution, we should add a deprecation warning. |
ssh keys for root are supported in the manner that fnichol/chef-user works. However, it has a bug: it pulls in users that aren't active.
We have a choice to make for 1.0 release: Either support ssh root keys fully, with the active users configuration of chef-user, or remove this support entirely.
Adding rootkey configuration in this manner is a 2year-old workaround to configure a server with keys for user root. We have to decide if this is still in scope of hardening. Feedback welcome.
The text was updated successfully, but these errors were encountered: