salt: salt-key can't delete a single key if name is duplicated

Description of Issue/Question

Sometimes when replacing instances outside of salt-cloud, I find myself in a situation where old minion keys are left over on the master and need to be cleaned up. Since a new key was created for the replacement host with the same name, salt-key is unable to remove just the old host key. The only known work-around is to have salt-key delete both keys, and then restart the minion on the new host to have it send through a new key, which then also has to be manually accepted.

Setup

Launch a host using EC2 or whatever using salt-cloud. Nuke it from outside salt-cloud. Launch a new host using salt-cloud. You will end up with multiple keys with different fingerprints but the same name.

$ sudo salt-key -L
Accepted Keys:
salt-master0.internal
vpn0.internal
Denied Keys:
salt-master0.internal
Unaccepted Keys:
Rejected Keys:
$ sudo salt-key -d salt-master0.internal
The following keys are going to be deleted:
Accepted Keys:
salt-master0.internal
Denied Keys:
salt-master0.internal
Proceed? [N/y] y
Key for minion salt-master0.internal deleted.
Key for minion salt-master0.internal deleted.
$

If I try to delete by fingerprint:

$ sudo salt-key -d df:18:84:7b:e3:2b:fa:e8:cc:af:c8:80:92:78:79:51:38:54:d2:0f:cd:31:55:2d:f7:00:6f:23:35:50:fd:00
The key glob 'df:18:84:7b:e3:2b:fa:e8:cc:af:c8:80:92:78:79:51:38:54:d2:0f:cd:31:55:2d:f7:00:6f:23:35:50:fd:00' does not match any unaccepted keys.

AFAIK there’s no way to just delete the old key when such naming conflicts exist using salt-key, but salt-cloud will happily allow such conflicts to be created.

Steps to Reproduce Issue

Nothing beyond the steps in the Setup section.

Versions Report

salt --versions-report
Salt Version:
           Salt: 2017.7.2
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.5.3
      docker-py: Not Installed
          gitdb: 2.0.0
      gitpython: 2.1.1
          ioflo: Not Installed
         Jinja2: 2.8
        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
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.13 (default, Nov 24 2017, 17:33:09)
   python-gnupg: 0.3.9
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.1
        timelib: Not Installed
        Tornado: 4.4.3
            ZMQ: 4.2.1
 
System Versions:
           dist: debian 9.3 
         locale: UTF-8
        machine: x86_64
        release: 4.9.0-5-amd64
         system: Linux
        version: debian 9.3

The issue has been around for a long time. I thought I would have already had a bug report open about this, but either I forgot to or can’t find it.

About this issue

Original URL
State: open
Created 6 years ago
Reactions: 5
Comments: 16 (11 by maintainers)

Most upvoted comments

Been another year, the above workaround is functional enough, but this seems like something that newbies would run into.

“Used terraform to spin up a second server with the same hostname as a new target to move my apps to, but now can’t do stuff with it because Salt denied the key due to duplicate minion_id & now I can’t un-deny it…”

mdschmitt on Nov 10, 2021

So salt-key -l denied -d salt-master0.internal would only delete the denied keys with that name.

For the record, this doesn’t work. It only lists all denied keys but doesn’t offer to (or actually does) delete the key.

mbunkus on Jul 5, 2018

You can specify the type of minions that you want with -l or --list

So salt-key -l denied -d salt-master0.internal would only delete the denied keys with that name.

Does this work for you?

Thanks, Daniel

gtmanfred on Feb 15, 2018

This doesn’t really address the cli for salt-key not being able to delete only the denied key, but its a workaround.

If you’re able to access the salt-master, which I assume you are, then the denied keys are located here: /etc/salt/pki/master/minions_denied

I just deleted the one I wanted to delete.

isaachui on Jun 26, 2020

Yeah, that is really reasonable.

I am marking this as a feature request.

Thanks! Daniel

gtmanfred on Feb 15, 2018