[BUG] Terraform roster overrides provided "priv" entry.

Description

Despite the priv attribute being provided from the Terraform provider, the roster file overrides this with either ~/.ssh/id_rsa (if ssh_use_home_key is True), the value from ssh_priv (global) config if set, or the default value defined as os.path.abspath(os.path.join(__opts__["pki_dir"], "ssh", "salt-ssh.rsa")).

If a "salt_host" entry from Terraform contains a truthy priv entry, that should supercede the general configuration.

Setup

This is using the terraform roster, which determines the roster based on a Terraform tfstate file. The salt-ssh config used:

# Saltfile
salt-ssh:
    roster: terraform
    roster_file: /opt/saltssh/roster.tfstate
    config_dir: /opt/saltssh/etc
    ssh_log_file: /opt/saltssh/saltssh.log
    ignore_host_keys: True
    ssh_wipe: True

And here is a relevant excerpt from a tfstate file as an example:

# roster.tfstate
{
  "version": 4,
  "terraform_version": "1.3.7",
  ...
  "resources": [
    ...
    {
      "mode": "managed",
      "type": "salt_host",
      "name": "db_minion",
      "provider": "provider[\"registry.terraform.io/dmacvicar/salt\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "cmd_umask": null,
            "host": "<PUBLIC_IP_HERE>",
            "id": "db",
            "minion_opts": null,
            "passwd": ">INITIAL_ROOT_PASS_HERE>",
            "port": null,
            "priv": "/opt/saltssh/ssh_private/saltssh_key",  # <-- Explicit "priv" value
            "salt_id": "db",
            "sudo": true,
            "sudo_user": null,
            "thin_dir": null,
            "timeout": 60,
            "tty": null,
            "user": "root"
          },
          ...
          "dependencies": [
            "linode_instance.db-postgresql"
          ]
        }
      ]
    }
  ],
  ...
}

Please be as specific as possible and give set-up details.

• on-prem machine
• VM (Virtualbox, KVM, etc. please specify)
• VM running on a cloud service, please be explicit and add details
• container (Docker)
• or a combination, please be explicit
• jails if it is FreeBSD
• classic packaging
• onedir packaging
• used bootstrap to install

Steps to Reproduce the behavior

Despite SSH access being correctly configured, running salt-ssh 'db' test.version will fail with the following message:

# Output truncated
/opt/saltssh # salt-ssh -l info '*' test.version
[INFO    ] Loading Saltfile from '/opt/saltssh/Saltfile'
[INFO    ] {'salt_id': 'db', ..., 'priv': '/opt/saltssh/ssh_private/saltssh_key', ...'}
Permission denied for host db, do you want to deploy the salt-ssh key? (password required):
[Y/n]

Using a flat roster file version of this works as expected, so the key used is definitely correct. For this example, it looks like this:

db:
    host: <SNIP>
    user: <SNIP>
    sudo: True
    priv: /opt/saltssh/ssh_private/saltssh_key 

Expected behavior

The command should complete successfully.

Suggested code change

In the _add_ssh_key function of salt/roster/terraform.py (L119), if "priv" is present (and truthy) in the target the function can perform an early out.

I will create an example of this in a fork shortly.

Screenshots
N/A

Versions Report

Salt Version:
          Salt: 3005.1

Dependency Versions:
          cffi: 1.14.6
      cherrypy: unknown
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 3.1.0
       libgit2: 1.1.0
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: 2.17
      pycrypto: Not Installed
  pycryptodome: 3.9.8
        pygit2: 1.6.1
        Python: 3.7.13 (default, Apr 20 2022, 03:16:50)
  python-gnupg: 0.4.8
        PyYAML: 5.4.1
         PyZMQ: 18.0.1
         smmap: Not Installed
       timelib: 0.2.4
       Tornado: 4.5.3
           ZMQ: 4.3.1

System Versions:
          dist: alpine 3.14.6
        locale: UTF-8
       machine: x86_64
       release: 5.10.16.3-microsoft-standard-WSL2
        system: Linux
       version: Alpine Linux 3.14.6

Additional context
Add any other context about the problem here.

Start in salt/roster/terraform.py at the _add_ssh_key function around line 119, then reproduce with the Terraform roster and a tfstate salt_host containing a truthy priv value. Verify how roster values are combined with ssh_use_home_key, ssh_priv, and the default key path. Done means salt-ssh uses the explicit Terraform priv path and the example command completes successfully.