Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

sudo_root(8) [linux man page]

sudo_root(8)						      System Manager's Manual						      sudo_root(8)

NAME
sudo_root - How to run administrative commands SYNOPSIS
sudo command sudo -i INTRODUCTION
By default, the password for the user "root" (the system administrator) is locked. This means you cannot login as root or use su. Instead, the installer will set up sudo to allow the user that is created during install to run all administrative commands. This means that in the terminal you can use sudo for commands that require root privileges. All programs in the menu will use a graphical sudo to prompt for a password. When sudo asks for a password, it needs your password, this means that a root password is not needed. To run a command which requires root privileges in a terminal, simply prepend sudo in front of it. To get an interactive root shell, use sudo -i. ALLOWING OTHER USERS TO RUN SUDO
By default, only the user who installed the system is permitted to run sudo. To add more administrators, i. e. users who can run sudo, you have to add these users to the group 'admin' by doing one of the following steps: * In a shell, do sudo adduser username admin * Use the graphical "Users & Groups" program in the "System settings" menu to add the new user to the admin group. BENEFITS OF USING SUDO
The benefits of leaving root disabled by default include the following: * Users do not have to remember an extra password, which they are likely to forget. * The installer is able to ask fewer questions. * It avoids the "I can do anything" interactive login by default - you will be prompted for a password before major changes can happen, which should make you think about the consequences of what you are doing. * Sudo adds a log entry of the command(s) run (in /var/log/auth.log). * Every attacker trying to brute-force their way into your box will know it has an account named root and will try that first. What they do not know is what the usernames of your other users are. * Allows easy transfer for admin rights, in a short term or long term period, by adding and removing users from the admin group, while not compromising the root account. * sudo can be set up with a much more fine-grained security policy. * On systems with more than one administrator using sudo avoids sharing a password amongst them. DOWNSIDES OF USING SUDO
Although for desktops the benefits of using sudo are great, there are possible issues which need to be noted: * Redirecting the output of commands run with sudo can be confusing at first. For instance consider sudo ls > /root/somefile will not work since it is the shell that tries to write to that file. You can use ls | sudo tee /root/somefile to get the behaviour you want. * In a lot of office environments the ONLY local user on a system is root. All other users are imported using NSS techniques such as nss-ldap. To setup a workstation, or fix it, in the case of a network failure where nss-ldap is broken, root is required. This tends to leave the system unusable. An extra local user, or an enabled root password is needed here. GOING BACK TO A TRADITIONAL ROOT ACCOUNT
This is not recommended! To enable the root account (i.e. set a password) use: sudo passwd root Afterwards, edit the sudo configuration with sudo visudo and comment out the line %admin ALL=(ALL) ALL to disable sudo access to members of the admin group. SEE ALSO
sudo(8), https://wiki.ubuntu.com/RootSudo February 8, 2006 sudo_root(8)

Check Out this Related Man Page

pam_ssh_agent_auth(8)							PAM						     pam_ssh_agent_auth(8)

PAM_SSH_AGENT_AUTH
       This module provides authentication via ssh-agent.  If an ssh-agent listening at SSH_AUTH_SOCK can successfully authenticate that it has
       the secret key for a public key in the specified file, authentication is granted, otherwise authentication fails.

SUMMARY
/etc/pam.d/sudo: auth sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys /etc/sudoers: Defaults env_keep += "SSH_AUTH_SOCK" This configuration would permit anyone who has an SSH_AUTH_SOCK that manages the private key matching a public key in /etc/security/authorized_keys to execute sudo without having to enter a password. Note that the ssh-agent listening to SSH_AUTH_SOCK can either be local, or forwarded. Unlike NOPASSWD, this still requires an authentication, it's just that the authentication is provided by ssh-agent, and not password entry. ARGUMENTS
file=<path to authorized_keys> Specify the path to the authorized_keys file(s) you would like to use for authentication. Subject to tilde and % EXPANSIONS (below) allow_user_owned_authorized_keys_file A flag which enables authorized_keys files to be owned by the invoking user, instead of root. This flag is enabled automatically whenever the expansions %h or ~ are used. debug A flag which enables verbose logging sudo_service_name=<service name you compiled sudo to use> (when compiled with --enable-sudo-hack) Specify the service name to use to identify the service "sudo". When the PAM_SERVICE identifier matches this string, and if PAM_RUSER is not set, pam_ssh_agent_auth will attempt to identify the calling user from the environment variable SUDO_USER. This defaults to "sudo". EXPANSIONS
~ -- same as in shells, a user's Home directory Automatically enables allow_user_owned_authorized_keys_file if used in the context of ~/. If used as ~user/, it would expect the file to be owned by 'user', unless you explicitely set allow_user_owned_authorized_keys_file %h -- User's Home directory Automatically enables allow_user_owned_authorized_keys_file %H -- The short-hostname %u -- Username %f -- FQDN EXAMPLES
in /etc/pam.d/sudo "auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys" The default .ssh/authorized_keys file in a user's home-directory "auth sufficient pam_ssh_agent_auth.so file=%h/.ssh/authorized_keys" Same as above. "auth sufficient pam_ssh_agent_auth.so file=~fred/.ssh/authorized_keys" If the home-directory of user 'fred' was /home/fred, this would expand to /home/fred/.ssh/authorized_keys. In this case, we have not specified allow_user_owned_authorized_keys_file, so this file must be owned by 'fred'. "auth sufficient pam_ssh_agent_auth.so file=/secure/%H/%u/authorized_keys allow_user_owned_authorized_keys_file" On a host named foobar.baz.com, and a user named fred, would expand to /secure/foobar/fred/authorized_keys. In this case, we specified allow_user_owned_authorized_keys_file, so fred would be able to manage that authorized_keys file himself. "auth sufficient pam_ssh_agent_auth.so file=/secure/%f/%u/authorized_keys" On a host named foobar.baz.com, and a user named fred, would expand to /secure/foobar.baz.com/fred/authorized_keys. In this case, we have not specified allow_user_owned_authorized_keys_file, so this file must be owned by root. v0.8 2009-08-09 pam_ssh_agent_auth(8)
Man Page