Sudoers NOPASSWD from host

I have an ARM system installed from many years and working fine.
What I found in the /etc/sudoers.d path is the file 10-installer.
This file simply contains %wheel ALL=(ALL) ALL and this works fine.
So I have tried to change to %wheel ALL=(ALL:ALL) NOPASSWD : ALL and this works fine again.
But this is not what I want. I want the users from wheel group to be allowed to make sudo without password only if they connect from some hosts of my internal home network.
So I have tried:

Host_Alias HOMENETWORK = dellg5.mgnet.net, mg2.mgnet.net
%wheel HOMENETWORK=(ALL:ALL) NOPASSWD : ALL 

Please notice that from the host where I want to make these changes the dellg5.mgnet.net hostname is resovled in an IP address:

ping -c 1 dellg5.mgnet.net
PING dellg5.mgnet.net (192.168.1.109) 56(84) bytes of data.
64 bytes from dellg5.local (192.168.1.109): icmp_seq=1 ttl=64 time=0.340 ms

--- dellg5.mgnet.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.340/0.340/0.340/0.000 ms

This is not working.
It seems the rule change is not activated:

#sudo -ll
User root may run the following commands on mg1:

Sudoers entry: /etc/sudoers
    RunAsUsers: ALL
    RunAsGroups: ALL
    Commands:
	ALL

You seem to be executing the sudo -ll as root. Execute it as one of the users on the wheel group to see the rules for that user.

Anyway, with a quick search on Google, it seems that the host is not meant to be used in that way. The host part means that the rule is only to be applicable if the current host is one of those hosts.

Apparently, this way, if you have a large number of servers, you can make only one sudoers file and distribute it to all the servers. An each server is going to follow just the rules that apply to that particular server.

2 Likes

If it is like you wrote I am very unhappy

[marco@mg1 ~]$ sudo -ll
[sudo] password for marco: 
Sorry, user marco may not run sudo on mg1.

For the actual permission, I believe it should be defined as

%wheel ALL=(ALL) NOPASSWD: ALL

For the rest :man_shrugging:

EDIT 2024-07-09T07:00:00Z

[https://www.sudo.ws/docs/man/1.7.10/sudoers.man/]

The basic structure of a user specification is “who where = (as_whom) what”.

After some reading, I realize that what you are describing is actually the opposite of you want.

The machines in Host_Alias is not the machines allowed to make changes but the machines on which the specified user may run any command without password

So by specifying machines in the HOMENETWORK which is not that actual machine will prevent your user from making any changes.

In an attempt to understand what you wanted I tried the same configuration as yours and got the same result.

But when changing the configuration to be the hostname of the machine the user is allowed to make changes - I could get it work - without the user being member of wheel group.

[root@rpi ~]# cat /etc/sudoers.d/09-safehosts
Host_Alias   SAFE_HOSTS = rpi
fh           SAFE_HOSTS = (ALL) NOPASSWD:ALL

If I negate the SAFE_HOSTS sudo is rejected

[root@rpi ~]# cat /etc/sudoers.d/09-safehosts
Host_Alias   SAFE_HOSTS = !rpi
fh           SAFE_HOSTS = (ALL) NOPASSWD:ALL

This leads me to this conclusion: The usecase you describe would work only in a centralilized management scenario - where a given server controls the sudo permissions.

In a small home network scenario - the Host_Alias is not applicable as you do not have a single signon to the network.

with polkit, in rules, we can exec bash (spawn) for accept or not without pass
BUT
pkexec not run in ssh connection

non-functional code :

polkit.addRule(function(action, subject) {
    if (subject.isInGroup("wheel")) {
        try {
            /* env | grep 'SSH_CONNECTION.*192\.178' */  is that what you want?
            polkit.spawn(["/myscripts/is-valid.sh", subject.user])
            return polkit.Result.YES;
        } catch (error) {
            return polkit.Result.AUTH_ADMIN;
        }
        /* return polkit.Result.NO; */
    }
});




with sudo, exits also “plugins” that you can write. But python version it’s not available with archlinux : not set in pkgbuild
man

Python plugin support needs to be explicitly enabled at build time with the configure option “–enable-python”.