当前位置：首页 > news >正文

SFTP不是加密FTP：底层是SSH子系统，配置核心在sshd_config

news 2026/6/22 5:56:54

1. 为什么SFTP不是“升级版FTP”，而是彻底换了一套底层逻辑

你可能在Windows上用过FileZilla，在Mac上点开终端敲过sftp user@host，或者在VS Code里装过SFTP插件——但真正搞懂SFTP的人，往往不是那些“能连上就行”的用户，而是被凌晨三点的Connection closed by remote host错误惊醒、翻遍日志才发现问题出在SSH密钥权限上的人。

SFTP（SSH File Transfer Protocol）这个名字本身就藏着一个巨大误解：它根本不是FTP的加密版本，也不是FTP over SSL/TLS（即FTPS）。它压根就不属于FTP协议族。SFTP是SSH协议套件中的一个子系统（Subsystem），运行在SSHv2连接之上，所有文件操作——列出目录、上传下载、重命名、删除、设置权限——全部封装在SSH数据流中，走的是同一个加密通道。这意味着：

没有独立的“SFTP端口”概念（虽然默认用22，但它只是SSH服务监听的端口）；
不需要额外配置FTP服务器（如vsftpd、pure-ftpd），只要SSH服务开着且允许SFTP子系统，就天然支持；
所有认证方式完全复用SSH机制：密码、公钥、甚至U2F安全密钥（OpenSSH 8.2+）；
没有PASV/PORT模式切换，不存在NAT穿透失败、防火墙放行困难等FTP经典顽疾。

我第一次在客户现场踩坑，就是把一台CentOS 7服务器的/etc/ssh/sshd_config里删掉了Subsystem sftp /usr/lib/openssh/sftp-server这一行，以为“反正能SSH登录，SFTP肯定也通”。结果开发团队全员无法上传代码包，CI流水线卡死。查了两小时网络策略，最后发现sshd -T | grep sftp输出为空——SFTP子系统根本没启用。这个细节，90%的教程都一笔带过，但它是整个流程的起点。

提示：sftp -v user@host加-v参数会输出完整握手过程，你能清晰看到debug1: Sending subsystem: sftp这行。如果这里失败，问题一定出在服务端SSH配置或权限上，和客户端工具无关。

关键词里的“sftp设置信任”“无法初始化sftp协议主机是sftp”，背后几乎全是这类底层认知偏差：人们习惯性把SFTP当FTP用，却忘了它本质是SSH的一个功能模块。当你在WinSCP里勾选“使用密钥对登录”，它实际是在调用OpenSSH的ssh-agent机制；当你在VS Code SFTP插件里填privateKeyPath，它最终是把私钥内容喂给ssh2库的privateKey字段——所有操作，都在SSH协议栈内完成。

所以，别再问“SFTP怎么开端口”，去查sshd_config；别再纠结“SFTP要不要开被动模式”，它压根没有这个概念；更别试图在Docker容器里单独装一个sftp-server二进制——除非你明确禁用了SSH服务，否则它就在那里，静默待命。

2. 服务端硬核配置：从默认禁用到生产级加固的七步实操

很多人的SFTP服务跑不起来，不是因为不会用客户端，而是服务端压根没配对。OpenSSH默认虽启用SFTP子系统，但生产环境必须做精细化控制。下面是我在线上集群部署时反复验证的七步配置法，每一步都有明确目的和实测后果：

2.1 确认SFTP子系统已声明并指向正确路径

检查/etc/ssh/sshd_config：

# 必须存在且未被注释 Subsystem sftp /usr/lib/openssh/sftp-server # 或新版OpenSSH推荐写法（更安全） # Subsystem sftp internal-sftp

注意路径差异：/usr/lib/openssh/sftp-server是传统外部进程模式；internal-sftp是内置子系统，无独立进程、内存隔离更好。CentOS 7默认用前者，Ubuntu 20.04+默认用后者。切勿混用——若启用了internal-sftp，再在Match块里指定外部路径会导致启动失败。

2.2 强制SFTP专用用户组，隔离shell访问

创建专用组，禁止交互式登录：

sudo groupadd sftpusers # 创建用户时指定组和无shell sudo useradd -m -g sftpusers -s /bin/false -d /var/sftp/john john # 设置密码（或后续配密钥） sudo passwd john

关键点：-s /bin/false让该用户无法执行任何shell命令，但SFTP仍可工作——因为SFTP子系统绕过了shell调用。这是最基础的权限收敛。

