When having multiple simultanious SSH connections, only the first two can `sudo`

Multisync · 12-05-2017, 09:13 AM

Hi all,

When there are multiple simultaneous SSH connections open, only the first two can sudo. In the third connection, one gets asked for a password, altough the user doesn't have a password set.

First connection:

Code:

manuel@manuelthinkpad:~$ ssh manuel-nas-wan 
Enter passphrase for key '/home/manuel/.ssh/manuel-thinkpad-arbeit.ed25519': 
Linux manuel-nas 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64

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

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Dec  5 13:59:52 2017 from xxx.xxx.xxx.xxx

user@manuel-nas:~$ sudo pwd
/home/user

Second connection:

(Equal to first connection)

Third connection:

Code:

manuel@manuelthinkpad:~$ ssh manuel-nas-wan
Enter passphrase for key '/home/manuel/.ssh/manuel-thinkpad-arbeit.ed25519': 
Linux manuel-nas 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64

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

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Dec  5 14:27:00 2017 from xxx.xxx.xxx.xxx

user@manuel-nas:~$ sudo pwd
[sudo] password for user:

Question

Can anyone tell me the reason, and how to deactivate this behavior? I want to be able to sudo from all of my connections, not just the first two.

Additional information

The server is a headless live-system, that is, it boots from removable media and then runs entirely from RAM. (/ is a tmpfs.) The image file which I'm flashing onto the removable media is created by a selfwritten shell script which is setting up the whole system using debootstrap and chroot commands.

The server is running "OpenSSH_7.4p1 Debian-10+deb9u1, OpenSSL 1.0.2l 25 May 2017".

Thanks!

ondoho · 12-06-2017, 03:48 AM

so it's a sudo problem, and not ssh?

Code:

man sudo
man sudoers
sudo nano /etc/sudoers

maybe there's a setting somewhere doing that.

WHICH password does it ask if you don't have a password set?

also, i didn't even know that's possible, and i think it's a really bad idea security-wise.

do you need to regularly perform sudo commands remotely, from a script?
maybe a better solution woul dbe to add that command to /etc/sudoers so that you can execute it without password. https://wiki.archlinux.org/index.php...xample_entries

Multisync · 12-08-2017, 05:33 AM

Quote:

Originally Posted by ondoho

so it's a sudo problem, and not ssh?

I don't know.

Quote:

Originally Posted by ondoho

Code:

man sudo
man sudoers
sudo nano /etc/sudoers

maybe there's a setting somewhere doing that.

Thanks for these hints, I took a quick look into these manpages and was surprised to learn that there is quite more behind this simple command than I expected. Unfortunately I didn't yet find time to chew through them completely.

Quote:

Originally Posted by ondoho

WHICH password does it ask if you don't have a password set?

also, i didn't even know that's possible, and i think it's a really bad idea security-wise.

do you need to regularly perform sudo commands remotely, from a script?
maybe a better solution woul dbe to add that command to /etc/sudoers so that you can execute it without password. https://wiki.archlinux.org/index.php...xample_entries

There is no security implication involved here. Access protection to WAN is achieved by using key-protected SSH. Access protection within LAN not necessary in my use case.

ondoho · 12-09-2017, 02:50 AM

my question stands:
what exactly do you mean by "the user doesn't have a password set"???

Multisync · 12-10-2017, 02:59 PM

Quote:

Originally Posted by ondoho

my question stands:
what exactly do you mean by "the user doesn't have a password set"???

I'm sorry, I thought that question was metaphorical.

The password field for this user in /etc/shadow is empty. You could also say: The password is a string of 0 characters length.

Here is the relevant part of /etc/shadow:

Code:

user::17504:0:99999:7:::

ondoho · 12-11-2017, 12:20 AM

^ so it apparently IS possible to set a blank password for a user.
not something i am going to try for testing purposes.

so that 3rd ssh connection, it CAN sudo, but asks a password?
what happens when you just press enter?

pan64 · 12-11-2017, 02:33 AM

Quote:

sudo versions 1.8.4 and higher support a flexible debugging framework that can help track down what sudo is doing internally if there is a problem.

see man sudo.conf

Multisync · 12-13-2017, 08:12 AM

Now this is interesting.

I have enabled sudo debugging by creating a file `/etc/sudo.conf` with following content:

Code:

Debug sudo /var/log/sudo_debug all@warn

After running sudo and provoking a "good" case and a "bad" case, I analyzed this file. This is were they start to differ:

Good case, i. e. sudo completes successfully:

