salt-ssh fails without sudo and with sudo not using NOPASSWD

[pille]

when i use salt-ssh without enabling sudo in the roster, it fails:

pille@salt-master ~ % sudo salt-ssh '*' test.version
live3:
    ERROR: Permissions problem, target user may need to be root or use sudo:
     Traceback (most recent call last):
      File "/tmp/.salt/salt-call", line 4, in 
        salt_call()
      File "/tmp/.salt/salt/scripts.py", line 77, in salt_call
        client.run()
      File "/tmp/.salt/salt/cli/__init__.py", line 303, in run
        caller.run()
      File "/tmp/.salt/salt/cli/caller.py", line 135, in run
        ret = self.call()
      File "/tmp/.salt/salt/cli/caller.py", line 72, in call
        with salt.utils.fopen(proc_fn, 'w+') as fp_:
      File "/tmp/.salt/salt/utils/__init__.py", line 872, in fopen
        fhandle = open(*args, **kwargs)
    IOError: [Errno 13] Permission denied: '/var/cache/salt/minion/proc/20131128102923233205'

which is understandable, so i enabled sudo in the roster and got:

    
pille@salt-master ~ % sudo salt-ssh '*' test.version
live3:
    ERROR: sudo expected a password, NOPASSWD required

it wasn't asking for my password, but trying something (probably nothing).
same, when i specify passwd in the roster.

i'm not fine using NOPASSWD for my sudo access, and like to be prompted for my password interactively. perhaps it's a good idea to implement this as a new cmdline option, so that it may fail when running automated or with a huge number of targets.

[basepi]

I think the problem is you need to install sshpass.

As far as the request to prompt for it interactively, that's a duplicate of https://github.com/saltstack/salt/issues/8723#issuecomment-29053467

[pille]

sshpass was installed on the master. installing it on the target doesn't change anything.
honestly i doubt that it will be useful for sudo. just to be clear: ssh-pub-auth is working for me.

[basepi]

Ah, gotcha, I did misunderstand. I'm not sure if we support sudo without NOPASSWD, but we definitely should. Thanks for the report.

[cliffrowley]

This appears to still be an issue. I have sshpass installed and connecting yields this:

sudo: no tty present and no askpass program specified

Normally this wouldn't be a problem as I typically use NOPASSWD, however when setting up a new node it's a bit of a pain in the butt and means I can't automate it. I don't run enough nodes to justify setting up a master (and in fact, I would end up running several masters with my particular setup) - so salt-ssh is ideal for me.

[akhayyat]

Is this issue about supporting SSH with SUDO passwords (do not require NOPASSWD)? If so, I'm interested in this feature too.

[gw0]

I can not believe that salt-ssh is so bad from the security perspective. Check out how Ansible manages all these situations (afaik it handles everything: ssh login passwords, ssh key unlock passwords, sudo passwords).

[basepi]

@gw0 You're talking strictly from a feature-set standpoint, correct? As far as we know there are no outstanding security issues with salt-ssh, but if you've found one we'd love to hear about it. See our responsible disclosure policy: http://docs.saltstack.com/en/latest/security/index.html

[gw0]

@basepi Yes, from feature-set standpoint.

[basepi]

Thanks. =)

[azmelanar]

+1

[mlalpho]

+1 This would be a great feature

[miukumac]

+1 - this would be a pretty important thing to have since we have tens (and soon hundreds) of systems that we cannot (for various reasons, sometimes because of the customer, sometimes because salt-minion uses too many resources and has too many dependencies / requirements) install the minion on.

NOPASSWD is just not a very good idea from a security standpoint anyway.

[damon-atkins]

If you run salt-minion as a normal user then anything it needs to run as root via sudo should have NOPASSWORD, I suggest its very hard to support anything else. However the user the minion running as, should have every command it needs listed in the sudoers e.g./usr/bin/useradd if you want salt to be able to add users. It should not be ANY command as root, other wise you may as will run the minion as root.

I seen companies do the PASSWORD and then I have seen admins work around it by storing their password in expect scripts, which is not a good idea.

I assume your doing salt target -> ssh keys -> normal user -> sudo -> sudoers -> specific command allowed ?

The initial access at 1st system boot might need to be all commands, then as part of salt doing the first set of states it could update the sudoers file, and never have ALL Commands as root again.

Doing pattern matches on stdin looking for password prompts is asking for pain. For example a message of the day could contain "password: please change them once a month"

I agree on the master If you wish sudo salt target or sudo salt-call should work with NOPASSWORD and with PASSWORD.

My best guest is that your running salt-minion not as root on the target, and therefore /var/cache/salt/ should be owned by the user the minion is running as and not root. And this is why you are getting the error. I assume the salt installs set up the perms for root only by default.
/var/cache/salt/minion/proc/20131128102923233205 Maybe the bug is salt is changing it back or someone is running salt-call as root and its changing it back ????????????????

Hope this helps with your error, I have not personal used salt with ssh, but thats what the error looks like to me. I suggest If it was running as root you would only get the error with selinux settings in the mix

I suggest your describe your setup a bit more.

[miukumac]

