Hot answers tagged sudoers
You said that you want one particular user to not require a tty. That's the default behavior. Nevertheless, you can explicitly set that like this: Defaults:username !requiretty If you want everyone else to require a tty, then you'll have to uncommment the line.
EDIT thanks to medina's comment: According to the man page, you should be able to write ALL ALL = (ALL) NOPASSWD: ALL to allow all users to run all commands without a password. For reference, I'm leaving my previous answer: If you add a line of the form %wheel ALL = (ALL) NOPASSWD: ALL to /etc/sudoers (using the visudo command, ...
I love the idea of accessing servers via keys, so that I don't have to type in my password every time I ssh into a box, I even lock my user's (not root) password (passwd -l username) so it's impossible to log in without a key...Would you recommend/not recommend doing this for a user account on a server? You're going about disabling ...
I asked this question over on SO and it got moved here. That said I no longer have the ability to edit the question as if I owned it, or even accept the correct answer, but this turned out to be the true reason why and how to solve it: Found here User "rohandhruva" on there gives the right answer: This happens if you change the hostname during the ...
You should never edit your sudoers file directly. Use visudo - it will protect you from these syntax errors in the future. To recover from this situation, either boot into single-user mode and edit the file or boot off of a livecd and do the same.
If you can avoid it, never grant sudo privileges to individual users. Always grant privilegs to a group and then add users to that group. For ubuntu-based servers, instead of adding lines to /etc/sudoers, add config file fragments into /etc/sudoers.d. This is more flexible, easier to understand, more resilient in the face of upgrades, and works better with ...
Why not scrap /etc/sudoers and use AD (LDAP) as your sudoers store? -- More info here. You're already authenticating against AD, so this is just the next logical step, and gives you a convenient, centralized place to handle authentication and authorization.
How about a configuration management tool? Puppet, Chef, CFEngine, etc?
Have you considered a password-less sudo instead?
I tried all the answers on this page, with no useful results. Eventually I figured it out, use this command to list your sudo rights: sudo -l This should give you an output like this: User gmurphy may run the following commands on this host: (root) NOPASSWD: ALL (ALL) ALL It shows that I'm configured with root privileges but that I'm still part ...
Hopefully you are using an EBS root volume. If so, the solution is not too difficult. Essentially, you attach the EBS volume to another instance make the changes, and reattach it to the original instance: Stop (don't terminate) the original instance Detach the EBS volume Launch another instance Attach your current EBS volume to the new instance SSH into ...
This depends on how much access you have given people who use sudo. If you have given people sufficient privilege to enable them to use sudo in an unrestricted manner then you pretty much have to trust them. You can explicitly deny access to the visudo command sudouser ALL=ALL, !/usr/sbin/visudo then $ sudo visudo [sudo] password for sudouser: Sorry, ...
I don't think there is a configuration parameter to do this. You could hack the source code and recompile it. You could also use an alias e.g. alias sudo='sudo -u pedro' but then you'd have to remember to out a \ infront of sudo for anything else \sudo somecommand
Check /etc/sudoers.d/cloud-init file, ec2-user default user is there, just delete this file.
You should be able to do: Cmnd_Alias NOTTYCMDS = /path/to/cmd1, /path/to/cmd2 Defaults!NOTTYCMDS !requiretty
The same commands: who where = (aswhom) NOPASSWD:SETENV: commands The different commands: who where = (aswhom) NOPASSWD: command1, SETENV: command2
sudo works pretty much identically on Solaris as it does on Linux, FreeBSD, AIX, etc. -- The major caveat being that you will need to install it and configure it on Solaris (You can download it here). That website also has extensive documentation on sudo, and if you are unfamiliar with it I would suggest that you invest some time in reading about what sudo ...
I generally restrict use of NOPASSWORD to commands that are run by an automated process. It is preferable to have a service account for these commands, and restrict the use of sudo to the required commands. Allowing NOPASSWORD for general commands, allows anyone who gets access to your userid to run any commands. This could result from a compromise of ...
I just found this little tidbit out there... seems you need to be particularly careful with using the -G option in Ubuntu, in particular in combination -g option. So: Use usermod -aG to add the user(s) to a group. Then as @EEAA suggested, add the group to the /etc/sudoers file using the $ sudovisudo command (automatically invokes a privileged editor ...
Is one of the files/directories it needs to read on a networked mount, or is it somehow triggering reading from a slow usb device? Try strace and see where it's slow; if it goes by too fast, do sudo strace -r -o trace.log sudo echo hi Each line will start with the time taken since entering the previous syscall. (The initial sudo seems to be necessary; I ...
You have two options: You can disable tty requirements by sudo: run visudo and either remove "requiretty" option globally if it is set, or on per-user basis: Defaults:username !requiretty You can force ssh to allocate pseudo-tty: ssh -t -t myuser@$myip "sudo sh" Note the double -t options, both are needed. Moreover, you need to add exit as a last ...
Make sure that no rule below your mentioned rule are overriding it. From man sudoers (1.7.2p2): When multiple entries match for a user, they are applied in order. Where there are multiple matches, the last match is used (which is not necessarily the most specific match).
You might expect that you can do this using Defaults env_keep += "LD_LIBRARY_PATH FRED" but a quick test on a CentOS 6.2 with Sudo version 1.7.4p5 doesn't pass LD_LIBRARY_PATH but does pass FRED. The sudoers man page has this to say Note that the dynamic linker on most operating systems will remove variables that can control dynamic linking from the ...
I don't think that giving the apache user sudo rights would be wise from a security point of view. Have you considered changing the ownership of that file on group level so apache can write to it without the need for sudo?
What version of sudo? Does your version of sudo support using #includedir option to break things out into a fragment directory /etc/sudoers.d/? If so, then I suggest you use that functionality to build your config. Have your main config file delivered to /etc/sudoers that includes all the settings that is common to every host you control. Then have ...
As you can see, your sudoers file contains a line above which includes a number of other files from /etc/sudoers.d. You may be thinking that the hash symbol in front is a comment, but from man sudoers: It is possible to include other sudoers files from within the sudoers file currently being parsed using the #include and #includedir ...
The full path is mandatory, otherwise the unprivileged user could create a new script with the same name at an arbitrary location, completely circumventing the security you're trying to implement.
The absolute last thing I would want to do, is create a separate sudoers file, like Dave suggests. If you have a lot of machines, and only subtle differences apply (as is often the case), you really do not want this. It will generate a lot of overhead. What you really want to do, is create one sudoers file. In that sudoers file, you can then define ...
Step 1. Setup an ldap server and configure all your machines to authenticate users and groups via ldap Step 2. Create a master sudoers group in ldap, say yourcompany-sudoers. Give that group permission to sudo (with password) in the /etc/sudoers file on each machine. Step 3. Create a sudoers-machinename group in ldap, add that group to /etc/sudoers on the ...
Sudo works exactly the same with Solaris as it does with Ubuntu etc so any previous experience you have with it is useful. Solaris does though come with Role Based Access Control (RBAC) which gives you quite fine grained control over what people are alowed to run with elevated privileges. Using sudo or RBAC is preferable to su - as they can be used to log ...
Only top voted, non community-wiki answers of a minimum length are eligible