[ID# 00845880] Failed to run command with sudo

[basictheprogram]

Turned on Guest processing and Enabled guest file system indexing for all my Ubuntu linux systems (12.04 and 14.04).

Entered my Guest OS credentials and click Test Now. Receive this error on all my Linux guests.

3/19/2015 3:23:53 PM :: Testing SSH credentials for: XXXX Error: Failed to run command with sudo: no tty present and no askpass program specified
Sorry, try again.
sudo: no tty present and no askpass program specified
Sorry, try again.
sudo: no tty present and no askpass program specified
Sorry, try again.
sudo: 3 incorrect password attempts

In the Linux VM syslog shows me these messages

Mar 19 15:23:57 testvm-2 sudo: pam_unix(sudo:auth): conversation failed
Mar 19 15:23:57 testvm-2 sudo: pam_unix(sudo:auth): auth could not identify password for [XXXX]
Mar 19 15:23:57 testvm-2 sshd[647]: pam_unix(sshd:session): session closed for user XXXX

And I get these generated email alert

Mar 19 15:23:53 : XXXX : 3 incorrect password attempts ; TTY=unknown ; PWD=/home/XXXX ; USER=root ; COMMAND=/usr/bin/id -u

I've played with the Defaults entry in my /etc/sudoers file.

!requiretty doesn't resolve the problem
visualpw just hangs

Any help?

Thanks.

[basictheprogram]

Typo.
visiblepw just hangs.

[basictheprogram]

Can demonstrate this problem like this:

$ ssh XXXX@testvm.local "sudo /usr/bin/id -u"
XXXX@testvm.local's password:
sudo: no tty present and no askpass program specified

And a workaround on the command line line this:

$ ssh -t XXXX@testvm.local "sudo /usr/bin/id -u"
XXXX@testvm.local's password:
[sudo] password for XXXX:
0

[tsightler]

Do you have something like the below in your sudoers file:

Code: Select all

Defaults requiretty

This line causes sudo to require a tty. I didn't realize this was a common default in Ubuntu, and I don't see it on any of the Ubuntu systems I have access to. Any chance it came from a security policy?

If you are not providing a root account for indexing then you could potentially override this requirement for the user you are using. Of the top of my head it's something like:

Code: Select all

Defaults:veeamuser        !requiretty

[basictheprogram]

$ sudo -l
Matching Defaults entries for XXXX on dns-2:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
!requiretty

User XXXX may run the following commands on dns-2:
(ALL) ALL

Still get the same error message.

[tsightler]

Hmm...I can't explain that. Here's the same basic command line test on one of my Ubuntu 14.04 systems:

Code: Select all

$ ssh XXXX@ubuntu01 "sudo /usr/bin/id -u" 
XXXX@ubunto01's password:
[sudo] password for XXXX:
0

This is a pretty basic Ubuntu 14.04 server install, nothing much customized. I even tried using ssh -T which forces SSH to NOT allocate a psuedo-tty and it still works. Feels like there has to be something different with the environment settings or sudoers since sudo is the one complaining even for you ssh command line test but unfortunately I can't think of what it might be. I know it's somewhat security sensitive but is there any chance you could post your sudoers settings or at least PM them to me to test? I certainly understand if not but I don't know exactly where to go from here.

[basictheprogram]

As far as I know stock sudoers file.

Just the README in /etc/sudoers.d

The veeam backup user is in the %admin group.

Code: Select all

#
# 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

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

# 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

[veenski]

Did you manage to fix this?
I have the exact same issue

[veenski]

The reason for this error is that Linux wants to prompt for the sudo password on the remote host but doesn't have a tty to show you one.
You can bypass this by not letting it ask for a password at all.

first I created a new backup user

Code: Select all

sudo adduser backupuser

then add it to sudo group

Code: Select all

sudo adduser backupuser sudo

then edit the sudoers file

Code: Select all

sudo visudo

add the following line at the bottom

Code: Select all

backupuser ALL=(ALL) NOPASSWD: ALL

in the veeam create a new credential
username:backupuser
password:wellwhatyathink

put a tack at: Elevate specified user to root

Safer would be to replace the
backupuser ALL=(ALL) NOPASSWD: ALL
backupuser YOURVEEAMHOSTNAME=(root) NOPASSWD: 'what ever command it is veeam runs to index the filesystem'

But I wouldn't know what that command would be.

[ChrisCal]

I realize this is a very old thread but here's what I added to my sudoers file to get this to work reliably:

Code: Select all

USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /bin/uname
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /usr/bin/scp
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /bin/arch
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /bin/mount
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /usr/bin/sh
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /bin/rm
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /tmp/*

[jgh]

Please delete this post. I don't know why I am unable to do this.

Thank you.

[jgh]

I realize this is a very old thread but here's what I added to my sudoers file to get this to work reliably:

Code: Select all

USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /bin/uname
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /usr/bin/scp
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /bin/arch
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /bin/mount
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /usr/bin/sh
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /bin/rm
USERNAMEOFSSHUSER ALL=(root) NOPASSWD: /tmp/*

Thanks for the command-set for sudo. This definitely helped me to at least get a better grip on what was required for veeam using sudo facilities to interact when restoring. All of this aside, I would like to see if you have a more secure approach. The bits that allow /bin/rm and /tmp/* are of concern.

I have opened case 01732540 with Veeam to see if I could get clarification on more specific details, as their current sudo directives are wildly insecure.

Thanks!
-jgh

[jeffshead]

I have opened case 01732540 with Veeam to see if I could get clarification on more specific details, as their current sudo directives are wildly insecure.

Thanks!
-jgh

@jgh - Did Support provide you with a better approach?

Sorry for resurrecting an old thread but this was the only one I found that describes the same issue I'm encountering with Zorin OS.

Cheers,

Jeff

[riahc3]

Using NOPASSWD is EXTREMELY unsecure and not a valid workaround.

[csydas]

@John,

Is it really?

If you're using Private Keys for authentication on your server, plausibly the only way that someone malicious is getting on the server and running stuff is if they've either got "physical" access to the machine (literal or through your hypervisor) or if they've compromised your passphrase, are able to get access to the Veeam Server for the key as well, and bypass whatever access restriction you have set up.

I'm all for security, but it seems like worrying about NOPASSWD is worrying about the wallpaper when the castle's on fire.

Use a service account with a relatively unique name, lock down remote access to the machine, disable root login over SSH, set up sudoers with the above settings, and that should be fine. At that point if they're still getting in, it's not because NOPASSWD is set, even for /bin/rm and /tmp/*. The battle is lost the moment they log on, not once they realize they're running with NOPASSWD.

[spoovy]

Sorry to dig up an oldish thread but this is definitely insecure. With "normal", password-required sudo, if someone compromises your private keys somehow then they still need the passwords (which would be stored elsewhere of course) to actually do anything rooty on the box -- it's 2FA. Passwordless sudo is equivalent to just letting people log on as root.

[tsightler]

But the question is, how is the private key going to be compromised if setup correctly? For a normal interactive user, it's 2FA because it's a thing you have (the key) and a thing you know (the password), if my machine is compromised and someone gets the key (assuming I've stored the key without a passphrase, already bad practice), they still don't know the password, which is hopefully only in my head. They will need to perform other techniques (keylogging, etc) to attempt to get the password. However, if I have stored the password anywhere on the system, then they do have both key and password and it's not really 2FA anymore.

However, the Veeam server is not a normal interactive user, it's a service, and thus, it is required to store both the key and the password in the credentials store. The private key used for this service should be protected by a passphrase, and should exist nowhere except in the encrypted credentials store. If someone compromises the Veeam server enough to acquire this key, they will easily be able to acquire the sudo password as well since they will be stored in the same place.

Now, I'm not arguing against supporting sudo with password, but I just don't see how it would add much security. If keys can be compromised without stealing them, then SSH has much bigger problems, and the only place to steal them from is the credentials store, which would have both key and password.

[spoovy]

You are assuming that the private key is only stored on the server where it is actually used. In reality private keys are often stored in a shared password database, at risk of being leaked by accidental copy/paste, sharing on slack etc. I don't like this practice myself, but it is common in my experience.

But this whole argument of "If X is compromised, then Y is likely compromised too, so we might as well not configure Y properly" is bad practice. Every security feature can be compromised; that's why we build security in independent layers.