Hi Allen, It may be worth regenerating the client's machine-id, as that's how Uyuni/Salt identifies machines. My assumption is that the salt key is linked to the machine id in Uyuni from the previous registration. I could be wrong and others may give you better advice, but FWIW: these are the commands I've added to my bootstrap.sh to do that, but they can be run manually before bootstrapping. They'll remove the existing id on a EL machine and regenerate it. echo "Clearing machine-id to ensure no dupes" rm -f /etc/machine-id rm -f /var/lib/dbus/machine-id dbus-uuidgen --ensure systemd-machine-id-setup -----Original Message----- From: Allen Beddingfield <allen@ua.edu> Sent: 26 August 2022 06:01 To: users@lists.uyuni-project.org Subject: [EXTERNAL EMAIL] "The salt master has cached the public key for this node" error. [You don't often get email from allen@ua.edu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] I have a salt minion that I deleted (by going to "salt keys" in the web ui), stopped the salt minion process on the server, changed the hostname, and re-ran the bootstrap script. It shows up in the lists of keys, and I have selected to approve it, but it never actually turns blue so that it can be selected. The minion on the server is giving this error: "The Salt Master has cached the public key for this node, this salt minion will wait for 10 seconds before attempting to re-authenticate". I've also tried deleting it with salt-key -d, with the same result. I have encountered this before on a SUSE Manger server, and the resolution was to remove the corresponding entry from /var/lib/salt/.ssh/known_hosts, which doesn't seem to exist on my Uyuni 2022.06 server. Any ideas on how to proceed? FYI, the minion is running CentOS 7.x. Thanks. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen@ua.edu