2.3 使用Match块实现精准策略控制

在sshd_config末尾添加：

# 匹配sftpusers组的所有用户 Match Group sftpusers # 禁用PTY分配（防止逃逸到shell） ForceCommand internal-sftp -u 0002 # 限制根目录为用户主目录（chroot） ChrootDirectory %h # 禁用端口转发等高危功能 X11Forwarding no AllowTcpForwarding no PermitTunnel no

这里-u 0002是umask，确保上传文件默认权限为664（组可写），避免开发上传后其他协作者无法修改。ChrootDirectory %h要求%h（用户主目录）必须由root拥有且不可写——这是OpenSSH chroot的硬性要求。我曾因/var/sftp/john属主是john自己，导致SFTP连接后立即报错Write failed: Broken pipe，查日志才发现sshd拒绝chroot到非root拥有的目录。

2.4 修复chroot目录权限的魔鬼细节

按上述配置，/var/sftp/john必须：

属主：root
属组：root
权限：755（不能777！）
但用户文件需存放在其子目录中，例如：

sudo mkdir -p /var/sftp/john/upload sudo chown john:sftpusers /var/sftp/john/upload sudo chmod 775 /var/sftp/john/upload

这样用户登录后看到的根目录是/var/sftp/john，但只能在upload下读写。/var/sftp/john本身对john只读，彻底阻断提权路径。

2.5 启用密钥认证并禁用密码（强制安全基线）

在Match块内追加：

# 禁用密码登录（仅密钥） PasswordAuthentication no # 允许公钥认证 PubkeyAuthentication yes # 指定authorized_keys位置（chroot后路径变化） AuthorizedKeysFile /var/sftp/%u/.ssh/authorized_keys

注意%u是用户名，/var/sftp/john/.ssh/authorized_keys必须存在且权限为600，属主john。由于chroot，~/.ssh路径在用户视角是/下的.ssh，但物理路径是/var/sftp/john/.ssh。

2.6 日志级别调至VERBOSE，定位连接失败根源

在sshd_config全局段添加：

LogLevel VERBOSE # 或更详细（调试用） # LogLevel DEBUG3

重启后查看/var/log/auth.log（Ubuntu）或/var/log/secure（CentOS）：

debug1: SFTP server child started→ 子系统启动成功
fatal: bad ownership or modes for chroot directory→ chroot目录权限错误
userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms→ 客户端密钥算法过时（OpenSSH 8.8+默认禁用RSA-SHA1）

2.7 防火墙与SELinux双校验（Linux特有雷区）

CentOS/RHEL用户必做：

# 开放SSH端口（22） sudo firewall-cmd --permanent --add-service=ssh sudo firewall-cmd --reload # SELinux上下文修正（否则chroot失败） sudo semanage fcontext -a -t ssh_home_t "/var/sftp(/.*)?" sudo restorecon -Rv /var/sftp

semanage命令在policycoreutils-python-utils包中，常被忽略。没有这步，ls命令在SFTP客户端里会返回空列表，而/var/log/audit/audit.log里躺着avc: denied { search } for ... scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir——典型的SELinux拦截。

这七步做完，你的SFTP服务就不再是“能连上”，而是“符合等保2.0三级要求”的生产级配置。我管理的200+台服务器，全部采用此模板，零起因SFTP配置导致的安全事件。

3. 客户端实战矩阵：从命令行到VS Code的全场景穿透指南

客户端选择不是“哪个好用”，而是“哪个匹配你的工作流和安全策略”。我按使用频率和复杂度，把常见工具拆解成四类场景，每类给出真实痛点解决方案。

3.1 OpenSSH原生命令行：最简路径与隐藏陷阱

基础用法人人会：

sftp -i ~/.ssh/id_rsa user@host # 进入交互式界面后 sftp> put localfile.txt /remote/path/ sftp> get /remote/file.log .

但生产环境必踩的坑：

密钥密码缓存失效：sftp -i每次都要输密钥密码？用ssh-agent：

eval $(ssh-agent) # 启动代理 ssh-add ~/.ssh/id_rsa # 添加密钥（输一次密码） sftp user@host # 此后无需重复输密钥密码

中文文件名乱码：SFTP协议本身不传编码信息，依赖终端locale。在Mac上，export LC_ALL=en_US.UTF-8；在Windows WSL中，export LANG=C.UTF-8。实测无效？改用lftp替代：
```
lftp -u user, sftp://host lftp> set sftp:charset utf-8
```

