必须手动接受minion密钥才能通信，因salt采用公钥认证机制：minion首次连接时提交公钥，master需用salt-key -a显式接受，否则无法建立受信通信，导致salt '*' test.ping无响应或超时。
直接装官方仓库的 salt-master 和 salt-minion，别用 EPEL；master 启动后必须手动接受 minion key 才能通信，否则 salt '*' test.ping 永远返回空或超时。
为什么不用 EPEL 仓库装 SaltStack
EPEL 提供的 salt-master 版本老旧（如 CentOS 7 上默认是 2015.8），不支持现代 state 语法、state.apply 的默认行为变更，且与新版 minion 握手失败概率高。官方仓库已全面转向 py3 构建，兼容 Python 3.6+ 和 ZeroMQ 4.3+。
实操建议：
- CentOS/RHEL 7：运行
yum install https://repo.saltproject.io/py3/redhat/7/x86_64/latest/salt-py3-repo-latest.el7.noarch.rpm，再yum install salt-master salt-minion - CentOS/RHEL 8/9：改用
dnf，URL 中把7换成8或9 - 跳过
epel-release安装——它不是必需的，反而可能引发 yum repo 冲突
/etc/salt/minion 配置最容易漏掉的三件事
只写 master: 192.168.1.100 不够，minion 启动后大概率连不上，常见现象是 tail -f /var/log/salt/minion 里反复打印 Retrying connect to master。
必须确认以下三项：
-
master:行末不能有空格或 tab，冒号后**必须且只能有一个空格**，例如master: 192.168.1.100（不是master:192.168.1.100） - 如果用主机名（如
master.test.com），确保 minion 能nslookup或ping通，且/etc/hosts里有对应条目 - 检查
id:是否被注释——若未显式设置，minion 会用自己的 hostname 当 ID；但若 hostname 是localhost.localdomain，master 会拒绝签名
salt-key 认证失败的典型错误和绕过方法
执行 salt-key -L 看不到 minion，或 salt-key -a minion-id 后仍无法 test.ping，多数因证书路径或权限错乱。
排查要点：
- minion 启动后，检查
/etc/salt/pki/minion/minion.pub是否存在；不存在说明 key 生成失败，删掉整个/etc/salt/pki/minion/目录并重启 minion - master 上执行
salt-key -L时，若输出为空，先确认/etc/salt/pki/master/下有master.pem和master.pub；没有则systemctl restart salt-master强制重建 - 不要用
salt-key -A一键全接受——生产环境必须逐个-a，否则任意能连到 4505/4506 端口的机器都能伪装 minion
远程命令执行前必须验证的两个端口
master 默认监听 4505（publish）和 4506（ret），但仅开放 4505 不够——minion 回传结果走的是 4506，防火墙封掉它会导致命令“发出去了但收不到返回”，现象是 salt '*' cmd.run 'uptime' 卡住或超时。
操作清单：
- master 主机上跑
ss -tlnp | grep ':450[56]'，确认两个端口都处于LISTEN状态 - 如果用了 firewalld：
firewall-cmd --permanent --add-port=4505/tcp和firewall-cmd --permanent --add-port=4506/tcp，再 reload - iptables 用户注意：规则顺序很重要，
-I INPUT 1插入最前，避免被后面的REJECT拦截
真正卡住的地方往往不在安装步骤，而在 minion 启动瞬间是否成功生成密钥、master 是否真的收到了那把 minion.pub——日志里没报错不等于认证成功，salt-key -L 输出必须出现在 Accepted Keys 下才算过关。
