Skip to content

Feature/security#58

Merged
swalkinshaw merged 1 commit intoroots:masterfrom
FightTheCurrent:feature/security
Nov 20, 2014
Merged

Feature/security#58
swalkinshaw merged 1 commit intoroots:masterfrom
FightTheCurrent:feature/security

Conversation

@nathanielks
Copy link
Contributor

No description provided.

@nathanielks
Copy link
Contributor Author

Alrighty, have a few things to work out. In the latest commit, c73a4a5, I had to allow root access in /etc/ssh/sshd_config in order for ansible to continue to be able to provision the server. Do we want to create another user that has sudo access and restrict root ssh login? deploy perhaps? Or continue to allow root ssh login?

@swalkinshaw
Copy link
Member

root ssh access should definitely be disabled in production. I'm not sure the "general" user should be deploy (it should still exist but just for deploys). We could go with the common ubuntu that services like AWS use or something generic like web. Not really sure if there's a more standard user name for this purpose.

@austinpray
Copy link
Contributor

something generic like web

This sounds good

We could go with the common ubuntu

Ehh not great for folks that like to use Debian

@nathanielks
Copy link
Contributor Author

hrm... my only problem with web is that does it really describe the user's purpose. How about admin? It'll be a user with sudo privileges, so that makes a little more sense to me.

@swalkinshaw
Copy link
Member

👍 to admin

@nathanielks
Copy link
Contributor Author

Done and done.

@austinpray
Copy link
Contributor

brilliant

@nathanielks
Copy link
Contributor Author

I'm starting to write the documentation for the README and am realizing it's getting pretty huge. Should I continue writing the documentation in the README file, or write it in a separate readme, like SECURE-ROOT.md or perhaps a wiki?

@nathanielks
Copy link
Contributor Author

After second thought, maybe not. The other roles I'd be writing documentation for already have readme's in their role directories. How do we want to let the user know they exist?

@austinpray
Copy link
Contributor

You can link them up with relative links. 

I have never seen a well maintained wiki on GH, it seems they always fall behind. 

Sent from my iPhone

On Tue, Sep 23, 2014 at 8:17 PM, Nathaniel notifications@github.com
wrote:

After second thought, maybe not. The other roles I'd be writing documentation for already have readme's in their role directories. How do we want to let the user know they exist?

Reply to this email directly or view it on GitHub:
#58 (comment)

@mAAdhaTTah
Copy link
Contributor

Would it be possible to set the general user via a variable (like with the MySQL root pw) or does it have to be hard-coded somewhere?

@nathanielks
Copy link
Contributor Author

@swalkinshaw The admin users are set up using 2 different variables: sudoers and sudoer_passwords. More in the documentation

@swalkinshaw
Copy link
Member

@nathanielks this is looking great. Finally got a chance to look over the READMEs. Just going to try and do some basic testing of this before merging it in since it's big.

@nathanielks
Copy link
Contributor Author

NP @swalkinshaw!

@mAAdhaTTah
Copy link
Contributor

Is this PR good to go? Does it need more testing? I'm going to be provisioning some things tonight so wondering if I can help w/ this.

@swalkinshaw
Copy link
Member

More testing mainly so any help with that would be great.

@nathanielks could we get a rebase on this?

@nathanielks
Copy link
Contributor Author

I sure hope so @mAAdhaTTah! I'll need to squash everything before we merge, but afaik it should be ok.

@nathanielks
Copy link
Contributor Author

yup, I'll get that done now.

@nathanielks
Copy link
Contributor Author

Okie doke. Rebasing is all done. Once I get the 👍 I'll squash! I did a quick provision on a vanilla server and everything seems to be checking out. Test away @mAAdhaTTah!

@mAAdhaTTah
Copy link
Contributor

Don't know if this is a huge deal, but in the hosts/production file, ansible_ssh_user=admin needs to be removed when running the initial secure-root.yml playbook.

@nathanielks
Copy link
Contributor Author

@mAAdhaTTah aye, you're right. Looking into that.

@mAAdhaTTah
Copy link
Contributor

I think I have a solution. Gimme a few to test.

@nathanielks
Copy link
Contributor Author

The one I'm pursuing is defining the user in the playbooks as opposed to the inventory files. Vagrant disregards the remote user, so in this case I think we'd be good to go.

Was that what you were thinking?

@mAAdhaTTah
Copy link
Contributor

Yup! Got it working for me too.

@mAAdhaTTah
Copy link
Contributor

FWIW, I had to add remote_user: admin to both plays in the site.yml playbook.

@mAAdhaTTah
Copy link
Contributor

This looks like the changes I made. I'll pull down and do one more test, but otherwise, 👍

@nathanielks
Copy link
Contributor Author

sweet!

@mAAdhaTTah
Copy link
Contributor

👍

@nathanielks
Copy link
Contributor Author

Squashed and ready to go.

swalkinshaw added a commit that referenced this pull request Nov 20, 2014
@swalkinshaw swalkinshaw merged commit e604949 into roots:master Nov 20, 2014
@nathanielks nathanielks deleted the feature/security branch November 20, 2014 18:51
@mAAdhaTTah
Copy link
Contributor

WOO!

@austinpray
Copy link
Contributor

yall are ballers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants