How to run sudo command with no password?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







220















How does the ubuntu user on the AWS images for Ubuntu Server 12.04 have passwordless sudo for all commands when there is no configuration for it in /etc/sudoers?



I'm using Ubuntu server 12.04 on Amazon. I want to add a new user that has the same behavior as the default Ubuntu user. Specifically I want passwordless sudo for this new user.



So I've added a new user and went to edit /etc/sudoers (using visudo of course). From reading that file it seemed like the default ubuntu user was getting it's passwordless sudo from being a member of the admin group. So I added my new user to that. Which didn't work. Then I tried adding the NOPASSWD directive to sudoers. Which also didn't work.



Anyway, now I'm just curious. How does the ubuntu user get passwordless privileges if they aren't defined in /etc/sudoers. What is the mechanism that allows this?










share|improve this question

























  • Related: Execute sudo without Password?

    – Eliah Kagan
    Jul 26 '17 at 7:12


















220















How does the ubuntu user on the AWS images for Ubuntu Server 12.04 have passwordless sudo for all commands when there is no configuration for it in /etc/sudoers?



I'm using Ubuntu server 12.04 on Amazon. I want to add a new user that has the same behavior as the default Ubuntu user. Specifically I want passwordless sudo for this new user.



So I've added a new user and went to edit /etc/sudoers (using visudo of course). From reading that file it seemed like the default ubuntu user was getting it's passwordless sudo from being a member of the admin group. So I added my new user to that. Which didn't work. Then I tried adding the NOPASSWD directive to sudoers. Which also didn't work.



Anyway, now I'm just curious. How does the ubuntu user get passwordless privileges if they aren't defined in /etc/sudoers. What is the mechanism that allows this?










share|improve this question

























  • Related: Execute sudo without Password?

    – Eliah Kagan
    Jul 26 '17 at 7:12














220












220








220


82






How does the ubuntu user on the AWS images for Ubuntu Server 12.04 have passwordless sudo for all commands when there is no configuration for it in /etc/sudoers?



I'm using Ubuntu server 12.04 on Amazon. I want to add a new user that has the same behavior as the default Ubuntu user. Specifically I want passwordless sudo for this new user.



So I've added a new user and went to edit /etc/sudoers (using visudo of course). From reading that file it seemed like the default ubuntu user was getting it's passwordless sudo from being a member of the admin group. So I added my new user to that. Which didn't work. Then I tried adding the NOPASSWD directive to sudoers. Which also didn't work.



Anyway, now I'm just curious. How does the ubuntu user get passwordless privileges if they aren't defined in /etc/sudoers. What is the mechanism that allows this?










share|improve this question
















How does the ubuntu user on the AWS images for Ubuntu Server 12.04 have passwordless sudo for all commands when there is no configuration for it in /etc/sudoers?



I'm using Ubuntu server 12.04 on Amazon. I want to add a new user that has the same behavior as the default Ubuntu user. Specifically I want passwordless sudo for this new user.



So I've added a new user and went to edit /etc/sudoers (using visudo of course). From reading that file it seemed like the default ubuntu user was getting it's passwordless sudo from being a member of the admin group. So I added my new user to that. Which didn't work. Then I tried adding the NOPASSWD directive to sudoers. Which also didn't work.



Anyway, now I'm just curious. How does the ubuntu user get passwordless privileges if they aren't defined in /etc/sudoers. What is the mechanism that allows this?







sudo aws






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 12 '12 at 15:02









Peachy

5,10672843




5,10672843










asked Sep 23 '12 at 9:30









aychedeeaychedee

5,08731513




5,08731513













  • Related: Execute sudo without Password?

    – Eliah Kagan
    Jul 26 '17 at 7:12



















  • Related: Execute sudo without Password?

    – Eliah Kagan
    Jul 26 '17 at 7:12

















Related: Execute sudo without Password?

– Eliah Kagan
Jul 26 '17 at 7:12





Related: Execute sudo without Password?

– Eliah Kagan
Jul 26 '17 at 7:12










4 Answers
4






active

oldest

votes


















314














Okay, I have discovered the answer so may as well put it here for completeness. At the end of /etc/sudoers there is what I thought was just a comment:



#includedir /etc/sudoers.d


However this actually includes the contents of that directory. Inside of which is the file
/etc/sudoers.d/90-cloudimg-ubuntu. Which has the expected contents



# ubuntu user is default user in cloud-images.
# It needs passwordless sudo functionality.
ubuntu ALL=(ALL) NOPASSWD:ALL


So that is where the sudo configuration for the default ubuntu user lives.



You should edit this file using visudo. The following command will let you edit the correct file with visudo.



sudo visudo -f /etc/sudoers.d/90-cloudimg-ubuntu


And add a line like:



aychedee ALL=(ALL) NOPASSWD:ALL


At the end.






