hello list,
I've been asked to give someone sudo rights across an entire environment without the benefit of something like puppet or chef or cfengine et al.
What I've come up with so far is this:
ssh -t miaprbicsra04v sudo -S /bin/echo "rsherman ALL=(ALL) NOPASSWD: /sbin/service /bin/rm /usr/bin/du /bin/df" >> sudo tee /etc/sudoers
Right now that's just to one host, but I plan on substituting a list of hosts once I get farther along. Problem is, the output hangs on the tee command. Not sure why. Any suggestions?
Thanks, Tim
Tim Dunphy wrote:
hello list,
I've been asked to give someone sudo rights across an entire environment without the benefit of something like puppet or chef or cfengine et al.
What I've come up with so far is this:
ssh -t miaprbicsra04v sudo -S /bin/echo "rsherman ALL=(ALL) NOPASSWD: /sbin/service /bin/rm /usr/bin/du /bin/df" >> sudo tee /etc/sudoers
Bad admin. No coffee for you!
First, I would have listed the above as
ssh -t <whatsit> sudo -S /bin/echo "<username> ALL=(ALL) NOPASSWD: /sbin/service /bin/rm /usr/bin/du /bin/df" >> sudo tee /etc/sudoers
Since doing what you did just told the world a username that they can try to break in with.
Second, sudoers should ALWAYS be edited with visudo, and you might do a here script.... <snip> mark
On Mon, Jul 08, 2013 at 05:02:58PM -0400, m.roth@5-cent.us wrote:
Since doing what you did just told the world a username that they can try to break in with.
Assuming it's internet facing.
Second, sudoers should ALWAYS be edited with visudo, and you might do a here script....
Hardly. If you're using any type of provisioning system with a tested template this type of thing is trivial to do right.
Tim, if you're using C6 look into dropping a properly configured sudo config into /etc/sudoers.d instead of mucking with /etc/sudoers.conf.
John
Assuming it's internet facing.
It's NOT!! Luckily. :) Otherwise he'd be completely right.
Second, sudoers should ALWAYS be edited with visudo, and you might do a here script....
Hardly. If you're using any type of provisioning system with a tested template this type of thing is trivial to do right.
Tim, if you're using C6 look into dropping a properly configured sudo config into /etc/sudoers.d instead of mucking with /etc/sudoers.conf.
Thanks, that'd be my preference. Although it's tough to tell if all sudoers across the environment should be exactly the same. Probably not so I'm attempting to append the file. I've done the original edit in visudo.. not sure if that's enough for me to be confident in the line I'm attempting to add however.
Tim
On Mon, Jul 8, 2013 at 5:17 PM, John R. Dennison jrd@gerdesas.com wrote:
On Mon, Jul 08, 2013 at 05:02:58PM -0400, m.roth@5-cent.us wrote:
Since doing what you did just told the world a username that they can try to break in with.
Assuming it's internet facing.
Second, sudoers should ALWAYS be edited with visudo, and you might do a here script....
Hardly. If you're using any type of provisioning system with a tested template this type of thing is trivial to do right.
Tim, if you're using C6 look into dropping a properly configured sudo config into /etc/sudoers.d instead of mucking with /etc/sudoers.conf.
John-- TURKEY, n. A large bird whose flesh when eaten on certain religious anniversaries has the peculiar property of attesting piety and gratitude. Incidentally, it is pretty good eating.
-- Ambrose Bierce, The Devil's Dictionary
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Am 08.07.2013 um 23:02 schrieb m.roth@5-cent.us:
Tim Dunphy wrote:
hello list,
I've been asked to give someone sudo rights across an entire environment without the benefit of something like puppet or chef or cfengine et al.
What I've come up with so far is this:
ssh -t miaprbicsra04v sudo -S /bin/echo "rsherman ALL=(ALL) NOPASSWD: /sbin/service /bin/rm /usr/bin/du /bin/df" >> sudo tee /etc/sudoers
Bad admin. No coffee for you!
First, I would have listed the above as
ssh -t <whatsit> sudo -S /bin/echo "<username> ALL=(ALL) NOPASSWD: /sbin/service /bin/rm /usr/bin/du /bin/df" >> sudo tee /etc/sudoers
Since doing what you did just told the world a username that they can try to break in with.
Second, sudoers should ALWAYS be edited with visudo, and you might do a here script....
<snip>
also check 'man sudoers' for 'Including other files from within sudoers'
placing an add-on file without touching the dist files to much is my suggested best practice.
-- LF
On 2013-07-08, Leon Fauster leonfauster@googlemail.com wrote:
also check 'man sudoers' for 'Including other files from within sudoers'
For CentOS 5 you will need an up to date sudo from yum or equivalent; earlier versions apparently do not have this functionality.
--keith
You might want to have a look at ansible (www.ansibleworks.com) for orchestration/configuration tasks like this. Very simple to set up and requires nothing but ssh and python on the target host. Takes care of all the ssh and sudo user transitions for you. For your case it would be as simple as.
yum install ansible echo target_host > hosts ansible target_host -i hosts -s -m lineinfile -a 'dest=/etc/sudoers regexp="^username ALL=(ALL) NOPASSWD:"'
replacing target_host and username as appropriate.
You can even package that invocation in a playbook so you don't have to remember all the details next time.
Hope this helps.
K
On 07/08/2013 10:32 PM, Tim Dunphy wrote:
hello list,
I've been asked to give someone sudo rights across an entire environment without the benefit of something like puppet or chef or cfengine et al.
another option is using ldap, so you can specify who can do what in the ldap tree.
The IPA project (included in centos as ipa-server and ipa-client) fixes all this for you:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
Having said this, the question to manage an environment without management tools is peculiar. You need to have a way to introduce changes in a safe, tested, repetitive way. Denying you the possibility of doing this is not best practices and you should point this a a risk in your project.
-
John R. Dennison -
Kahlil Hodgson -
Keith Keller -
Leon Fauster -
m.roth＠5-cent.us -
natxo asenjo -
Tim Dunphy