salt-ssh: run as non-root when using password auth

[Supermathie]

When using salt-ssh as a normal user I should be able to use password authentication without requiring the generation of keys.

→ ls -al /etc/salt/roster
-rw-r--r-- 1 root root 518 Feb 27 11:50 /etc/salt/roster

→ salt-ssh monster -r 'echo I AM ALIVE'
salt-ssh could not be run because it could not generate keys.

You can probably resolve this by executing this script with increased permissions via sudo or by running as root.
You could also use the '-c' option to supply a configuration directory that you have permissions to read and write to.

Version:
salt-ssh 2014.7.1+ds-3precise1

[rallytime]

Thanks for the report @Supermathie. I am not very familiar with the salt-ssh code or process/procedures, but I bet @basepi can comment about this particular issue much better that I can.

[basepi]

It may be a deeper problem than key generation. We will also need access to the cache directory and whatnot.

That said, key generation should probably be optional. Does it try to generate keys if you pass in --askpass? That's the way to do password authentication.

[Supermathie]

In this case I have a password specified in a roster file.

○ → salt-ssh gallifrey test.ping
salt-ssh could not be run because it could not generate keys.

You can probably resolve this by executing this script with increased permissions via sudo or by running as root.
You could also use the '-c' option to supply a configuration directory that you have permissions to read and write to.

○ → salt-ssh gallifrey --askpass test.ping
Password: 
salt-ssh could not be run because it could not generate keys.

You can probably resolve this by executing this script with increased permissions via sudo or by running as root.
You could also use the '-c' option to supply a configuration directory that you have permissions to read and write to.

[basepi]

Ah, good to know. Yes, we should make this work.

[bertjwregeer]

It would be awesome as well if it would print what path it was trying to create, so that it would be easier to debug issues with Saltfile and having the master contain the right paths for everything.

[basepi]

Ya, that probably would be good. In this case it should be in /etc/salt/pki, just FYI.

[bertjwregeer]

In my case due to not setting the root_dir in my master so it was trying to write to /salt_root rather than ./salt_root.

Figured it out by printing the original exception rather than just catching it and raising another one.

[basepi]

Ah, I understand. Glad you got it figured out.

[8BitAce]

It should be noted that the documentation currently seems to state this is possible:
https://docs.saltstack.com/en/latest/topics/ssh/#running-salt-ssh-as-non-root-user

However running salt-ssh with the following Saltfile:

salt-ssh:
  config_dir: ./config
  log_file: ./salt.log
  pki_dir: ./config/pki
  cache_dir: ./cache

Produces the same message. So likely there is something going on deeper down.

~/pisalt $ salt-ssh '*' test.ping
salt-ssh could not be run because it could not generate keys.

You can probably resolve this by executing this script with increased permissions via sudo or by running as root.
You could also use the '-c' option to supply a configuration directory that you have permissions to read and write to.

This seems like a rather large flaw as I'd rather keep all configs in a single user-owned directory so that I can manage them in git.

[bertjwregeer]

In your roster file you can specify the path to a key...

dnstest:
    host: 10.10.10.12
    user: salty
    sudo: True
    priv: ~/.ssh/configmgmt

So if you have an appropriate file somewhere in your tree, you can pass it directly. In my case I share my salt-ssh setup with a lot of others users, and they have their own keys. We update a central authorized_keys file with all of our users keys, that is stored in git for version control. Then existing users can add new entries/remove them as necessary.

The user has their own private key, which they symlink to ~/.ssh/configmgmt and now we don't have private keys in our git repo.

Anyway, give this work-around a shot.

[8BitAce]

Great! This strategy works for the time being.
It took me a few hours of digging through the code to realize I also needed to set pki_dir in the master config file and not Saltfile. And as you mentioned earlier I then also had set root_dir.

So long story short it seems salt-ssh could use a bit of tweaking in how it handles configuration options.
This is something I might be able to help with if I can find the time, but overall shouldn't be too hard of a fix.

[ashokrajar]

Here is how I worked around the problem,

$ tree
.
├── Saltfile
├── config
│   ├── master
│   └── roster

