Salt: Use current user's username when connecting with salt-ssh

[mitar]

Description of Issue/Question

I would like to have a roster file where I can specify that for username, salt-ssh should use local user's username. So that roster file can be shared across team members. And we have the same username on our local machines than on servers.

Setup

I have a config/roster file for salt-ssh which has entries like:

server1:
  host: server1.example.com
  port: 22
  user: mitar
  sudo: True

Ideally, I could do something like:

server1:
  host: server1.example.com
  port: 22
  user: $USER
  sudo: True

Versions Report

Salt Version:
           Salt: 2016.11.1

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.9.4
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.10 (default, Jul 14 2015, 19:46:27)
   python-gnupg: 0.3.8
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.4.2
            ZMQ: 4.1.5

System Versions:
           dist:   
        machine: x86_64
        release: 14.5.0
         system: Darwin
        version: 10.10.5 x86_64

[sergeizv]

A roster file may be templated with Jinja2, but I see no way accessing environment variables from it. However, it might be useful to specify a user via a variable:

{% set username = 'foobar' %}

or get it from the master's config

{% set username = opts['user'] %}

and then

server1:
  host: server1.example.com
  port: 22
  user: {{ username }}
  sudo: True

If modules were available when templating a roster file, it could be

{% set username = salt['environ.get']('USER') %}

[Ch3LL]

@mitar does the jinja that @sergeizv posted work for you use case?

[mitar]

No, because it seems there is no way to access to the environment variable? I would like to have both roster and master files fixed for people deploying things. The only thing which is different is their username with which they can SSH into the system.

[The-Loeki]

FWIW your issue inspired me to add environment support to the new cache roster I wrote (#40284).

Without knowing too much of your details I will strongly and warmly suggest deploying regular salt minions. Salt-SSH has it's many uses, but for regular & teambased usage you're going to have so much more fun doing a real salt master setup, I promise you.

[mitar]

Ooo, great. In our case we prefer this setup because then we as an open source project can have a repository with all salt data and configuration, so that contributors can contribute. And then we can keep the same roster and everything, and just add people's SSH key on the server if we want them to be able to deploy.

[The-Loeki]

https://gist.github.com/The-Loeki/23ab504333d6d6546a8d1d106366dce6

@mitar recently I've been toying with getting Salt-SSH to run as a fully standalone application on workstations.
This script is rough but it shows you how we do it; it can easily be modified for your needs. Note by the way we use SSH Agent for accessing the keys.

And note also a few of the speedbumps I've had on the way ;) Salt-SSH definitely isn't made for this stuff (yet) and requires some bludgeoning to get right

[jknightstreamme]

👍

[Ch3LL]

Does this new roster work for your use case? Are we okay to close this now or are there any other concerns? It seems that roster makes use of the sdb env module.

[mitar]

I have not yet tested this, but if one can access environment that this does satisfy our needs.

[Ch3LL]

Okay I will go ahead and close and please create a new issue if it does not work with teh details as to why its not working. Thanks

[mitar]

Hm, looking into this, but I am not sure how exactly is this used? @The-Loeki

So if I currently have this entry in my roster file:

foobar:
  host: foorbar.example.com
  port: 22
  user: mitar
  sudo: True

How do I convert it so that mitar is read from the environment?

[The-Loeki]

@mitar I had some discussion in my PR regarding that environment support, and eventually the Salt powers decided against directly supporting it.

I've modified the roster and docs to boot; it should now be done through sdb:
https://docs.saltstack.com/en/develop/ref/roster/all/salt.roster.cache.html#module-salt.roster.cache

Bear in mind this is only in upcoming Nitrogen release

[mitar]

Not sure how this would then be used. Would this work?

foobar:
  host: foorbar.example.com
  port: 22
  user: sdb://osenv/USER
  sudo: True

If this is not implemented, maybe the issue should be reopened?

[mitar]

Why is salt['environ.get']('USER') not supported in flat roster format? So why are modules not available to the renderer?

[babilen5]

I really don't consider this issue solved as it requires users to use the cache roster which necessitates them to have a master in place already.

Much like the struggles documented in https://github.com/saltstack/salt/issues/41256 salt should allow users to write parameterised rosters so that users can share configuration. It's annoying that one has to specify the user in the first place when standard SSH has been configured to work perfectly in ~/.ssh/config already.

[nergdron]

Just ran into this as well experimenting with salt-ssh, and after doing a lot of Ansible lately, it's pretty surprising that there isn't an easy way to just say "salt-ssh should use the username of the account it's being run as" from the Saltfile or some other source of configuration. Definitely a frustrating barrier to entry with salt-ssh.

[babilen5]

@nergdron Exactly!

[holmboe]

@Ch3LL it seems this should be reopened since there is no solution or fix provided?

[rossengeorgiev]

One way to do this is ssh-ssh --user=$USER --askpass .......

@Ch3LL I've noticed that --user is not documented on https://docs.saltstack.com/en/latest/ref/cli/salt-ssh.html

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

[mitar]

--user seems to me as documented. But that sets default user, not overrides the user in the roaster.

Moreover, I think it should be still possible to use something like salt['environ.get']('USER') in roaster file. Then those files can be easier to distribute and use.

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

[mitar]

Unstale.

[stale[bot]]

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

[tkwilliams]

For anyone looking for the INSANELY quick fix for this, do what I do and bail on Jinja.
For pretty much as long (7+ years) as I've been using Salt, I've set Mako as my default templating engine, simply because Mako gives you REAL PYTHON under the hood, instead of the thin python-like goop that is Jinja.

For instance, the simple solution here is to take your roster file, and:

$ cat roster
#!mako|yaml
<%
  import getpass
  user = getpass.getuser()
%>

host1.test.local:
  user: ${user}
host2.test.local:
  user: ${user}

... etc ...

See, trivial when you use Mako. You can of course set any other values you want too (minion_opts or what-have-you). Note that /etc/salt/master(,.d/*} are NOT parsed by templating, so you can't set this up via roster_defaults - that would be extra-swell but doesn't work, the last I checked.

[tkwilliams]

@mitar ^^^ :)

[mitar]

Yes, a very nice hack. :-)