I think the problem here is that it's actually two problems - the first being that you can't run salt-ssh unless you have permissions to various directories and then the bigger issues which is you can't execute commands remotely without having NOPASSWD on the target server which is just an epic fail from security standpoint.

Expecting to give users on every server that you don't want to run resource hogging salt-minion on literally unlimited access with NOPASSWD is.. crazy.

[djneades]

+1 for providing a solution to this. Compared to Ansible, Salt is severely lacking in its security and authentication capabilities. Not only does Ansible support passwords for sudo access, it enables you to store them securely in an encrypted vault so that you can unlock multiple passwords (and, indeed, other sensitive files, such as private keys) at run-time by entering a single master password.

[damon-atkins]

https://www.youtube.com/watch?v=qWG5pI8Glbs

I think I understand the miss understanding. It appears Ansible allows your normal user account to ssh to the target as your normal user account and then call sudo for root access
e.g. admin fred (without the Ansible bits)
fred@machine # ssh target sudo adduser ...... # sudo password prompt

Ansible is using fred's ssh keys or fred's password to log on to the target and then runs sudo and use fred's password again to allow sudo access to execute a command required

In the above case fred account is a normal account use by a admin everyday, I can understand why Ansible can handle the sudo password prompt, because its borrowing a fred's admin account. And companies general require for their staff with sudo root access (if the command being run as security risks) prompt for a password.

My response was based on a dedicated user account for salt-ssh that no admin (e.g. fred) logs into ever.

So I suspect ??? the people with Ansible background are expect salt to be able to use their own normal account as the remote target with salt-ssh, vs a dedicate salt account which can sudo with no password and a list of commands.

And hence this comment was made "Expecting to give users on every server that you don't want to run .. salt-minion on literally unlimited access with NOPASSWD is.. crazy." Expect everyone to use their own account as the ssh target account vs a dedicated account (with sudo salt-ssh target i.e. root to dedicated account or root to root or dedicated account [sudo -u saltuser salt-ssh ] to dedicated account.)

Don't think this thread has made it clear, what the the request is, in enough detail?

The little bit of a play I have done with salt-ssh I suspect that salt most of the time calls sudo python
If 10 people use salt-ssh then their will be 10 /tmp/.username...._salt directories with a small copy of salt with the files owned by root.

I am sure @basepi will be able to give us the background for salt-ssh intention i.e. dedicated account for salt vs normal user account which has admin access with sudo.

I hope I have interpreted correctly??

[basepi]

I think the goal is to support both dedicated accounts for salt and normal users with admin access via sudo.

[damon-atkins]

I would suggest for now from the master use
"sudo -u saltuser salt-ssh server1 disk.usage" to saltuser@server1 on the target (with NOPASSWORD) also use ssh allow key settings to restrict the commands and from where they can be executed from, on the local saltuser account on the target servers.

And then you can use normal sudo on the master to restrict what sudo -u saltuser salt-ssh is allow todo for each group of users people have.

[gw0]

@damon-atkins "dedicated user account for salt-ssh that no admin (e.g. fred) logs into ever" -- Yes, but every admin must have a SSH key for that user. If he does and gets hacked, the hacker can get into the server too, and even gain root privileges _without_ entering any password. In Ansible the hacker will need to break into the users secure vault, before he can do anything. You should not assume sysadmins are unhackable and that they carefully follow security guidelines.

[damon-atkins]

That's not correct @gw0
saltuser is the only user with private key. that's why .eg. fred on the master needs execute "sudo -u saltuser slat-ssh ....." and enter fred's password. Their is no need to distribute lots of individual admin keys. Only salt-user pub/authentication key needs to be distributed to the minions saltuser and only allow the salt master to use the key.

And on top of that salt master would only have a limited number of people using it.

See also http://blog.siphos.be/2015/07/restricting-even-root-access-to-a-folder/

---

In Ansible the hacker will need to break into the users secure vault, before he can do anything. You should not assume sysadmins are unhackable and that they carefully follow security guidelines.

Not sure how this password on the vault (store on secure server or a laptop) is more protected than any other password after hacking an individual sysadmin.. Once you can copy the vault you can do a brute force attack on AWS gain master password and all the passwords stored in the vault after hacking an individual sysadmin..

Their is also whats called onion approach to security i.e. layers. Second authentication like RSA Token or Google Authentication etc.

Both Salt and Ansible copy files to the target systems, if a person breaks into the Master or (Ansible laptop with private key) then updates the Salt or Ansible code, they just need to wait until someone runs Salt or Ansible to execute a remote worm.

It's always good to perform risk to benefit analysis on options before deciding any particular path.

I just put a suggest out their people can use it or wait for salt-ssh to support individual users the Ansible way

[teliduxing004]

stderr': 'sudo: no tty present and no askpass program specifiedn',
'stdout': 'ERROR: sudo expected a password, NOPASSWD required'},

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[xuhcc]

Keep it open.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[djneades]

Please keep this issue open.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[johncollaros]

Waiting for an update on this issue - key for boot-straping new systems.

[fabfurnari]

This is a very important feature to add!