saltstack密钥认证必须显式接受minion公钥，否则test.ping必失败；关键在于公钥是否进入master的minions_pre目录，而非配置文件是否正确，常见问题多源于连接未建立或残留密钥干扰。
SaltStack 的密钥认证不是“配完就能通”，而是必须显式接受 minion 公钥，否则 salt '*' test.ping 一定失败，返回 Minion did not return. [Not connected]。关键不在配置文件写对没写对，而在公钥是否进入 /etc/salt/pki/master/minions/ 目录。
minion 启动后为什么 master 看不到 Unaccepted Keys？
常见现象：minion 已启动、systemctl status salt-minion 显示 active，但 salt-key -L 输出里 Unaccepted Keys 为空，甚至整个命令报错或卡住。
- 检查 minion 是否真连上了 master：
ss -tnp | grep :4505—— 如果没看到 ESTABLISHED 连接，说明 minion 根本没连上，Unaccepted Keys自然不会出现 - 确认 minion 配置里
master:地址可解析且端口可达（默认ret_port: 4506用于握手，publish_port: 4505用于后续通信） - 检查 minion 日志：
journalctl -u salt-minion -n 50 -f，重点看是否有Failed to connect to master或Authentication failed - 注意：minion 启动时若无法连接 master，会静默重试，默认不报错也不生成待认证公钥；只有成功建立 TCP 连接并完成初始 handshake，才会把
minion.pub发过去
salt-key -a 不生效的三个典型原因
执行 salt-key -a web137 后再跑 salt-key -L，发现 web137 仍出现在 Unaccepted Keys 里，不是命令输错了，而是底层状态没变。
-
minion_id和实际发送的公钥名不一致：minion 默认用hostname，但如果你在/etc/salt/minion里写了id: web137，又没删旧密钥，它可能还在用旧hostname发公钥 —— 查看/etc/salt/pki/minion/minion.pub对应的文件名（无扩展名）是否真为web137 - master 没读到新公钥：确认
/etc/salt/pki/master/minions_pre/下是否存在对应文件（如web137），没有就说明 minion 根本没送达；有但salt-key -L不显示，可能是 master 进程没加载新内容，重启salt-master再试 - 权限问题：
/etc/salt/pki/master/及其子目录必须属主root:root，且minions_pre/目录权限不能高于700，否则 master 拒绝读取
删除旧密钥后重启 minion 仍连不上原 master
你按标准流程删了 /etc/salt/pki/minion/minion.pem 和 /etc/salt/pki/minion/minion.pub，重启服务，但 salt-key -L 里还是看不到新 key，或者出现 Denied Keys。
- 漏删
/etc/salt/pki/minion/minion_master.pub：这是 master 上次认证后下发的公钥，如果它还存在，minion 会尝试用它验证旧 master 身份，导致握手失败，直接跳过公钥上传阶段 - minion 缓存了旧 master IP：检查
/var/cache/salt/minion/minion_data.p，有时它会记住上次连接成功的 master 地址，删掉这个缓存文件再重启 - master 端已有同名 key 在
Denied Keys：先运行salt-key -d web137清掉拒绝记录，否则 minion 重连时会被立即拒收
真正麻烦的从来不是“怎么加”，而是“为什么没加进去”——密钥认证卡住时，90% 的问题出在连接层或残留状态，而不是 YAML 配置语法。盯住 /var/log/salt/minion 和 /var/log/salt/master 里的 ERROR 行，比反复改 auto_accept: True 有用得多。
