不能只改FTP，因为明文服务（如FTP、Telnet、HTTP、Rsync over rsh）深度嵌入脚本、CI/CD、监控、日志等全链路，单点替换无法消除风险；必须逐层识别并用SSH生态原生替代，如telnet→ssh、rsync -e "ssh"、curl http→HTTPS+client cert或scp、明文FTP脚本→sftp -b+密钥认证，并强制禁用密码登录与交互式shell。
为什么不能只改 FTP，而要动整个通信链路
明文服务（如 FTP、Telnet、HTTP、Rsync over rsh）不是孤立存在的，它们往往嵌在脚本、CI/CD 流水线、监控采集、日志归档等环节里。单纯把 ftp_put() 换成 sftp_put() 不够——如果上游调用方仍用 telnet 连管理口，或用 curl http:// 拉配置，加密就形同虚设。真正的“全面升级”，是逐层识别明文出口，再用 SSH 生态原生替代。
哪些服务必须优先替换（附对应 SSH 替代方案）
按风险等级和替换成本排序，以下是最常被忽略但又高频使用的明文通道：
-
telnet→ 改用ssh：不只用于登录，很多设备的串口代理、网络设备 CLI 封装也走 telnet，必须确认其调用方是否可配为 ssh； -
rsync默认走 rsh → 强制指定-e "ssh -o StrictHostKeyChecking=no"，否则仍可能 fallback 到明文； -
curl http://或wget http://拉内部配置 → 改为curl -s --key ~/.ssh/id_rsa --cert ~/.ssh/client.crt https://，或更稳妥地改用scp拉取本地文件； - 自建脚本中用
echo "user:pass" | ftp类型逻辑 → 必须废弃，改用sftp批处理模式：sftp -b /path/to/commands.txt user@host，且commands.txt中不能含密码（靠密钥认证）； - 监控工具（如 Zabbix、Nagios）通过明文 SNMP 或 HTTP API 获取指标 → 优先启用 HTTPS + client cert，次选改用 SSH exec 模式（Zabbix 的
system.run[ssh user@host 'df -h']）。
SSH 密钥认证不是可选项，而是强制前提
全面升级后，密码认证会成为最大短板：一旦某处脚本仍写死密码，就等于留了后门。所有自动化场景必须用密钥，并满足以下硬性条件：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 私钥必须加 passphrase，且由
ssh-agent管理（避免脚本里硬编码解密口令）； - 服务器端
/etc/ssh/sshd_config中禁用密码登录：PasswordAuthentication no，并确认PubkeyAuthentication yes； - 密钥对生成必须用
ssh-keygen -t ed25519 -a 100（非 RSA），ed25519 抗侧信道攻击更强，-a 100提高密钥派生强度； - 公钥部署后，用
ssh -T user@host验证是否免密成功，失败时检查~/.ssh/authorized_keys权限是否为600、目录是否为700。
最容易被绕过的漏洞点：Chroot 用户仍能执行 shell 命令
很多人以为给 SFTP 用户配了 ChrootDirectory 就万事大吉，但若没禁掉交互式 shell，攻击者可通过 sftp 的 !command 语法逃逸（例如 !sh 或 !/bin/bash）。必须确保：
- 用户 shell 明确设为
/sbin/nologin或/usr/bin/false，而非/bin/bash； -
/etc/ssh/sshd_config中对应Match Group sftpusers块内包含ForceCommand internal-sftp，该指令会拦截所有非 SFTP 协议命令； - 不要在 chroot 根目录下放
/bin/sh或/usr/bin/env，否则!sh可能意外生效； - 验证方式：用该用户登录后执行
!，应直接报错Interactive commands not allowed，而非弹出 shell 提示符。
真正难的不是换命令，而是厘清所有依赖明文协议的上下游组件——一个没发现的 nc host 21 调用，就足以让整套加密体系失效。