$ cat Saltfile
salt-ssh:
roster_file: ./config/roster
config_dir: ./config
ssh_log_file: /tmp/salt-ssh-log.log
ssh_priv: agent-forwarding
ssh_max_procs: 10
ssh_wipe: True
ssh_rand_thin_dir: True
ssh_user: ubuntu
ssh_sudo: True
ssh_tty: True

$ cat config/master
cachedir: /tmp/salt

$ cat config/roster
minion01:
host: minion01.domain.com
grains:
environment: dev

$ salt-ssh 'dev-minion01' state.apply

[dreampuf]

@ashokrajar Thanks. Your comment solves my problem.

[falenn]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a temporary error. The following address(es) deferred:

curtis.l.[email protected]
Domain imwiz.com has exceeded the max emails per hour (156/150 (104%)) allowed. Message will be reattempted later

------- This is a copy of the message, including all the headers. ------
Received: from github-smtp2-ext4.iad.github.net ([192.30.252.195]:50295 helo=github-smtp2a-ext-cp1-prd.iad.github.net)
by box969.bluehost.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.87)
(envelope-from [e-mail])
id 1cnrXO-0000jd-5Q
for [email protected]; Tue, 14 Mar 2017 12:51:19 -0600
Date: Tue, 14 Mar 2017 11:51:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
s=pf2014; t=1489517463;
bh=XLnrmuc88hVTCK3ROe6y/1ZiUnUaAZ/ldk1UypCRVQQ=;
h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
List-Archive:List-Post:List-Unsubscribe:From;
b=PLFuI8jrokSvCRseNT9ZGZkvd/PYCYCXExvwhzlUe3EkE7MNpQwctTQKYRYm4r0Q7
ibTQSSy6bn+AQwD2ch89QG0ZvqHJwkc0BK14UXn3SfE6X5xgXLDPYrW8Q/JSHHZdgE
D2BsS/SgG7P7431+bUBErxcP868bSPXQZ6oaLs8w=
From: Dreampuf [e-mail]
Reply-To: saltstack/salt [e-mail]
To: saltstack/salt [e-mail]
Cc: Subscribed [e-mail]
Message-ID:
In-Reply-To:
References:
Subject: Re: [saltstack/salt] salt-ssh: run as non-root when using password
auth (#21118)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_58c83b975ccc8_6a0f3fbf6e0ffc2c116772";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: dreampuf
X-GitHub-Recipient: falenn
X-GitHub-Reason: subscribed
List-ID: saltstack/salt
List-Archive: https://github.com/saltstack/salt
List-Post: [e-mail]
List-Unsubscribe: ,
https://github.com/notifications/unsubscribe/AAq2Csb5MT-W3BGOWp5yzRXKASyOgQcpks5rluGXgaJpZM4DnHkv
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: [email protected]
X-Spam-Status: No, score=-1.3
X-Spam-Score: -12
X-Spam-Bar: -
X-Ham-Report: Spam detection software, running on the system "box969.bluehost.com",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
root@localhost for details.

Content preview: @ashokrajar Thanks. Your comment solves my problem. -- You
are receiving this because you are subscribed to this thread. Reply to this
email directly or view it on GitHub: https://github.com/saltstack/salt/issues/21118#issuecomment-286523398
[...]

Content analysis details: (-1.3 points, 4.0 required)

pts rule name description

---

-0.0 SPF_PASS SPF: sender matches SPF record
0.7 HTML_IMAGE_ONLY_20 BODY: HTML: images with 1600-2000 bytes of words
0.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
-2.8 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[192.30.252.195 listed in wl.mailspike.net]
0.9 AWL AWL: Adjusted score from AWL reputation of From: address
X-Spam-Flag: NO

----==_mimepart_58c83b975ccc8_6a0f3fbf6e0ffc2c116772
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit

@ashokrajar Thanks. Your comment solves my problem.

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/saltstack/salt/issues/21118#issuecomment-286523398
----==_mimepart_58c83b975ccc8_6a0f3fbf6e0ffc2c116772
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit

@ashokrajar Thanks. Your comment solves my problem.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58c83b975ccc8_6a0f3fbf6e0ffc2c116772--

[centic9]

This seems to be mostly a duplicate of #9474, a similar workaround is described there as well.

[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.