Skip to content
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

Replace shared root login with user accounts #628

Closed
wants to merge 13 commits into from
Closed

Conversation

@edunham
Copy link
Contributor

edunham commented Mar 27, 2017

These changes:

  • Create individual user account for everyone who has an SSH key
  • Add each SSH key to its person's account instead of to root
  • Forbid root login at ssh config level (OSX and Ubuntu)
  • Permit passwordless sudo for each user who has an SSH key. This is not great but it is no worse than the current state of affairs. The options for moving away from passwordless sudo will all potentially break peoples' workflows, so I'd like to write and test them as a separate set of changes from this one.

r? @aneeshusa to catch my inevitable Salt room-for-improvement

cc @larsbergstrom for thoughts on if/how we should actively disallow root login on Windows

Labeling please-don't-merge because I'm 90% sure something in here will break Travis.


This change is Reviewable

@edunham
Copy link
Contributor Author

edunham commented Mar 27, 2017

Oh actually I had a couple old PRs about this which were broken for various reasons. I'll integrate the suggestions from them before consuming anyone's review time.

@edunham edunham force-pushed the edunham:accts branch from 1fc0c9d to edffbd7 Mar 27, 2017
@larsbergstrom
Copy link
Contributor

larsbergstrom commented Apr 1, 2017

From the logs, it looks like the creation step needs to be depended upon by the keyfile installation step? There are a bunch of OSX errors about [ERROR ] Failed to add the ssh key. Is the home directory available, and/or does the key file exist?

Copy link
Member

aneeshusa left a comment

I haven't tested this, but looks good overall so far. I left some Salt comments.

# Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.
PermitRootLogin No

# Use kernel sandbox mechanisms where possible in unprivilegied processes

This comment has been minimized.

@aneeshusa

aneeshusa Apr 11, 2017

Member

spelling: unprivileged

{% for ssh_user in admin.ssh_users %}
{{ ssh_user }}:
user.present:

This comment has been minimized.

@aneeshusa

aneeshusa Apr 11, 2017

Member

Before user.present, we should also use group.present to create a group for each user with the same name. We should require the group state from the user state and set gid_from_name: True in the user state.

{{ ssh_user }}:
user.present:
- empty_password: True
- optional_groups:

This comment has been minimized.

@aneeshusa

aneeshusa Apr 11, 2017

Member

We should use groups instead of optional_groups so Salt complains if this doesn't work.

user.present:
- empty_password: True
- optional_groups:
- wheel

This comment has been minimized.

@aneeshusa

aneeshusa Apr 11, 2017

Member

Might be nice to add a group.present state for the wheel group itself.

- empty_password: True
- optional_groups:
- wheel
ssh_auth.present:

This comment has been minimized.

@aneeshusa

aneeshusa Apr 11, 2017

Member

This should require the user.present state.

# FIXME This is just as bad as all sharing root login.
/etc/sudoers:
file.append:

This comment has been minimized.

@aneeshusa

aneeshusa Apr 11, 2017

Member

I've personally never been a fan of file.append, I prefer to use file.managed and control the whole contents instead of hoping that Salt is always smart enough to do the right thing with file.append.

/etc/sudoers:
file.append:
- text:
{% for ssh_user in admin.ssh_users %}

This comment has been minimized.

@aneeshusa

aneeshusa Apr 11, 2017

Member

We could provide permissions to the wheel group instead of each user individually.

{% for ssh_user in admin.ssh_users %}
sshkey-{{ ssh_user }}:
ssh_auth.present:
# FIXME we should also explicitly AllowUsers usera userb userc

This comment has been minimized.

@aneeshusa

aneeshusa Apr 11, 2017

Member

We could also use AllowGroups wheel, I think.

This comment has been minimized.

@edunham

edunham Oct 26, 2017

Author Contributor

I believe we want to end up with as few people having root access as possible, so most users who can access the hosts to examine logs or whatever will not be in wheel. Thus they'll either need to be individually added with AllowUsers, or all added to a group which in turn is added using AllowGroups. While a dedicated group would have the same effect as individually allowing, it adds a layer of indirection when trying to figure out which users have access compared to just looking at sshd_config.

So my FIXME was pretty unclear, but I'm pretty sure it's an issue that AllowGroups wheel does not adequately address.

@aneeshusa
Copy link
Member

