pki keys are still created with salt-ssh and ssh_use_home_key

[mitar]

When I use salt-ssh with ssh_use_home_key: True set in master configuration, I see that salt-ssh.rsa and salt-ssh.rsa.pub are still created inside the pki directory, but not really used it seems. This is confusing. I would suggest that files are not created if not needed.

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

[Ch3LL]

@mitar this is expected behavior because if auth fails, it will ask to copy over the salt-ssh key. For example it will look something like this:

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

I would clarify this as expected behavior since we want to give the option to deploy the salt-ssh key.

[Ch3LL]

Although I just thought we could probably just create the key when the user selects yes or when specifying in the config to use the key. I will approve as a feature request.

[mitar]

Thanks! Because in my setup we do not want to use or deploy any new keys to servers. If a key fails, then this is a failure and this is it.

[mitar]

BTW, is there a config to say to not use the key? How does one specify in config to use the key?

[Ch3LL]

@mitar i dove into the code and found this: if not isinstance(ret[host], dict) or self.opts.get('ssh_key_deploy'):. the ssh_key_deploy option added from the --key-deploy argument to salt-ssh.

Also looking at the code I found if you have ssh_key_deploy: True in your master config and do not have a passwd set or ssh_passwd set it will just fail. Is that the same as you? Now i'm not sure if this is the behavior we exactly want. But if you could confirm you see the same behavior that woudl be great.

[mitar]

I am not sure what are you asking here. This is an example of my master file I am using.

[mitar]

Should I set ssh_key_deploy to False and see if keys are still generated, is that what you are proposing?

[Ch3LL]

I don't need you to try to attempt this i'm confident of the behavior. Sorry for sidetracking the issue there. Just saw some behavior when setting ssh_key_deploy: True where it still does create the keys but it doesn' ask to copy them over atleast.

Apologies I was trying to answer your question:

How does one specify in config to use the key?

I thought that was the option (ssh_key_deploy/--key-deploy) but it looks liek i was wrong From salt-ssh man page:

    --key-deploy        Set this flag to attempt to deploy the authorized ssh
                        key with all minions. This combined with --passwd can
                        make initial deployment of keys very fast and easy.

Looking at the code I believe it attempts to default to copying over that salt-ssh key if permission denied is in the return results. So I don't believe there is an option for this

[mitar]

My current workaround: pki_dir: /tmp/salt-pki

I do not need those keys, I do not deploy them (they are not really sensitive), so I can just create them there.

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

Please reopen this issue.

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