很多站长和运维在做网站安全时，第一反应是：WAF、后台加固、插件漏洞、服务器防火墙......但我在实际排查里反复遇到一种情况：网站本身没先出事，反而是 SFTP/SSH 先被撞开。
原因也很现实：攻击者会长期扫描 TCP 22/2222，一旦端口开放，就会直接上"撞库 + 爆破"工具。只要还在用密码登录（哪怕密码看起来很复杂），风险就会持续存在。更糟的是，SFTP 经常用的是服务器本地账号------一旦被拿下，不只是"能上传文件"，很可能是整台机器的权限链条都被打开。
本文我们就来以Hostease 的服务器为例，讲清楚为什么 SFTP 必须和 SSH 一起加固，以及如何把 SSH Key 作为默认认证方式，用最小权限原则，把上传与登录风险压到更低。
SFTP 不是独立服务，是 SSH 的一个子系统
很多人以为"我开的是 SFTP，不是 SSH"，但实际上：
SFTP 是 SSH 的 subsystem。
你每一次 SFTP 连接，都走同一套 SSH 握手、加密和认证流程。
理解这四步，你就知道安全控制该加在哪：
1）加密协商：客户端/服务器协商加密算法，生成短期会话密钥（对称加密）
2）服务器身份验证：服务器用 host key 证明"我就是这台机器"，客户端核对指纹防 MITM
3）客户端认证：
密码登录（不推荐）
公钥认证（推荐）：客户端用私钥签名，服务器用 authorized_keys 里的公钥验证
4）通道建立：认证后才会进入 internal-sftp 或 shell 等子功能
一句话：
会话密钥负责"加密传输"
公私钥负责"证明身份"
用密码替代 Key，本质上是把身份交给了最容易被泄露、复用、撞库的那类秘密。
Host Key 和 User Key 别混：很多人管理错就从这里开始
1）Host Key（主机密钥）
位置：/etc/ssh/ssh_host_*
用途：让客户端确认"连的是正确的服务器"
影响：服务器重装/轮换 host key 会导致指纹变化，需要有更新流程
安全级别：root-only，不能外传
2）User Key（用户密钥）
生成：客户端本地 ssh-keygen
服务器放置：~/.ssh/authorized_keys
撤销：删掉对应那一行即可，立即生效
建议做法：
记录指纹、备注归属人/用途
把 host key 和 user key 分开备份与变更记录
团队内明确"谁负责加 key、谁负责清理 key"
为什么密码登录迟早会出事（哪怕你觉得密码很强）
密码登录的问题不在"强不强"，而在"攻击面太适配自动化"：
撞库：泄露库 + 自动化脚本，成本极低
终端中毒：键盘记录/木马直接拿到密码
社工钓鱼：一次误点就够
复用与共享：现实里很难完全避免
而公钥认证的优势是：
私钥不会在网络上传输
私钥文件可设置 passphrase（静态保护）
对高权限账号还能进一步使用硬件密钥形态（更抗钓鱼）
生成更强的 SSH Key：推荐 ed25519
在发起连接的机器上执行（本地电脑/运维机/CI runner）：
推荐（更现代、更快、更短）
ssh-keygen -t ed25519 -a 100 -C "deploy@example.com"
如果必须使用 RSA（建议 4096 位）
ssh-keygen -t rsa -b 4096 -a 100 -C "legacy-rsa@example.com"
为什么要加 -a 100？
它会提高密钥派生的计算轮数：即使私钥文件不幸泄露，离线猜 passphrase 的成本也更高。
实践建议：
尽量给私钥设置 passphrase
自动化场景若不得不免密：要把运行环境隔离好（权限、网络、凭证管理），并限定 key 的用途与来源 IP
密钥轮换与审计：别等到"离职账号还在登录"才处理
建议建立固定节奏（尤其是多人协作的站点运维）：
每季度审计一次：清理离职/停用/过期 key
发现异常：立刻撤销 key（删 authorized_keys 对应行）
指纹登记（方便审计/工单核对）：
ssh-keygen -lf /path/to/key.pub
Host Key 变更注意：
服务器重装或轮换后，客户端可能需要清理旧指纹：
ssh-keygen -R hostname
日志与防护：SSH 加密强，但"登录后行为"更要管
1）先把登录行为记录清楚
Debian/Ubuntu：/var/log/auth.log
RHEL/AlmaLinux：/var/log/secure
systemd：journalctl -u sshd
建议至少对这些行为做告警：
短时间大量失败登录
某个账号突然从陌生地区/IP 登录
authorized_keys 被改动
SFTP chroot/权限异常
2）基础对抗：Fail2ban + 连接限制 + 防火墙
Fail2ban：失败 N 次自动封 IP
MaxStartups：限制未认证连接，防止洪泛
防火墙/安全组：尽量限制来源 IP（对安全提升非常明显）
3）"上传目录"的安全别忽略
很多入侵不是"撞开后立刻删库"，而是：先上传后门、慢慢潜伏。
更稳妥的做法是：
上传目录做实时/准实时扫描（自建或接入安全体系均可）
配合文件完整性监控（异常变更可追踪）
4）备份要有"不可篡改副本"
每日快照业务目录（尤其是 chroot/SFTP 根目录）
异地保存，最好是不可变策略（防止入侵后删除历史）
把 SFTP 加固放进"站点整体安全闭环"
只做 SSH Key 认证还不够，建议配合网站层的安全防护以及代码与文件变更监控，并做好备份工作。把 SSH/SFTP 加固作为上线的第一步，成本很低，但能直接砍掉一大类"最常见入侵路径"。