share|improve this answer





















  • 3





    I'm pretty sure I had to do a full reboot.

    – aychedee
    Feb 14 '13 at 20:40






  • 2





    new sudo rules will be used for every new logged user - so you need re login at least

    – bluszcz
    Feb 27 '13 at 10:17






  • 30





    'sudo service sudo restart' works :)

    – Laice
    Jun 11 '13 at 2:23








  • 4





    In later versions (14.04 for example) the included file is /etc/sudoers.d/90-cloud-init-users (so to edit.. sudo visudo -f /etc/sudoers.d/90-cloud-init-users). Although it'd be cleaner to create additional files than editing the generated one. Note that files containing a . or ending in ~ will not be included.

    – Molomby
    Aug 27 '15 at 5:29






  • 2





    @Phil_1984_ Most likely, it was added as a comment to allow compatibility with other (standard?) versions of sudo, which don't allow includes, but wouldn't be tripped up by a weird comment. (Standards are hard! ;-)

    – jpaugh
    Nov 23 '16 at 14:39





















88














I found that the most straight forward thing to do, in order to easily replicate this behavior across multiple servers, was the following:



sudo visudo


Change this line:



# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL


to this line:



# Members of the admin group may gain root privileges
%admin ALL=(ALL) NOPASSWD:ALL


And move it under this line:



# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL


you should now have this:



# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#

Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) NOPASSWD:ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d


then for every user that needs sudo access WITH a password:



sudo adduser <user> sudo


and for every user that needs sudo access WITH NO password:



sudo adduser <user> admin


and finally, run this:



sudo service sudo restart


And that's it!



Edit: You may have to add the admin group as I don't think it exists by default.



sudo groupadd admin


You can also add the default AWS ubuntu user to the admin group via this command:



sudo usermod ubuntu -g admin


Note: As @hata mentioned, you may need to use adm as your admin group name, depending on which version of Ubuntu is being used.






share|improve this answer





















  • 3





    Note to self: It's a convention to move less restrictive permissions lower in the stack. But not doing it won't affect functionality.

    – poweratom
    Sep 5 '14 at 9:47






  • 2





    As jiminikiz explained, I had to place the %admin after the %sudo on my Ubuntu GNOME 16.04 LTS. Plus, the administrators group id is exactly not admin but adm on my Ubuntu. No reboot was required.

    – hata
    Oct 26 '17 at 10:52





















2














I would create my own file under /etc/sudoers.d/ directory - the file created by Amazon Cloud might be overwritten in case of any update. After creating your file in /etc/sudoers.d, add this entry,



<your user name> ALL=(ALL) NOPASSWD:ALL


Reboot the system and this will work.