3.2 WinSCP：Windows用户的密钥登录终极配置

“winscp如何使用密钥对登录sftp”是高频问题，根源在于PuTTY密钥格式（.ppk）与OpenSSH（id_rsa）不兼容。解决方案分三步：

转换密钥格式：用PuTTYgen打开.ppk，Conversions → Export OpenSSH key保存为id_rsa；
WinSCP配置：新建站点 →Advanced → SSH → Authentication，勾选Attempt authentication using Pageant（若用Pageant管理密钥），或直接指定id_rsa路径；
关键一步：Advanced → Environment → SFTP，将SFTP server改为sftp（不是空，也不是/usr/lib/openssh/sftp-server）。WinSCP默认尝试外部sftp-server，但chroot环境下必须用内置子系统，填sftp会触发internal-sftp调用。

注意：WinSCP的“保存密码”选项在密钥登录时灰色不可用——这是设计使然，因为密钥本身已是凭证。若想免输密钥密码，需用Pageant加载.ppk并勾选Auto-start Pageant。

3.3 VS Code SFTP插件：开发者的实时同步工作流

vscode sftp 密钥问题本质是插件配置与OpenSSH行为差异。官方SFTP插件（by liximomo）配置ftpconfig.json如下：

{ "name": "Prod Server", "host": "192.168.1.100", "port": 22, "username": "deploy", "privateKeyPath": "/Users/me/.ssh/id_rsa", "protocol": "sftp", "passphrase": "", // 若密钥有密码，填在此处（明文！） "remotePath": "/var/www/html/", "uploadOnSave": true, "ignore": [".git", "node_modules"] }

致命细节：

passphrase字段必须是明文密码，不能留空（即使密钥无密码也要写""），否则插件会卡在连接阶段；
remotePath必须以/结尾，否则上传路径拼接错误；
若遇Error: Cannot parse privateKey: Unsupported key format，说明私钥是新格式（OpenSSH 8.8+默认生成BEGIN OPENSSH PRIVATE KEY），需降级生成：
```
ssh-keygen -t rsa -b 4096 -m PEM -f ~/.ssh/id_rsa_legacy
```

3.4 脚本化批量传输：用`lftp`解决`linux sftp 连接失败`顽疾

当标准sftp命令在某些嵌入式设备或老旧系统上失败（报Received message too long），lftp是救星。它支持SFTP、FTP、HTTP多协议，且重试、断点续传、并行传输一应俱全。

# 安装（Ubuntu/Debian） sudo apt install lftp # 批量上传脚本 lftp -c " set sftp:connect-program 'ssh -a -x -o StrictHostKeyChecking=no'; open sftp://user:pass@host; lcd ./local_dir; cd /remote/dir; mirror -R --parallel=3 --exclude-glob='*.tmp'; "

-R表示反向镜像（本地→远程），--parallel=3并发3个连接加速，--exclude-glob过滤临时文件。set sftp:connect-program覆盖默认SSH命令，禁用agent forwarding（-a）和X11 forwarding（-x），规避某些防火墙拦截。

这四类工具覆盖了95%的SFTP使用场景。我的经验是：日常调试用命令行，Windows运维用WinSCP，前端开发用VS Code，自动化任务用lftp脚本——没有银弹，只有适配。

4. 故障排查黄金链路：从`Connection closed`到`Upload failed`的逐层解剖

网络热词里“linux sftp 连接失败”“gaussdb集中式 docker安装 upload sftp package failed”看似不同，但底层排查逻辑完全一致。我总结出一条五层黄金链路，每层对应一个ssh -v输出的关键节点，按顺序排查，99%的问题3分钟内定位。

4.1 第一层：TCP连接是否建立？（网络层）

执行：

telnet host 22 # 或 nc -zv host 22

成功：输出Connected to host→ 进入第二层；
失败：Connection refused→ 目标SSH服务未运行或端口被占；No route to host→ 网络不通（防火墙、路由、Docker网络配置错误）。
Docker典型场景：GaussDB容器内执行sftp失败，先docker exec -it gaussdb bash，再ping host和telnet host 22。若不通，检查Docker网络模式（--network host或自定义bridge）及宿主机防火墙。

4.2 第二层：SSH握手是否完成？（协议层）

执行：

ssh -v user@host

观察输出：

debug1: Connecting to host port 22.→ TCP层OK；
debug1: SSH2_MSG_KEXINIT sent→ 密钥交换开始；
debug1: kex: algorithm: curve25519-sha256→ KEX算法协商成功；
debug1: Authentication succeeded (publickey).→ 认证成功。
关键失败点：
no matching key exchange method found→ 客户端与服务端KEX算法不兼容（旧客户端连新服务端）。解决方案：在~/.ssh/config中添加：
```
Host legacy-host KexAlgorithms +diffie-hellman-group1-sha1
```
Permission denied (publickey)→ 公钥未正确部署或authorized_keys权限错误（必须600，属主正确）。

4.3 第三层：SFTP子系统是否启用？（服务层）

若SSH登录成功但sftp user@host报Connection closed by remote host，执行：

ssh user@host "echo \$?" # 测试SSH命令执行 ssh user@host "sftp -V" # 查看sftp客户端版本（服务端不提供此命令） # 更直接：检查服务端sshd配置 ssh root@host "sshd -T | grep sftp"

输出subsystem sftp /usr/lib/openssh/sftp-server→ 子系统启用；
输出空 → 未启用，需修改sshd_config并systemctl restart sshd；
输出subsystem sftp internal-sftp但客户端报错 → 检查Match块是否冲突（如同时指定了外部路径）。

4.4 第四层：Chroot环境是否就绪？（文件系统层）

当SFTP登录后立即断开，或ls返回空，检查：

# 在服务端执行（以用户john为例） sudo -u john ls -ld /var/sftp/john # 应输出：drwxr-xr-x 3 root root 4096 ... sudo -u john ls -l /var/sftp/john/.ssh # 应输出：-rw------- 1 john sftpusers 394 ...

若/var/sftp/john属主不是root →chown root:root /var/sftp/john；
若.ssh权限不是600 →chmod 600 /var/sftp/john/.ssh/authorized_keys；
若/var/sftp/john/upload不存在 →mkdir /var/sftp/john/upload && chown john:sftpusers /var/sftp/john/upload。

4.5 第五层：应用层操作是否受限？（业务逻辑层）

gaussdb集中式 docker安装 upload sftp package failed这类错误，通常发生在SFTP连接成功后执行put时失败。此时：

查看服务端/var/log/auth.log，搜索internal-sftp关键字；
常见日志：open "/package.tar.gz" flags WRITE_ONLY|CREAT|TRUNC mode 0644: Permission denied→ 上传目录权限不足（/var/sftp/john/upload需775且属组sftpusers）；
或rename "/tmp/file.part" -> "/package.tar.gz": Invalid argument→ 文件系统不支持硬链接（某些NFS或overlayfs），需在sshd_config的Match块中添加：
```
ForceCommand internal-sftp -u 0002 -o subsystem=sftp
```

这条链路不是理论，而是我在金融客户现场处理GaussDB升级包上传失败的真实路径。从telnet确认网络通，到ssh -v发现KEX不兼容，再到sshd -T揪出子系统未启用，最后ls -ld修复chroot权限——五步，17分钟，问题闭环。

5. 密钥管理与安全加固：超越`ssh-keygen`的生产实践

热词中“公钥 ssh可用 sftp失败”揭示了一个残酷现实：密钥能用于SSH登录，不代表能用于SFTP。原因在于OpenSSH 8.8+的算法策略变更和密钥格式演进。以下是我在高安全要求项目中落地的密钥管理方案。

5.1 算法选择：告别SHA-1，拥抱Ed25519

OpenSSH 8.8（2021年发布）起，默认禁用ssh-rsa签名（RSA-SHA1），因其易受伪造攻击。若你用老版ssh-keygen -t rsa生成的密钥，在新服务端SFTP会失败。正确做法：

# 生成Ed25519密钥（推荐，速度快、安全性高） ssh-keygen -t ed25519 -C "admin@company.com" -f ~/.ssh/id_ed25519 # 或RSA-2048（兼容性更好，但需显式启用） ssh-keygen -t rsa -b 2048 -m PEM -C "admin@company.com" -f ~/.ssh/id_rsa_pem

-m PEM强制生成PEM格式（-----BEGIN RSA PRIVATE KEY-----），而非新格式（-----BEGIN OPENSSH PRIVATE KEY-----），确保VS Code等工具兼容。

5.2 密钥分发：`ssh-copy-id`的三个致命缺陷及修复

ssh-copy-id是便捷工具，但生产环境慎用：

缺陷1：不校验目标目录权限→.ssh目录若为777，authorized_keys会被拒绝；
缺陷2：不处理chroot路径→ 默认写入~/.ssh/authorized_keys，但chroot后路径是/var/sftp/user/.ssh；
缺陷3：不设置密钥权限→ 上传后需手动chmod 600。

安全分发脚本：

#!/bin/bash USER="deploy" HOST="prod-server" KEY_PATH="$HOME/.ssh/id_ed25519.pub" # 创建chroot内的.ssh目录 ssh root@$HOST "mkdir -p /var/sftp/$USER/.ssh && chown $USER:sftpusers /var/sftp/$USER/.ssh" # 上传公钥并设权限 ssh root@$HOST "cat >> /var/sftp/$USER/.ssh/authorized_keys" < $KEY_PATH ssh root@$HOST "chmod 600 /var/sftp/$USER/.ssh/authorized_keys && chown $USER:sftpusers /var/sftp/$USER/.ssh/authorized_keys"

5.3 密钥轮换：自动化脚本与审计追踪

密钥不应永久有效。我用以下脚本实现90天自动轮换：

# rotate_sftp_key.sh NEW_KEY=$(mktemp) ssh-keygen -t ed25519 -f "$NEW_KEY" -N "" -C "auto-$(date +%Y%m%d)" # 分发新密钥（调用上节脚本） ./deploy_key.sh "$NEW_KEY.pub" "$USER" "$HOST" # 记录审计日志 echo "$(date): Rotated SFTP key for $USER on $HOST" >> /var/log/sftp_key_rotation.log # 清理旧密钥（需人工确认） # sed -i "/old-comment/d" /var/sftp/$USER/.ssh/authorized_keys

配合cron每月执行，并将/var/log/sftp_key_rotation.log接入SIEM系统。

5.4 审计与监控：让每一次SFTP操作可追溯

仅靠/var/log/auth.log不够。在sshd_config中添加：

# 启用SFTP详细日志 Subsystem sftp internal-sftp -l INFO -f AUTH # 或更详细（调试用） # Subsystem sftp internal-sftp -l VERBOSE -f AUTH

重启后，/var/log/auth.log中会出现：

sshd[12345]: session opened for user deploy by (uid=0) internal-sftp[12346]: session opened for user deploy internal-sftp[12346]: opendir "/upload" internal-sftp[12346]: open "/upload/app_v2.1.zip" flags WRITE_ONLY|CREAT|TRUNC mode 0644 internal-sftp[12346]: close "/upload/app_v2.1.zip" bytes read 0 written 12345678

每一行对应一个SFTP操作，精确到字节数。我用awk脚本实时提取上传文件名和大小，推送到企业微信机器人，实现“开发上传即告警”。

密钥不是一劳永逸的凭证，而是需要持续运营的安全资产。从生成、分发、轮换到审计，每个环节都需工程化管控。这是我管理银行核心系统SFTP服务三年零事故的核心经验。

6. Docker与云环境特例：解决`windows server 安装ftp和sftp`的架构误判

热词中“windows server 安装ftp和sftp”暴露了一个普遍误区：在Windows Server上，你不需要、也不应该安装传统FTP服务来实现SFTP。SFTP是SSH协议的一部分，而Windows Server 2019+原生支持OpenSSH服务。同样，Docker容器内SFTP失败，根源常是架构设计错误。

6.1 Windows Server 2019+原生SFTP部署（零第三方软件）

微软已将OpenSSH作为可选功能集成：

启用OpenSSH服务：

# PowerShell管理员模式 Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 Start-Service sshd Set-Service -Name sshd -StartupType 'Automatic'

配置SFTP专用用户：

# 创建本地用户（无登录权限） New-LocalUser "sftpuser" -Password (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force) -FullName "SFTP User" # 加入SFTP组（需提前创建） Add-LocalGroupMember -Group "sftpusers" -Member "sftpuser"

修改C:\ProgramData\ssh\sshd_config：

Subsystem sftp sftp-server.exe Match Group sftpusers ForceCommand C:/ProgramData/ssh/sftp-server.exe -u 0002 ChrootDirectory C:/sftp/%u PasswordAuthentication no PubkeyAuthentication yes

注意：Windows路径用正斜杠，ChrootDirectory必须是绝对路径，且C:/sftp/sftpuser目录需由SYSTEM拥有。

6.2 Docker容器内SFTP：为何`gaussdb集中式 docker安装 upload sftp package failed`

GaussDB等数据库镜像通常基于精简Linux（如Alpine），默认不包含openssh-server。若你在容器内执行sftp命令失败，不是SFTP服务问题，而是你试图在客户端容器里连自己——这是逻辑错误。正确架构是：

SFTP服务端：独立容器（如atmoz/sftp），挂载共享卷；
应用容器（GaussDB）：通过host.docker.internal或自定义网络，连接SFTP服务端容器。

# docker-compose.yml version: '3.8' services: sftp-server: image: atmoz/sftp volumes: - ./sftp-data:/home/foo/upload ports: - "2222:22" command: foo:pass:::upload gaussdb: image: gaussdb:latest depends_on: - sftp-server # 在GaussDB容器内执行 # sftp -P 2222 foo@host.docker.internal

atmoz/sftp镜像已预配置chroot和密钥，foo:pass是用户凭据。GaussDB容器通过host.docker.internal解析宿主机IP，连接SFTP服务。

6.3 云环境（AWS/Azure）SFTP网关：规避自建风险

对于合规要求高的场景（如金融、医疗），自建SFTP存在审计压力。云厂商提供托管SFTP服务：

AWS Transfer Family：完全托管，支持SFTP/FTPS/FTP，后端可接S3/EFS，自动加密，IAM精细授权；
Azure Logic Apps SFTP Connector：无需管理服务器，通过逻辑流触发文件上传，与Azure Key Vault集成密钥。

我主导的一个医保数据交换项目，原计划自建SFTP，但等保测评指出“密钥生命周期管理缺失”。最终切换AWS Transfer，用S3桶策略+IAM角色控制访问，审计日志直连CloudTrail，测评一次性通过。成本增加15%，但节省了3人月的运维和安全加固工作。

在云和容器时代，“安装SFTP”早已不是技术动作，而是架构决策。选择自建还是托管，取决于你的安全水位、运维能力和合规要求。盲目在Windows Server上装FileZilla Server或在Docker里硬塞openssh-server，只会把简单问题复杂化。

7. 终极检查清单：上线前必须验证的12个硬性指标

所有配置和排错终将落地为一份可执行的检查清单。这是我交付给客户的SFTP服务上线前最终核验表，12项全部打钩，方可对外提供服务：

序号	检查项	验证命令/方法	不通过后果	我的实测备注
1	SSH服务监听22端口	`sudo ss -tlnp \| grep :22`	无法建立TCP连接	Ubuntu需`sudo ufw allow OpenSSH`
2	SFTP子系统已启用	`sudo sshd -T \| grep sftp`	`sftp`命令立即断开	输出必须含`subsystem sftp`
3	用户属组为`sftpusers`	`id username`	`Match Group`规则不生效	组名必须与`sshd_config`完全一致
4	chroot目录属主为root	`sudo ls -ld /var/sftp/username`	登录后`Connection closed`	权限必须755，不可777
5	`.ssh/authorized_keys`权限600	`sudo ls -l /var/sftp/username/.ssh/authorized_keys`	`Permission denied (publickey)`	属主必须为该用户
6	上传目录属组为`sftpusers`	`sudo ls -ld /var/sftp/username/upload`	`Permission denied`上传失败	权限775，确保组可写
7	密钥算法兼容（Ed25519）	`ssh-keygen -lf ~/.ssh/id_ed25519.pub`	新服务端拒绝连接	避免使用`ssh-rsa`
8	SELinux上下文正确（RHEL/CentOS）	`sudo ls -Z /var/sftp`	`ls`返回空，无错误日志	必须`ssh_home_t`类型
9	日志级别为VERBOSE	`sudo grep LogLevel /etc/ssh/sshd_config`	故障时无有效线索	重启`sshd`生效
10	防火墙放行22端口	`sudo firewall-cmd --list-ports`	外网无法连接	Docker需`--publish 2222:22`
11	客户端密钥密码已缓存（如使用）	`ssh-add -l`	每次操作输密钥密码	`ssh-agent`需`eval $(ssh-agent)`
12	上传/下载/重命名/删除全操作测试	`sftp user@host; sftp> put test.txt; sftp> get test.txt; sftp> rename test.txt test2.txt; sftp> rm test2.txt`	业务功能不完整	必须覆盖所有SFTP核心操作