[BUG] salt-ssh no longer applies roster defaults to hosts not explicitly listed in the roster

[nergdron]

Description used to be able to just run salt-ssh against any host using the configured roster defaults by hostname. at some point in the recent past, this has broken, so now all hosts have to be manually defined in the roster file.

Setup

Steps to Reproduce the behavior

• run salt-ssh against a host not explicitly defined in the roster file
• watch it not use the roster defaults and fail

roster_defaults: priv: agent-forwarding sudo: True tty: True user: tessa

$ salt-ssh testhost state.apply
[DEBUG   ] LazyLoaded roster_matcher.targets
[DEBUG   ] Matched minions: {}
[DEBUG   ] LazyLoaded roots.envs
[DEBUG   ] Could not LazyLoad roots.init: 'roots.init' is not available.
[DEBUG   ] Updating roots fileserver cache
[DEBUG   ] In saltenv 'base', looking at rel_path '_grains/dirs.py' to resolve 'salt://_grains/dirs.py'
[DEBUG   ] In saltenv 'base', ** considering ** path '/tmp/.salt-root/var/cache/salt/master/files/base/_grains/dirs.py' to resolve 'salt://_grains/dirs.py'
[DEBUG   ] LazyLoaded local_cache.prep_jid
[DEBUG   ] Adding minions for job 20210128041157634134: ['c1.sudo.prv']
[DEBUG   ] LazyLoaded state.apply
[DEBUG   ] Performing shimmed, blocking command as follows:
test.opts_pkg
[DEBUG   ] Executed SHIM command. Command logged to TRACE
[DEBUG   ] Child Forked! PID: 1560248  STDOUT_FD: 11  STDERR_FD: 13
[DEBUG   ] VT: Salt-SSH SHIM Terminal Command executed. Logged to TRACE
[DEBUG   ] RETCODE c1.sudo.prv: 255
[DEBUG   ] SHIM retcode(255) and command: 
Permission denied for host testhost, do you want to deploy the salt-ssh key? (password required):
testhost:
    ----------
    _error:
        Failed to return clean data
    retcode:
        255
    stderr:
        root@testhost: Permission denied (publickey,password).
    stdout:

Expected behavior I expected it to use my username and sudo to run the states against the remote host. not just try root and fail.

Versions Report

salt --versions-report

```yaml Salt Version: Salt: 3002.2 Dependency Versions: cffi: 1.14.3 cherrypy: Not Installed dateutil: 2.8.1 docker-py: 4.3.1 gitdb: Not Installed gitpython: Not Installed Jinja2: 2.11.2 libgit2: Not Installed M2Crypto: Not Installed Mako: 1.1.4 msgpack: 0.6.2 msgpack-pure: Not Installed mysql-python: Not Installed pycparser: 2.20 pycrypto: 2.6.1 pycryptodome: 3.9.8 pygit2: Not Installed Python: 3.8.6 (default, Sep 25 2020, 09:36:53) python-gnupg: Not Installed PyYAML: 5.3.1 PyZMQ: 19.0.1 smmap: Not Installed timelib: Not Installed Tornado: 4.5.3 ZMQ: 4.3.2 System Versions: dist: ubuntu 20.10 groovy locale: utf-8 machine: x86_64 release: 5.8.0-40-lowlatency system: Linux version: Ubuntu 20.10 groovy ```

Additional context Add any other context about the problem here.

[Ch3LL]

I'm not able to replicate this. Which Salt-SSH roster are you using?

[nergdron]

I'm using the default static yaml roster. hosts in the roster correctly get the defaults, but hosts not in the roster don't. so for instance, if I have a new host on my network and run salt-ssh newhost cmd.run ls, it fails because it tries to ssh as my username, not as the username set in roster_defaults.

it's easy to demonstrate by putting an entry for the host with its hostname in the roster, and then comparing the run with the hostname vs the IP. the hostname, which is in the roster, executes correctly. but the IP always dies with:

Permission denied for host my.ip.address, do you want to deploy the salt-ssh key? (password required):
[Y/n]

I'm currently running on Arch, with salt 3004.

[Ch3LL]

Thanks for clarifying. I am able to replicate this now. Do you happen to know in which version it was working?

[nergdron]

I don't remember, sorry. as you can see, I filed this in Jan of last year, and it was broken for a little while before that, so hopefully that'll help you bisect it.

[Flashdown]

Well I got the same, I guess the last time roster_defaults may was working must have been around salt 3000 to 3001 but unsure. Checked my git change history and now I would bet that in 3001.1 or 3000.3 it must have been working. hope that helps.

[max-arnold]

Duplicate of #58440