share|improve this answer































    1














    Short answer without using any editor (tested on bash, very risky to execute on remote hosts).



    Configure sudo to work without a password for the current user:



    echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers


    Check the edit with:



    sudo visudo -c


    Verify if you can use sudo without a password:



    sudo cat /etc/sudoers | grep "$USER"


    ...or simply try it with:



    sudo <anything>





    share|improve this answer





















    • 21





      This is pretty dangerous advice... copy and paste this wrong and you'll lock yourself out of your own server. Hence the advice to use visudo. It checks that the syntax is correct before saving to disk. So, for anyone that wants to use this. Don't do it on a remote server that you care about. You might want to include a warning about that in your answer.

      – aychedee
      Aug 14 '14 at 9:25








    • 8





      Not using visudo is a horrible idea. Trust me, I know.

      – trognanders
      Sep 9 '15 at 17:22






    • 1





      IMHO, a copy-paste is safer than a manual edit. A minor simplification: echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers

      – theartofrain
      Apr 5 '16 at 23:56








    • 4





      @theartofrain - Normally, I'd agree, but visudo is particularly nice about not allowing you to break the sudoers file, thus not locking you out of your machine (or at least sudo).

      – Jon V
      Mar 15 '17 at 2:43






    • 3





      @JonV You can lose admin rights via visudo too, but usually not by accident, because visudo only saves changes that are well-formed according to the grammar for sudoers files. Most mistakes are syntactically wrong, so they cause no harm with visudo. If /etc/sudoers or a file in /etc/sudoers.d is ill-formed, sudo refuses to elevate privileges for anyone as a security measure, which is why not using visudo is dangerous. (Though sometimes pkexec can fix it without a reboot.)

      – Eliah Kagan
      Sep 28 '17 at 12:29












    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "89"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f192050%2fhow-to-run-sudo-command-with-no-password%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    314














    Okay, I have discovered the answer so may as well put it here for completeness. At the end of /etc/sudoers there is what I thought was just a comment:



    #includedir /etc/sudoers.d


    However this actually includes the contents of that directory. Inside of which is the file
    /etc/sudoers.d/90-cloudimg-ubuntu. Which has the expected contents



    # ubuntu user is default user in cloud-images.
    # It needs passwordless sudo functionality.
    ubuntu ALL=(ALL) NOPASSWD:ALL


    So that is where the sudo configuration for the default ubuntu user lives.



    You should edit this file using visudo. The following command will let you edit the correct file with visudo.



    sudo visudo -f /etc/sudoers.d/90-cloudimg-ubuntu


    And add a line like:



    aychedee ALL=(ALL) NOPASSWD:ALL


    At the end.






    share|improve this answer





















    • 3





      I'm pretty sure I had to do a full reboot.

      – aychedee
      Feb 14 '13 at 20:40






    • 2





      new sudo rules will be used for every new logged user - so you need re login at least

      – bluszcz
      Feb 27 '13 at 10:17






    • 30





      'sudo service sudo restart' works :)

      – Laice
      Jun 11 '13 at 2:23








    • 4





      In later versions (14.04 for example) the included file is /etc/sudoers.d/90-cloud-init-users (so to edit.. sudo visudo -f /etc/sudoers.d/90-cloud-init-users). Although it'd be cleaner to create additional files than editing the generated one. Note that files containing a . or ending in ~ will not be included.

      – Molomby
      Aug 27 '15 at 5:29






    • 2





      @Phil_1984_ Most likely, it was added as a comment to allow compatibility with other (standard?) versions of sudo, which don't allow includes, but wouldn't be tripped up by a weird comment. (Standards are hard! ;-)

      – jpaugh
      Nov 23 '16 at 14:39


















    314














    Okay, I have discovered the answer so may as well put it here for completeness. At the end of /etc/sudoers there is what I thought was just a comment:



    #includedir /etc/sudoers.d


    However this actually includes the contents of that directory. Inside of which is the file
    /etc/sudoers.d/90-cloudimg-ubuntu. Which has the expected contents



    # ubuntu user is default user in cloud-images.
    # It needs passwordless sudo functionality.
    ubuntu ALL=(ALL) NOPASSWD:ALL


    So that is where the sudo configuration for the default ubuntu user lives.



    You should edit this file using visudo. The following command will let you edit the correct file with visudo.



    sudo visudo -f /etc/sudoers.d/90-cloudimg-ubuntu


    And add a line like:



    aychedee ALL=(ALL) NOPASSWD:ALL


    At the end.






    share|improve this answer





















    • 3





      I'm pretty sure I had to do a full reboot.

      – aychedee
      Feb 14 '13 at 20:40






    • 2





      new sudo rules will be used for every new logged user - so you need re login at least

      – bluszcz
      Feb 27 '13 at 10:17






    • 30





      'sudo service sudo restart' works :)

      – Laice
      Jun 11 '13 at 2:23








    • 4





      In later versions (14.04 for example) the included file is /etc/sudoers.d/90-cloud-init-users (so to edit.. sudo visudo -f /etc/sudoers.d/90-cloud-init-users). Although it'd be cleaner to create additional files than editing the generated one. Note that files containing a . or ending in ~ will not be included.

      – Molomby
      Aug 27 '15 at 5:29






    • 2





      @Phil_1984_ Most likely, it was added as a comment to allow compatibility with other (standard?) versions of sudo, which don't allow includes, but wouldn't be tripped up by a weird comment. (Standards are hard! ;-)

      – jpaugh
      Nov 23 '16 at 14:39
















    314












    314








    314







    Okay, I have discovered the answer so may as well put it here for completeness. At the end of /etc/sudoers there is what I thought was just a comment:



    #includedir /etc/sudoers.d


    However this actually includes the contents of that directory. Inside of which is the file
    /etc/sudoers.d/90-cloudimg-ubuntu. Which has the expected contents



    # ubuntu user is default user in cloud-images.
    # It needs passwordless sudo functionality.
    ubuntu ALL=(ALL) NOPASSWD:ALL


    So that is where the sudo configuration for the default ubuntu user lives.



    You should edit this file using visudo. The following command will let you edit the correct file with visudo.



    sudo visudo -f /etc/sudoers.d/90-cloudimg-ubuntu


    And add a line like:



    aychedee ALL=(ALL) NOPASSWD:ALL


    At the end.






    share|improve this answer















    Okay, I have discovered the answer so may as well put it here for completeness. At the end of /etc/sudoers there is what I thought was just a comment:



    #includedir /etc/sudoers.d


    However this actually includes the contents of that directory. Inside of which is the file
    /etc/sudoers.d/90-cloudimg-ubuntu. Which has the expected contents



    # ubuntu user is default user in cloud-images.
    # It needs passwordless sudo functionality.
    ubuntu ALL=(ALL) NOPASSWD:ALL


    So that is where the sudo configuration for the default ubuntu user lives.



    You should edit this file using visudo. The following command will let you edit the correct file with visudo.



    sudo visudo -f /etc/sudoers.d/90-cloudimg-ubuntu


    And add a line like:



    aychedee ALL=(ALL) NOPASSWD:ALL


    At the end.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 7 '14 at 10:01

























    answered Sep 23 '12 at 10:27









    aychedeeaychedee

    5,08731513




    5,08731513








    • 3





      I'm pretty sure I had to do a full reboot.

      – aychedee
      Feb 14 '13 at 20:40






    • 2





      new sudo rules will be used for every new logged user - so you need re login at least

      – bluszcz
      Feb 27 '13 at 10:17






    • 30





      'sudo service sudo restart' works :)

      – Laice
      Jun 11 '13 at 2:23








    • 4





      In later versions (14.04 for example) the included file is /etc/sudoers.d/90-cloud-init-users (so to edit.. sudo visudo -f /etc/sudoers.d/90-cloud-init-users). Although it'd be cleaner to create additional files than editing the generated one. Note that files containing a . or ending in ~ will not be included.

      – Molomby
      Aug 27 '15 at 5:29






    • 2





      @Phil_1984_ Most likely, it was added as a comment to allow compatibility with other (standard?) versions of sudo, which don't allow includes, but wouldn't be tripped up by a weird comment. (Standards are hard! ;-)

      – jpaugh
      Nov 23 '16 at 14:39
















    • 3





      I'm pretty sure I had to do a full reboot.

      – aychedee
      Feb 14 '13 at 20:40






    • 2





      new sudo rules will be used for every new logged user - so you need re login at least

      – bluszcz
      Feb 27 '13 at 10:17






    • 30





      'sudo service sudo restart' works :)

      – Laice
      Jun 11 '13 at 2:23








    • 4





      In later versions (14.04 for example) the included file is /etc/sudoers.d/90-cloud-init-users (so to edit.. sudo visudo -f /etc/sudoers.d/90-cloud-init-users). Although it'd be cleaner to create additional files than editing the generated one. Note that files containing a . or ending in ~ will not be included.

      – Molomby
      Aug 27 '15 at 5:29






    • 2





      @Phil_1984_ Most likely, it was added as a comment to allow compatibility with other (standard?) versions of sudo, which don't allow includes, but wouldn't be tripped up by a weird comment. (Standards are hard! ;-)

      – jpaugh
      Nov 23 '16 at 14:39










    3




    3





    I'm pretty sure I had to do a full reboot.

    – aychedee
    Feb 14 '13 at 20:40





    I'm pretty sure I had to do a full reboot.

    – aychedee
    Feb 14 '13 at 20:40




    2




    2





    new sudo rules will be used for every new logged user - so you need re login at least

    – bluszcz
    Feb 27 '13 at 10:17





    new sudo rules will be used for every new logged user - so you need re login at least

    – bluszcz
    Feb 27 '13 at 10:17




    30




    30





    'sudo service sudo restart' works :)

    – Laice
    Jun 11 '13 at 2:23







    'sudo service sudo restart' works :)

    – Laice
    Jun 11 '13 at 2:23






    4




    4





    In later versions (14.04 for example) the included file is /etc/sudoers.d/90-cloud-init-users (so to edit.. sudo visudo -f /etc/sudoers.d/90-cloud-init-users). Although it'd be cleaner to create additional files than editing the generated one. Note that files containing a . or ending in ~ will not be included.

    – Molomby
    Aug 27 '15 at 5:29





    In later versions (14.04 for example) the included file is /etc/sudoers.d/90-cloud-init-users (so to edit.. sudo visudo -f /etc/sudoers.d/90-cloud-init-users). Although it'd be cleaner to create additional files than editing the generated one. Note that files containing a . or ending in ~ will not be included.

    – Molomby
    Aug 27 '15 at 5:29




    2




    2





    @Phil_1984_ Most likely, it was added as a comment to allow compatibility with other (standard?) versions of sudo, which don't allow includes, but wouldn't be tripped up by a weird comment. (Standards are hard! ;-)

    – jpaugh
    Nov 23 '16 at 14:39







    @Phil_1984_ Most likely, it was added as a comment to allow compatibility with other (standard?) versions of sudo, which don't allow includes, but wouldn't be tripped up by a weird comment. (Standards are hard! ;-)

    – jpaugh
    Nov 23 '16 at 14:39















    88














    I found that the most straight forward thing to do, in order to easily replicate this behavior across multiple servers, was the following:



    sudo visudo


    Change this line:



    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) ALL


    to this line:



    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) NOPASSWD:ALL


    And move it under this line:



    # Allow members of group sudo to execute any command
    %sudo ALL=(ALL:ALL) ALL


    you should now have this:



    # This file MUST be edited with the 'visudo' command as root.
    #
    # Please consider adding local content in /etc/sudoers.d/ instead of
    # directly modifying this file.
    #
    # See the man page for details on how to write a sudoers file.
    #

    Defaults env_reset
    Defaults mail_badpass
    Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

    # Host alias specification

    # User alias specification

    # Cmnd alias specification

    # User privilege specification
    root ALL=(ALL:ALL) ALL

    # Allow members of group sudo to execute any command
    %sudo ALL=(ALL:ALL) ALL

    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) NOPASSWD:ALL

    # See sudoers(5) for more information on "#include" directives:

    #includedir /etc/sudoers.d


    then for every user that needs sudo access WITH a password:



    sudo adduser <user> sudo


    and for every user that needs sudo access WITH NO password:



    sudo adduser <user> admin


    and finally, run this:



    sudo service sudo restart


    And that's it!



    Edit: You may have to add the admin group as I don't think it exists by default.



    sudo groupadd admin


    You can also add the default AWS ubuntu user to the admin group via this command:



    sudo usermod ubuntu -g admin


    Note: As @hata mentioned, you may need to use adm as your admin group name, depending on which version of Ubuntu is being used.






    share|improve this answer





















    • 3





      Note to self: It's a convention to move less restrictive permissions lower in the stack. But not doing it won't affect functionality.

      – poweratom
      Sep 5 '14 at 9:47






    • 2





      As jiminikiz explained, I had to place the %admin after the %sudo on my Ubuntu GNOME 16.04 LTS. Plus, the administrators group id is exactly not admin but adm on my Ubuntu. No reboot was required.

      – hata
      Oct 26 '17 at 10:52


















    88














    I found that the most straight forward thing to do, in order to easily replicate this behavior across multiple servers, was the following:



    sudo visudo


    Change this line:



    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) ALL


    to this line:



    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) NOPASSWD:ALL


    And move it under this line:



    # Allow members of group sudo to execute any command
    %sudo ALL=(ALL:ALL) ALL


    you should now have this:



    # This file MUST be edited with the 'visudo' command as root.
    #
    # Please consider adding local content in /etc/sudoers.d/ instead of
    # directly modifying this file.
    #
    # See the man page for details on how to write a sudoers file.
    #

    Defaults env_reset
    Defaults mail_badpass
    Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

    # Host alias specification

    # User alias specification

    # Cmnd alias specification

    # User privilege specification
    root ALL=(ALL:ALL) ALL

    # Allow members of group sudo to execute any command
    %sudo ALL=(ALL:ALL) ALL

    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) NOPASSWD:ALL

    # See sudoers(5) for more information on "#include" directives:

    #includedir /etc/sudoers.d


    then for every user that needs sudo access WITH a password:



    sudo adduser <user> sudo


    and for every user that needs sudo access WITH NO password:



    sudo adduser <user> admin


    and finally, run this:



    sudo service sudo restart


    And that's it!



    Edit: You may have to add the admin group as I don't think it exists by default.



    sudo groupadd admin


    You can also add the default AWS ubuntu user to the admin group via this command:



    sudo usermod ubuntu -g admin


    Note: As @hata mentioned, you may need to use adm as your admin group name, depending on which version of Ubuntu is being used.






    share|improve this answer





















    • 3





      Note to self: It's a convention to move less restrictive permissions lower in the stack. But not doing it won't affect functionality.

      – poweratom
      Sep 5 '14 at 9:47






    • 2





      As jiminikiz explained, I had to place the %admin after the %sudo on my Ubuntu GNOME 16.04 LTS. Plus, the administrators group id is exactly not admin but adm on my Ubuntu. No reboot was required.

      – hata
      Oct 26 '17 at 10:52
















    88












    88








    88







    I found that the most straight forward thing to do, in order to easily replicate this behavior across multiple servers, was the following:



    sudo visudo


    Change this line:



    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) ALL


    to this line:



    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) NOPASSWD:ALL


    And move it under this line:



    # Allow members of group sudo to execute any command
    %sudo ALL=(ALL:ALL) ALL


    you should now have this:



    # This file MUST be edited with the 'visudo' command as root.
    #
    # Please consider adding local content in /etc/sudoers.d/ instead of
    # directly modifying this file.
    #
    # See the man page for details on how to write a sudoers file.
    #

    Defaults env_reset
    Defaults mail_badpass
    Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

    # Host alias specification

    # User alias specification

    # Cmnd alias specification

    # User privilege specification
    root ALL=(ALL:ALL) ALL

    # Allow members of group sudo to execute any command
    %sudo ALL=(ALL:ALL) ALL

    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) NOPASSWD:ALL

    # See sudoers(5) for more information on "#include" directives:

    #includedir /etc/sudoers.d


    then for every user that needs sudo access WITH a password:



    sudo adduser <user> sudo


    and for every user that needs sudo access WITH NO password:



    sudo adduser <user> admin


    and finally, run this:



    sudo service sudo restart


    And that's it!



    Edit: You may have to add the admin group as I don't think it exists by default.



    sudo groupadd admin


    You can also add the default AWS ubuntu user to the admin group via this command:



    sudo usermod ubuntu -g admin


    Note: As @hata mentioned, you may need to use adm as your admin group name, depending on which version of Ubuntu is being used.






    share|improve this answer















    I found that the most straight forward thing to do, in order to easily replicate this behavior across multiple servers, was the following:



    sudo visudo


    Change this line:



    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) ALL


    to this line:



    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) NOPASSWD:ALL


    And move it under this line:



    # Allow members of group sudo to execute any command
    %sudo ALL=(ALL:ALL) ALL


    you should now have this:



    # This file MUST be edited with the 'visudo' command as root.
    #
    # Please consider adding local content in /etc/sudoers.d/ instead of
    # directly modifying this file.
    #
    # See the man page for details on how to write a sudoers file.
    #

    Defaults env_reset
    Defaults mail_badpass
    Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

    # Host alias specification

    # User alias specification

    # Cmnd alias specification

    # User privilege specification
    root ALL=(ALL:ALL) ALL

    # Allow members of group sudo to execute any command
    %sudo ALL=(ALL:ALL) ALL

    # Members of the admin group may gain root privileges
    %admin ALL=(ALL) NOPASSWD:ALL

    # See sudoers(5) for more information on "#include" directives:

    #includedir /etc/sudoers.d


    then for every user that needs sudo access WITH a password:



    sudo adduser <user> sudo


    and for every user that needs sudo access WITH NO password:



    sudo adduser <user> admin


    and finally, run this:



    sudo service sudo restart


    And that's it!



    Edit: You may have to add the admin group as I don't think it exists by default.



    sudo groupadd admin


    You can also add the default AWS ubuntu user to the admin group via this command:



    sudo usermod ubuntu -g admin


    Note: As @hata mentioned, you may need to use adm as your admin group name, depending on which version of Ubuntu is being used.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Oct 11 '18 at 17:24

























    answered Apr 3 '14 at 21:45









    jiminikizjiminikiz

    1,03577




    1,03577








    • 3





      Note to self: It's a convention to move less restrictive permissions lower in the stack. But not doing it won't affect functionality.

      – poweratom
      Sep 5 '14 at 9:47






    • 2





      As jiminikiz explained, I had to place the %admin after the %sudo on my Ubuntu GNOME 16.04 LTS. Plus, the administrators group id is exactly not admin but adm on my Ubuntu. No reboot was required.

      – hata
      Oct 26 '17 at 10:52
















    • 3





      Note to self: It's a convention to move less restrictive permissions lower in the stack. But not doing it won't affect functionality.

      – poweratom
      Sep 5 '14 at 9:47






    • 2





      As jiminikiz explained, I had to place the %admin after the %sudo on my Ubuntu GNOME 16.04 LTS. Plus, the administrators group id is exactly not admin but adm on my Ubuntu. No reboot was required.

      – hata
      Oct 26 '17 at 10:52










    3




    3





    Note to self: It's a convention to move less restrictive permissions lower in the stack. But not doing it won't affect functionality.

    – poweratom
    Sep 5 '14 at 9:47





    Note to self: It's a convention to move less restrictive permissions lower in the stack. But not doing it won't affect functionality.

    – poweratom
    Sep 5 '14 at 9:47




    2




    2





    As jiminikiz explained, I had to place the %admin after the %sudo on my Ubuntu GNOME 16.04 LTS. Plus, the administrators group id is exactly not admin but adm on my Ubuntu. No reboot was required.

    – hata
    Oct 26 '17 at 10:52







    As jiminikiz explained, I had to place the %admin after the %sudo on my Ubuntu GNOME 16.04 LTS. Plus, the administrators group id is exactly not admin but adm on my Ubuntu. No reboot was required.

    – hata
    Oct 26 '17 at 10:52













    2














    I would create my own file under /etc/sudoers.d/ directory - the file created by Amazon Cloud might be overwritten in case of any update. After creating your file in /etc/sudoers.d, add this entry,



    <your user name> ALL=(ALL) NOPASSWD:ALL


    Reboot the system and this will work.






    share|improve this answer




























      2














      I would create my own file under /etc/sudoers.d/ directory - the file created by Amazon Cloud might be overwritten in case of any update. After creating your file in /etc/sudoers.d, add this entry,



      <your user name> ALL=(ALL) NOPASSWD:ALL


      Reboot the system and this will work.






      share|improve this answer


























        2












        2








        2







        I would create my own file under /etc/sudoers.d/ directory - the file created by Amazon Cloud might be overwritten in case of any update. After creating your file in /etc/sudoers.d, add this entry,



        <your user name> ALL=(ALL) NOPASSWD:ALL


        Reboot the system and this will work.






        share|improve this answer













        I would create my own file under /etc/sudoers.d/ directory - the file created by Amazon Cloud might be overwritten in case of any update. After creating your file in /etc/sudoers.d, add this entry,



        <your user name> ALL=(ALL) NOPASSWD:ALL


        Reboot the system and this will work.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Apr 3 at 13:50









        Sayan BoseSayan Bose

        1212




        1212























            1














            Short answer without using any editor (tested on bash, very risky to execute on remote hosts).



            Configure sudo to work without a password for the current user:



            echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers


            Check the edit with:



            sudo visudo -c


            Verify if you can use sudo without a password:



            sudo cat /etc/sudoers | grep "$USER"


            ...or simply try it with:



            sudo <anything>





            share|improve this answer





















            • 21





              This is pretty dangerous advice... copy and paste this wrong and you'll lock yourself out of your own server. Hence the advice to use visudo. It checks that the syntax is correct before saving to disk. So, for anyone that wants to use this. Don't do it on a remote server that you care about. You might want to include a warning about that in your answer.

              – aychedee
              Aug 14 '14 at 9:25








            • 8





              Not using visudo is a horrible idea. Trust me, I know.

              – trognanders
              Sep 9 '15 at 17:22






            • 1





              IMHO, a copy-paste is safer than a manual edit. A minor simplification: echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers

              – theartofrain
              Apr 5 '16 at 23:56








            • 4





              @theartofrain - Normally, I'd agree, but visudo is particularly nice about not allowing you to break the sudoers file, thus not locking you out of your machine (or at least sudo).

              – Jon V
              Mar 15 '17 at 2:43






            • 3





              @JonV You can lose admin rights via visudo too, but usually not by accident, because visudo only saves changes that are well-formed according to the grammar for sudoers files. Most mistakes are syntactically wrong, so they cause no harm with visudo. If /etc/sudoers or a file in /etc/sudoers.d is ill-formed, sudo refuses to elevate privileges for anyone as a security measure, which is why not using visudo is dangerous. (Though sometimes pkexec can fix it without a reboot.)

              – Eliah Kagan
              Sep 28 '17 at 12:29
















            1














            Short answer without using any editor (tested on bash, very risky to execute on remote hosts).



            Configure sudo to work without a password for the current user:



            echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers


            Check the edit with:



            sudo visudo -c


            Verify if you can use sudo without a password:



            sudo cat /etc/sudoers | grep "$USER"


            ...or simply try it with:



            sudo <anything>





            share|improve this answer





















            • 21





              This is pretty dangerous advice... copy and paste this wrong and you'll lock yourself out of your own server. Hence the advice to use visudo. It checks that the syntax is correct before saving to disk. So, for anyone that wants to use this. Don't do it on a remote server that you care about. You might want to include a warning about that in your answer.

              – aychedee
              Aug 14 '14 at 9:25








            • 8





              Not using visudo is a horrible idea. Trust me, I know.

              – trognanders
              Sep 9 '15 at 17:22






            • 1





              IMHO, a copy-paste is safer than a manual edit. A minor simplification: echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers

              – theartofrain
              Apr 5 '16 at 23:56








            • 4





              @theartofrain - Normally, I'd agree, but visudo is particularly nice about not allowing you to break the sudoers file, thus not locking you out of your machine (or at least sudo).

              – Jon V
              Mar 15 '17 at 2:43






            • 3





              @JonV You can lose admin rights via visudo too, but usually not by accident, because visudo only saves changes that are well-formed according to the grammar for sudoers files. Most mistakes are syntactically wrong, so they cause no harm with visudo. If /etc/sudoers or a file in /etc/sudoers.d is ill-formed, sudo refuses to elevate privileges for anyone as a security measure, which is why not using visudo is dangerous. (Though sometimes pkexec can fix it without a reboot.)

              – Eliah Kagan
              Sep 28 '17 at 12:29














            1












            1








            1







            Short answer without using any editor (tested on bash, very risky to execute on remote hosts).



            Configure sudo to work without a password for the current user:



            echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers


            Check the edit with:



            sudo visudo -c


            Verify if you can use sudo without a password:



            sudo cat /etc/sudoers | grep "$USER"


            ...or simply try it with:



            sudo <anything>





            share|improve this answer















            Short answer without using any editor (tested on bash, very risky to execute on remote hosts).



            Configure sudo to work without a password for the current user:



            echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers


            Check the edit with:



            sudo visudo -c


            Verify if you can use sudo without a password:



            sudo cat /etc/sudoers | grep "$USER"


            ...or simply try it with:



            sudo <anything>






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 2 '18 at 21:24









            David Eison

            1033




            1033










            answered Aug 13 '14 at 22:25









            user315445user315445

            671




            671








            • 21





              This is pretty dangerous advice... copy and paste this wrong and you'll lock yourself out of your own server. Hence the advice to use visudo. It checks that the syntax is correct before saving to disk. So, for anyone that wants to use this. Don't do it on a remote server that you care about. You might want to include a warning about that in your answer.

              – aychedee
              Aug 14 '14 at 9:25








            • 8





              Not using visudo is a horrible idea. Trust me, I know.

              – trognanders
              Sep 9 '15 at 17:22






            • 1





              IMHO, a copy-paste is safer than a manual edit. A minor simplification: echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers

              – theartofrain
              Apr 5 '16 at 23:56








            • 4





              @theartofrain - Normally, I'd agree, but visudo is particularly nice about not allowing you to break the sudoers file, thus not locking you out of your machine (or at least sudo).

              – Jon V
              Mar 15 '17 at 2:43






            • 3





              @JonV You can lose admin rights via visudo too, but usually not by accident, because visudo only saves changes that are well-formed according to the grammar for sudoers files. Most mistakes are syntactically wrong, so they cause no harm with visudo. If /etc/sudoers or a file in /etc/sudoers.d is ill-formed, sudo refuses to elevate privileges for anyone as a security measure, which is why not using visudo is dangerous. (Though sometimes pkexec can fix it without a reboot.)

              – Eliah Kagan
              Sep 28 '17 at 12:29














            • 21





              This is pretty dangerous advice... copy and paste this wrong and you'll lock yourself out of your own server. Hence the advice to use visudo. It checks that the syntax is correct before saving to disk. So, for anyone that wants to use this. Don't do it on a remote server that you care about. You might want to include a warning about that in your answer.

              – aychedee
              Aug 14 '14 at 9:25








            • 8





              Not using visudo is a horrible idea. Trust me, I know.

              – trognanders
              Sep 9 '15 at 17:22






            • 1





              IMHO, a copy-paste is safer than a manual edit. A minor simplification: echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers

              – theartofrain
              Apr 5 '16 at 23:56








            • 4





              @theartofrain - Normally, I'd agree, but visudo is particularly nice about not allowing you to break the sudoers file, thus not locking you out of your machine (or at least sudo).

              – Jon V
              Mar 15 '17 at 2:43






            • 3





              @JonV You can lose admin rights via visudo too, but usually not by accident, because visudo only saves changes that are well-formed according to the grammar for sudoers files. Most mistakes are syntactically wrong, so they cause no harm with visudo. If /etc/sudoers or a file in /etc/sudoers.d is ill-formed, sudo refuses to elevate privileges for anyone as a security measure, which is why not using visudo is dangerous. (Though sometimes pkexec can fix it without a reboot.)

              – Eliah Kagan
              Sep 28 '17 at 12:29








            21




            21





            This is pretty dangerous advice... copy and paste this wrong and you'll lock yourself out of your own server. Hence the advice to use visudo. It checks that the syntax is correct before saving to disk. So, for anyone that wants to use this. Don't do it on a remote server that you care about. You might want to include a warning about that in your answer.

            – aychedee
            Aug 14 '14 at 9:25







            This is pretty dangerous advice... copy and paste this wrong and you'll lock yourself out of your own server. Hence the advice to use visudo. It checks that the syntax is correct before saving to disk. So, for anyone that wants to use this. Don't do it on a remote server that you care about. You might want to include a warning about that in your answer.

            – aychedee
            Aug 14 '14 at 9:25






            8




            8





            Not using visudo is a horrible idea. Trust me, I know.

            – trognanders
            Sep 9 '15 at 17:22





            Not using visudo is a horrible idea. Trust me, I know.

            – trognanders
            Sep 9 '15 at 17:22




            1




            1





            IMHO, a copy-paste is safer than a manual edit. A minor simplification: echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers

            – theartofrain
            Apr 5 '16 at 23:56







            IMHO, a copy-paste is safer than a manual edit. A minor simplification: echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers

            – theartofrain
            Apr 5 '16 at 23:56






            4




            4





            @theartofrain - Normally, I'd agree, but visudo is particularly nice about not allowing you to break the sudoers file, thus not locking you out of your machine (or at least sudo).

            – Jon V
            Mar 15 '17 at 2:43





            @theartofrain - Normally, I'd agree, but visudo is particularly nice about not allowing you to break the sudoers file, thus not locking you out of your machine (or at least sudo).

            – Jon V
            Mar 15 '17 at 2:43




            3




            3





            @JonV You can lose admin rights via visudo too, but usually not by accident, because visudo only saves changes that are well-formed according to the grammar for sudoers files. Most mistakes are syntactically wrong, so they cause no harm with visudo. If /etc/sudoers or a file in /etc/sudoers.d is ill-formed, sudo refuses to elevate privileges for anyone as a security measure, which is why not using visudo is dangerous. (Though sometimes pkexec can fix it without a reboot.)

            – Eliah Kagan
            Sep 28 '17 at 12:29





            @JonV You can lose admin rights via visudo too, but usually not by accident, because visudo only saves changes that are well-formed according to the grammar for sudoers files. Most mistakes are syntactically wrong, so they cause no harm with visudo. If /etc/sudoers or a file in /etc/sudoers.d is ill-formed, sudo refuses to elevate privileges for anyone as a security measure, which is why not using visudo is dangerous. (Though sometimes pkexec can fix it without a reboot.)

            – Eliah Kagan
            Sep 28 '17 at 12:29


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Ask Ubuntu!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f192050%2fhow-to-run-sudo-command-with-no-password%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            數位音樂下載

            When can things happen in Etherscan, such as the picture below?

            格利澤436b