Dev1 Galaxy Forum / Unable to ssh from A to B to execute sudo command with arguments

Re: Unable to ssh from A to B to execute sudo command with arguments

dummy@example.com (Morgennebel) — Wed, 02 Oct 2019 16:39:08 +0000

chris2be8 wrote:

I've not used sudo for passwordless access for quite a few years. But as far as I can remember:
Start by running sudo -l on wolke7 and see what it says you can do.

Thank you, please see:

os@wolke7:~$ sudo -l
Matching Defaults entries for os on wolke7:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User os may run the following commands on wolke7:
    (root) NOPASSWD: /sbin/wondershaper *
    (ALL : ALL) ALL
os@wolke7:~$ sudo /sbin/wondershaper eth0 125 125
[sudo] password for os: 
Sorry, try again.
[sudo] password for os:

So sudo is not working for me.

If I redo the change to /etc/pam.d/sudo as described the link in the first post, it works as expected.
Is by chance /etc/pam.d/sudo broken in Devuan ASCII?

Thanks, -MN

Re: Unable to ssh from A to B to execute sudo command with arguments

dummy@example.com (Morgennebel) — Wed, 02 Oct 2019 16:36:44 +0000

Thank you,

I changed back the /etc/pam.d/sudo to original version:

root@wolke7:~# cat /etc/pam.d/sudo
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

and adopted your proposal:

root@wolke7:~# cat /etc/sudoers
#
# 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
#os	ALL=(ALL) NOPASSWD:  /sbin/wondershaper eth0 *
#os	ALL=(root) NOPASSWD: /bin/echo foo
os	ALL= NOPASSWD: /sbin/wondershaper

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

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

#includedir /etc/sudoers.d

As you can see, the two other lines are commented out.

After a reboot, sudo does not work:

os@wolke7:~$ sudo /sbin/wondershaper eth0 125 125
[sudo] password for os: 
Sorry, try again.
[sudo] password for os:

And in /var/log/auth.log I do see:

Oct  2 18:31:52 wolke7 su[2021]: pam_unix(su:session): session closed for user root
Oct  2 18:31:56 wolke7 sudo: pam_unix(sudo:auth): authentication failure; logname=os uid=1000 euid=0 tty=/dev/pts/0 ruser=os rhost=  user=os
Oct  2 18:32:22 wolke7 sudo: pam_unix(sudo:auth): conversation failed
Oct  2 18:32:22 wolke7 sudo: pam_unix(sudo:auth): auth could not identify password for [os]
Oct  2 18:32:22 wolke7 sudo:       os : 1 incorrect password attempt ; TTY=pts/0 ; PWD=/home/os ; USER=root ; COMMAND=/sbin/wondershaper eth0 125 125
Oct  2 18:32:32 wolke7 su[2060]: Successful su for root by os
Oct  2 18:32:32 wolke7 su[2060]: + /dev/pts/0 os:root
Oct  2 18:32:32 wolke7 su[2060]: pam_unix(su:session): session opened for user root by os(uid=1000)
Oct  2 18:32:32 wolke7 su[2060]: pam_elogind(su:session): Cannot create session: Already running in a session
Oct  2 18:32:53 wolke7 su[2060]: pam_unix(su:session): session closed for user root
Oct  2 18:32:55 wolke7 sudo: pam_unix(sudo:auth): conversation failed
Oct  2 18:32:55 wolke7 sudo: pam_unix(sudo:auth): auth could not identify password for [os]
Oct  2 18:33:03 wolke7 su[2088]: Successful su for root by os
Oct  2 18:33:03 wolke7 su[2088]: + /dev/pts/0 os:root
Oct  2 18:33:03 wolke7 su[2088]: pam_unix(su:session): session opened for user root by os(uid=1000)
Oct  2 18:33:03 wolke7 su[2088]: pam_elogind(su:session): Cannot create session: Already running in a session

Even when adding a * to os ALL= NOPASSWD: /sbin/wondershaper at the end to indicate arguments to wondershaper, it does not work.

/me confused.

Thanks, -MN

Re: Unable to ssh from A to B to execute sudo command with arguments

