Since I occasionally use my Pi over SSH, I have learned that it is dangerous to allow SSH to access sudo commands. Thus, I plan to turn off this permission in the near future. But, when I install packages I usually have to reboot. Currently, this is only allowed through the superuser.
sudo reboot
Is there any way that I can edit the permissions of the pi user to allow it to reboot (and install) packages?
Could I have multiple accounts with different permissions?
Thanks
To clarify a bit: There are no "sudo commands", there are only commands that need root privileges to operate correctly and sudo is the command to obtain them for one command: sudo simply runs the given command as root (read "sudo" as the imperative sentence "superuser, do something!"). The rules about which users may do this are written down in /etc/sudoers. On a default Raspbian installation, the default user "pi" has got his permissions from this line:
pi ALL=(ALL) NOPASSWD: ALL
It means: "The user 'pi' on ALL hosts is allowed to switch to ALL users and does NOt have to type his PASSWD when using ALL (read: any) commands". (I used crazy grammar here to retain the order of the line .. a note on why there's a way to distinguish hosts: this way, the same sudoers file can be distributed to multiple machines on a network so the network admin has less work).
It may be that being able to run commands using sudo without issuing an admin password is the point why you think it to be dangerous to use sudo over SSH (I haven't heard of a general problem with doing that ... so could you explain what danger exactly you mean?).
Sure you could have multiple users with different permissions. But I'm afraid that using sudo still is the best way to manage these permissions.
So, I hope this small recipe here is what you need:
$ sudo adduser admin
This will create a user "admin", ask for a password, create his home directory, etc.
$ sudo adduser admin sudo
$ sudo adduser admin adm
This will put the "admin" user into the usergroups "sudo" and "adm". And since permissions are managed in Linux by adding users to usergroups, this gives the "admin" user all privileges and permissions he needs. There is a line in /etc/sudoers that allows any user that is in the usergroup "sudo" to execute any command as root; and this privilege is what we need for an admin user (adding him to "adm" allows him to read some log files in /var/log without using sudo and a few other things). You still need to use sudo when you're logged in as admin -- but now sudo asks again and again for the admin's password whenever you did not use sudo for about five minutes.
Now log off and log on as the user "admin". Check whether
$ sudo apt-get update
$ sudo apt-get upgrade
works. If it does, you may revoke some privileges of the "pi" user, because you are now sure that your admin user has the right privileges:
$ sudo deluser pi sudo
$ sudo deluser pi adm
This throws the user "pi" out of the usergroup "sudo".
$ sudo visudo
This will start an editor that allows you to edit /etc/sudoers. Put a hash tag (#) before the line starting with "pi", commenting it out (or simply remove it). Then save and exit the editor, visudo will then re-load the privilege rules immediately. Now the user "pi" is not allowed to use sudo anymore.
After that, you may re-logon as the user "pi". If you ever want to switch over to the admin for some commands, use su ("switch user"):
$ su - admin
If you want to add more users: use sudo adduser <name> like above, then check the list of usergroups the user "pi" has got:
$ groups pi
pi : pi dialout cdrom audio video plugdev games users netdev input
Use sudo adduser <username> <groupname> to add your new user to several of these usergroups, enabling him to use audio, accelerated video, use pluggable devices, etc. If unsure, add him to all of these usergroups (but not to "sudo"!).
visudo is a command that will use your default editor to edit the sudoers file. Editing this file without it can be a pain and is not recommended. You can change your preferred editor by issuing sudo update-alternatives --config editor
Commented
May 20, 2013 at 23:38
VISUAL=vim visudo for just this time. But great example of changing default programs, like editor.
Yes, you can configure sudo to only allow the user to run certain commands with additional privileges. You can changed this in your /etc/sudoers file, but it's advisable not to do this directly but use sudo visudo command for this.
In default system installation you should find such line:
pi ALL=(ALL) NOPASSWD: ALL
It tells sudo to allow user pi to run all cammands as root user without even providing password. You can change last ALL and specify comma delimited list of commands (with their full path) allowed to run. In your case you should change this line to:
pi ALL=(ALL) NOPASSWD: /usr/bin/apt-get, /sbin/shutdown
Note that there is one more line in sudoers affecting pi user:
%sudo ALL=(ALL:ALL) ALL
This line let all users in group sudo (% character in front of the name means it's a group name instead of user name) run ALL passwords providing they know their OWN password. If you leave this line, user pi will be able to run all other commands but will be asked for his password.
If you want to prevent this from happening you can either remove this line or remove user pi from sudo group.
After making changes to /etc/sudoers file you may want to inspect that it really does what you want by calling sudo -l -U pi command.
Of course you can create different accounts and configure sudoers giving them access to different commands.
May 2018, This is still acccurate in concept but the procedure has changed with later versions:
Firstly, the files should be directly edited in vi or nano or leafpad or emacs - whichever is your favorite text editor.
The username pi is not mentioned in this file:
/etc/sudoers
and the last line of the file is this:
#includedir /etc/sudoers.d
This is a directory that contains a file named
010_pi-nopasswd
that contains this single line
pi ALL=(ALL) NOPASSWD: ALL
Which has the effect of not prompting for any sudo command as long as I am logged in as user pi. (note the syntax has to be exactly this way)
This is great.
The group line %sudo ALL=(ALL:ALL) ALL is still there as
So to answer the first part of the question:
When I moved the file /etc/sudoers/sudoers.d/010_pi-nopasswd file up one directory level to make the include fail, then waited 15 minutes, it caused my Raspbian system to prompt for my own password upon use of sudo, just like my Ubuntu 14.04 LTS system used to do.
Then when I moved it back where it belongs, even after 10 minutes it no longer prompted me.
No reboot necessary. Voila, no prompting for a password when using sudo
My lubuntu 14.04 LTS test system has the same setup except that the 010_pi-nopasswd file was not present. lubuntu was installed with pi as the root user. It prompted me for each time I used sudo, then didn't prompt me for 10 minutes afterwards.
I added this same file to the Ubuntu system just like the way Raspbian is set up, (remember to chmod 0440 on this file while you still are in that 10-minute window) - and
Voila, it no longer prompts me for my own password when I am logged in as pi even after 15 minutes.
Again, the change happens instantly with no reboot necessary.
This is the May 2018 answer for how to disable and enable the prompting for the use of the sudo command when logged in as root user pi. Other users and groups can be configured in this same fashion.
--UPDATE for Ubuntu 16.04 LTS
This system is very similar also. However, the biggest difference is that 16.04 has much tighter file permissions so the work must be done in su mode. If you have forgotten your root password you can reset it from your normal prompt by using sudo passwd root Then the su command will work and you can go from there.
sudoers is usually done at the time the user is created. Use Example: You'll note that the common command string sudo apt-get update && sudo apt-get upgrade invokes sudo twice yet is annoying that it might stop and ask for the password again before the upgrade. So I set mine to never prompt my one login name (pi) and also then use sudo apt-get update -y && sudo apt-get upgrade -y so it likewise won't stop to ask for the OK to make sizable changes. To make it more Unix-like. Just do what I ask, and even if I walk away I want it finished.
#includedir (which looks like a comment :-)) I cannot accept your statement "the files should be directly edited in ..." - please clarify (is there a not missing?)
Just an alternative to what scruss said, delete the /etc/sudoers.d/010_pi-nopasswd file by running sudo rm /etc/sudoers.d/010_pi-nopasswd. Much easier and safer then editing the main sudoers file, which can break sudo.
It's safer to allow sudo access through SSH than allow any user to install packages. If you're really worried about it, change the line it /etc/sudoers from:
pi ALL=(ALL) NOPASSWD: ALL
to
pi ALL=(ALL) PASSWD: ALL
That means you'll get prompted for a password the first time you use sudo in any session, and again after a few minutes' timeout. You can't edit /etc/sudoers directly; use sudo visudo to do so.
Looks like Krzysztof hopped in with an answer just there. Are you really sure you need to reboot every time you install new packages? Unless you're installing a new kernel or firmware, not much else needs a reboot. This is a quality OS we've got here ...
timestamp timeout is a good idea. It's 15 minutes by default, BTW. Note that PASSWD is default (if NOPASSWD wasn't specified earlier in this command list). Also note that /etc/sudoers can be edited directly without problems if you know what you are doing. Using visudo makes changes in temporary file preventing the file to be auto written in the middle of the change (which could introduce syntax errors and/or security problems), it locks this file against multiple simultaneous edits and does some syntax checks before writing the file.
Commented
Apr 21, 2013 at 20:28
In my experience, you don’t need sudo permissions to reboot. You do, however, need to if there are multiple users logged into the system.
Or you could, as mentioned above, just set the root password to something really long, and just use su. The risk there is that someone could get direct access to the root user by brute-forcing it using something like hydra.