aneeshusa commented Apr 11, 2017

It might also be nice to switch to a non-standard port to reduce log spam, since we've set the log level to verbose.

@aneeshusa
Copy link
Member

aneeshusa commented Apr 25, 2017

It might also be cool to integrate https://github.com/mozilla/ssh_scan as a test.

@aneeshusa
Copy link
Member

aneeshusa commented May 6, 2017

If we want to implement #657, I suggest the following changes:

  • Don't provide sudoers access to these per-user accounts; we'll implement the Publisher ACL in a separate PR
  • Keep root SSH access enabled for now

After testing Publisher ACL, we can enable sudoers access if necessary and drop root SSH access.

@bors-servo
Copy link
Contributor

bors-servo commented Jun 14, 2017

The latest upstream changes (presumably #694) made this pull request unmergeable. Please resolve the merge conflicts.

@edunham
Copy link
Contributor Author

edunham commented Oct 26, 2017

Feedbacks addressed; merging in master and fixing the conflicts now

sshkeys should not be needed because the states for individual user login
should be smart enough to make the directories they need.

Should.

We will briefly need similar states to these back for removing all the
authorized keys once we verify that user logins are working.
@edunham edunham force-pushed the edunham:accts branch from 9306996 to eb905c0 Oct 26, 2017
Copy link
Member

aneeshusa left a comment

Thanks for updating this! I'd made #725 in the meantime with a more robust SSH config and a test, so how do you feel about taking the SSH bits out of this PR and having this PR about creating individual accounts?

- groups:
- wheel
- require:
- group:

This comment has been minimized.

@aneeshusa

aneeshusa Oct 27, 2017

Member

Unless this is a new feature, I don't think this works and we'll need:

- group: wheel
- group: {{ ssh_user }}

as two separate lines.

This comment has been minimized.

@edunham

edunham Oct 27, 2017

Author Contributor

oops, yeah. Fixed.

{% for ssh_user in admin.ssh_users %}
{{ ssh_user }}:
group.present:
- members:

This comment has been minimized.

@aneeshusa

aneeshusa Oct 27, 2017

Member

We need to create the group first, and then the user, so this state shouldn't have a members key as that would be a circular dependency. The gid_from_name parameter in the user.present state will take care of this.

This comment has been minimized.

@aneeshusa

aneeshusa Oct 27, 2017

Member

FYI, since the group.present will be empty at that point, just set it to an empty list as so to get the YAML to parse correctly: https://docs.saltstack.com/en/2016.3/topics/troubleshooting/yaml_idiosyncrasies.html#yaml-does-not-like-double-short-decs

- mode: 644
- source: salt://{{ tpldir }}/files/sshd_config
wheel:

This comment has been minimized.

@aneeshusa

aneeshusa Oct 27, 2017

Member

I agree with your comment about only providing some users root access. To prevent confusion, let's rename this group to sshusers, and reserve the wheel group for users that will have root perms.

- group:
- wheel
- {{ ssh_user }}
ssh_auth.present:

This comment has been minimized.

@aneeshusa

aneeshusa Oct 27, 2017

Member

We'll need to keep the two-state solution of file.managed to continue being able to handle SSH key rotation and revocation.

- mode: 700
sshkeys:
/etc/sshd_config:

This comment has been minimized.

@aneeshusa

aneeshusa Oct 27, 2017

Member

We should keep the states that set up the SSH keys for the root user, as we don't want to lock ourselves out (and at least for now want to keep installing root SSH keys on new machines).

This comment has been minimized.

@edunham

edunham Nov 7, 2017

Author Contributor

Fixed :)

@aneeshusa
Copy link
Member

aneeshusa commented Oct 27, 2017

Also, since it doesn't look like the Publisher ACL feature panned out as I was expecting, feel free to bring back the sudoers-related states. A rebase would also be helpful for cleaning up the history a bit.

@edunham
Copy link
Contributor Author

edunham commented Oct 27, 2017

@aneeshusa Should be more-right. I un-clobbered your SSH states, restricted it to not trying to do Mac because getting account creation right on OSX is 🤷‍♂️, but kept the sshd config addition.

Looking ready for squash?

@edunham edunham dismissed aneeshusa’s stale review Nov 7, 2017

Can't find a "I made the requested changes" button, on the review... should be ready for another look now though

@edunham edunham closed this May 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.