dummy@example.com (chris2be8) — Wed, 02 Oct 2019 16:29:27 +0000

I've not used sudo for passwordless access for quite a few years. But as far as I can remember:

It should not make any difference whether you logged onto wolke7 through ssh or directly on to it.

Start by running sudo -l on wolke7 and see what it says you can do.

Once you can run it locally without being asked for a password ssh os@192.168.255.42 '/sbin/wondershaper eth0 1500 750' should work.

Chris

Re: Unable to ssh from A to B to execute sudo command with arguments

dummy@example.com (fsmithred) — Wed, 02 Oct 2019 16:12:04 +0000

I'm no sudo expert, but you shouldn't have to mess with pam to allow a user to have certain commands with no password. First thing I would try is to just list the command with its full path but without the arguments. And maybe leave out the (ALL).

Maybe this:

os      ALL= NOPASSWD:  /sbin/wondershaper

Unable to ssh from A to B to execute sudo command with arguments

dummy@example.com (Morgennebel) — Wed, 02 Oct 2019 13:26:35 +0000

Dear,

I have system A with userA and system B with userB. Both systems run Devuan ASCII with all updates.

My challenge: I need to ssh userA@A to userB@B without a password to execute a command (wondershaper) which requires sudo rights.

My steps:

I enabled password-less ssh from userA@A to userB@B which works fine
I modified /etc/sudoers on B to allow userB@B to execute wondershaper without password

Logs passwordless-ssh:

fhem@smarthome:~$ 
fhem@smarthome:~$ ssh os@192.168.255.42
Linux wolke7 4.9.0-6-amd64 x86_64 GNU/Linux

The programs included with the Devuan GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Devuan GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Oct  1 18:48:20 2019 from 192.168.255.100
os@wolke7:~$

The command to be executed from userB@B is /sbin/wondershaper with 3 arguments (Network device, Downspeed, Upspeed).

My /etc/sudoers (edited with visudo) on system B is

#
# 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
os      ALL=(ALL) NOPASSWD:  /sbin/wondershaper eth0 *
os      ALL=(root) NOPASSWD: /bin/echo foo

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

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

#includedir /etc/sudoers.d

With this setup userB (= os) should be able to sudo without a password /sbin/wondershaper eth0 with two additional parameters.

However sudo is asking for the user password:

os@wolke7:~$ 
os@wolke7:~$ 
os@wolke7:~$ sudo /sbin/wondershaper eth0 1500 750
[sudo] password for os:

Logfile /var/log/auth.log reports:

Oct  2 15:17:01 wolke7 CRON[16018]: pam_unix(cron:session): session closed for user root
Oct  2 15:18:42 wolke7 su[16008]: pam_unix(su:session): session closed for user root
Oct  2 15:19:13 wolke7 sudo: pam_unix(sudo:auth): conversation failed
Oct  2 15:19:13 wolke7 sudo: pam_unix(sudo:auth): auth could not identify password for [os]
Oct  2 15:19:36 wolke7 sudo: pam_unix(sudo:auth): conversation failed
Oct  2 15:19:36 wolke7 sudo: pam_unix(sudo:auth): auth could not identify password for [os]
Oct  2 15:19:43 wolke7 su[16054]: Successful su for root by os
Oct  2 15:19:43 wolke7 su[16054]: + /dev/pts/1 os:root
Oct  2 15:19:43 wolke7 su[16054]: pam_unix(su:session): session opened for user root by os(uid=1000)
Oct  2 15:19:43 wolke7 su[16054]: pam_elogind(su:session): Cannot create session: Already running in a session

To read the logfile I used "su -" as userB on system B.

I found https://stackoverflow.com/questions/576 … ssword-for as potential solution which is to change /etc/pam.d/sudo . The Poster has the same challenge on a CentOS 7 system. The /etc/pam.d/sudo file looks similiar on my Devuan ASCII system missing lines like

# Fixing ssh "auth could not identify password for [username]"
auth       sufficient   pam_permit.so

I have very little to no experience configuring pam - is this the right solution for Devuan as well?

Thanks, -MN