tftpd-hpa 是 linux 下最稳妥的 tftp 服务实现，因其维护活跃、兼容主流发行版、默认非 root 运行且具备 --secure 目录限制等安全机制，能有效规避 tftp 无认证风险。
为什么 tftpd-hpa 是 Linux 下最稳妥的选择
因为系统级 TFTP 服务基本就这一个维护活跃、兼容主流发行版（Debian/Ubuntu/CentOS/RHEL）的实现，xinetd + tftpd 组合已过时且容易权限失控。它默认以非 root 用户运行，能规避 TFTP 协议本身无认证带来的高危风险。
常见错误现象：Permission denied 错误不是路径没写对，而是 tftpd-hpa 进程根本没权限读取你指定的目录；或者客户端收到 Timeout，其实是防火墙拦了 UDP 69 端口，不是服务没起来。
- 安装命令：Debian/Ubuntu 用
sudo apt install tftpd-hpa，CentOS/RHEL 用sudo yum install tftp-server（注意包名不同） - 核心配置文件是
/etc/default/tftpd-hpa，不是/etc/xinetd.d/tftp -
TFTP_DIRECTORY必须是绝对路径，且该目录属主需为tftp用户（或至少对该用户可读） - 启动后检查端口：运行
sudo ss -uln | grep :69，看到127.0.0.1:69或*:69才算监听成功
如何让 TFTP 目录既安全又可用
不能直接把 /var/tftpboot 设成 777 —— tftpd-hpa 默认以 tftp 用户身份访问，只要保证该用户有读（GET）或读+写（PUT）权限即可，其他用户无需任何权限。
使用场景：嵌入式设备刷固件、PXE 启动传内核镜像、交换机批量配置下发——这些都只要单向读取，chmod 755 /srv/tftp + chown root:tftp /srv/tftp 就够了；如果真要上传（比如日志回传），才需 chmod 775 并确保 tftp 用户在 tftp 组里。
- 推荐路径：用
/srv/tftp（符合 FHS 标准），别用/tftpboot或家目录 - 创建后立即执行：
sudo chown -R root:tftp /srv/tftp和sudo chmod -R 755 /srv/tftp - 如果启用了
--secure模式（默认开启），tftpd-hpa只允许访问TFTP_DIRECTORY及其子目录，硬链接和符号链接会被拒绝
客户端连不上？先盯住这三件事
90% 的连接失败跟服务是否运行无关，而是卡在基础连通性上。TFTP 是纯 UDP 协议，没有三次握手，发不出去或收不到响应就是断的。
错误信息如 Transfer timed out 或 Cannot find host，说明请求压根没到服务端；而 Access violation 是到了但权限/路径不对。
- 关掉本地防火墙：
sudo ufw disable（Ubuntu）或sudo systemctl stop firewalld（RHEL） - 确认客户端和服务端在同一子网，或路由明确放行 UDP 69（注意：不是 TCP！）
- 用
tftp命令行工具测试时，必须加-v参数看详细过程：tftp -v 192.168.1.100，再输入get test.bin - 别用浏览器或 curl 测 TFTP——它们不支持 UDP 文件传输协议
tftpd-hpa 的几个关键启动参数含义
参数写错会导致服务静默失败，比如漏掉 --secure 可能被绕过目录限制，加了 --ipv4 却在 IPv6 环境下运行会直接退出。
配置文件 /etc/default/tftpd-hpa 中的 TFTP_OPTIONS 字段控制行为，不是所有参数都必要，但以下三个最常被改错：
-
--secure：强制限定访问路径，必须启用；禁用它等于打开任意文件读取漏洞 -
--create：仅当需要客户端上传（PUT）时才加，否则去掉；加了但目录不可写，上传会报Access violation -
--user tftp：指定运行用户，不要改成root——这是最大安全陷阱
改完配置必须重启服务：sudo systemctl restart tftpd-hpa，而不是 reload。
真正麻烦的是跨子网转发和 SELinux 上下文——前者要配 iptables DNAT，后者得用 semanage fcontext 重标路径类型，这两处一旦出问题，日志里几乎不报错，只能靠 journalctl -u tftpd-hpa -f 实时盯输出。