Code:

Dec 12 20:54:21 sudo[6860] <- policy_open @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/sudo.c:1292 := 1
Dec 12 20:54:21 sudo[6860] -> policy_check @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/sudo.c:1330
Dec 12 20:54:21 sudo[6860] <- policy_check @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/sudo.c:1340 := 1
Dec 12 20:54:21 sudo[6860] policy plugin returns 1

Bad case, i. e. sudo asks for a non-existent password:

Code:

Dec 12 20:54:43 sudo[6863] <- policy_open @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/sudo.c:1292 := 1
Dec 12 20:54:43 sudo[6863] -> policy_check @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/sudo.c:1330
Dec 12 20:54:43 sudo[6863] -> tgetpass @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/tgetpass.c:93
Dec 12 20:54:43 sudo[6863] -> tty_present @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/tgetpass.c:360
Dec 12 20:54:43 sudo[6863] <- tty_present @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/tgetpass.c:361 := true
Dec 12 20:54:43 sudo[6863] -> sudo_term_noecho_v1 @ /build/sudo-oI7LKn/sudo-1.8.19p1/lib/util/term.c:130
Dec 12 20:54:43 sudo[6863] <- sudo_term_noecho_v1 @ /build/sudo-oI7LKn/sudo-1.8.19p1/lib/util/term.c:141 := true
Dec 12 20:54:43 sudo[6863] -> getln @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/tgetpass.c:303
Dec 12 20:57:13 sudo[6863] <- getln @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/tgetpass.c:346 := (null)
Dec 12 20:57:13 sudo[6863] -> sudo_term_restore_v1 @ /build/sudo-oI7LKn/sudo-1.8.19p1/lib/util/term.c:112
Dec 12 20:57:13 sudo[6863] <- sudo_term_restore_v1 @ /build/sudo-oI7LKn/sudo-1.8.19p1/lib/util/term.c:120 := true
Dec 12 20:57:13 sudo[6863] <- tgetpass @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/tgetpass.c:231 := (null)
Dec 12 20:57:13 sudo[6863] <- policy_check @ /build/sudo-oI7LKn/sudo-1.8.19p1/src/sudo.c:1340 := 0
Dec 12 20:57:13 sudo[6863] policy plugin returns 0

This is the source code of policy_check(), located at `sudo.c` at around line 1330:

Code:

static int
policy_check(struct plugin_container *plugin, int argc, char * const argv[],
    char *env_add[], char **command_info[], char **argv_out[],
    char **user_env_out[])
{
    int ret;
    debug_decl(policy_check, SUDO_DEBUG_PCOMM)

    if (plugin->u.policy->check_policy == NULL) {
	sudo_fatalx(U_("policy plugin %s is missing the `check_policy' method"),
	    plugin->name);
    }
    sudo_debug_set_active_instance(plugin->debug_instance);
    ret = plugin->u.policy->check_policy(argc, argv, env_add, command_info,
	argv_out, user_env_out);
    sudo_debug_set_active_instance(sudo_debug_instance);
    debug_return_int(ret);
}

I think my attempt of finding the root cause is too low-level. I'm afraid to become acquainted with the code base requires more time from me than I can spare right now.

Has anyone any further insights?

Multisync · 12-13-2017, 08:17 AM

Quote:

Originally Posted by ondoho

^ so it apparently IS possible to set a blank password for a user.
not something i am going to try for testing purposes.

so that 3rd ssh connection, it CAN sudo, but asks a password?
what happens when you just press enter?

It tells me that the password is incorrect.

pan64 · 12-13-2017, 08:21 AM

this is the function plugin->u.policy->check_policy which will do the check (and returns 0 or 1)

ondoho · 12-13-2017, 11:26 PM

Quote:

Originally Posted by Multisync

It tells me that the password is incorrect.

i think you're lost in the rabbit hole.

i think you should go back to step zero.

something must have gone wrong in the very beginning of all this, that's my guess.

instead of setting a blank password (and i still question whether that is even possible) you should use /etc/sudoers to allow certain commands to run with elevated privileges, but without password check.

Multisync · 12-14-2017, 02:46 PM

I was able to circumvent the problem by adding

Code:

Defaults !authenticate

to /etc/sudoers.

Quote:

Originally Posted by ondoho

instead of setting a blank password (and i still question whether that is even possible) you should use /etc/sudoers to allow certain commands to run with elevated privileges, but without password check.

Again, blank passwords are a standard feature.

What makes you think my use case allows to restrict the set of sudo-able commands in any way?