SSH能正常登录，SFTP却刚连接就显示subsystem request failed on channel 0。这条错误发生在认证之后，重点应查服务端有没有提供sftp子系统，而不是先改密码或重建密钥。
先保留一个可用的SSH会话，再检查sshd生效配置和服务端日志，避免修改错误把自己锁在VPS外。
先区分登录与子系统失败
用同一个账户分别执行ssh 用户名@服务器地址和sftp -vvv 用户名@服务器地址。前者能登录、后者在请求子系统后失败，说明网络与基础认证已通过。不要把SFTP失败等同于SSH端口不通；先看详细输出最后几行是否确实出现子系统请求失败。
核对sshd生效配置
在服务端检查sshd -T输出及实际配置文件中的Subsystem sftp设置。OpenSSH手册说明，SFTP可以由外部sftp-server程序提供，也可以用internal-sftp进程内实现。不同发行版的外部程序路径可能不同，不要直接照搬其他系统的绝对路径。
检查Match与受限账户规则
某些部署会在Match User或Match Group中设置ForceCommand internal-sftp，也可能把账户限制在chroot目录。用sshd -T -C user=用户名,host=服务器地址,addr=客户端地址查看该账户的条件配置；再检查服务器日志是否报chroot目录所有权或权限错误。先确认规则实际命中谁，再改动对应账户的配置。
修正后先测试配置再重载
确认确实缺少或写错子系统定义时，在sshd配置中使用适合当前系统的Subsystem sftp internal-sftp，或修正已经安装的sftp-server路径。保存后执行sshd -t检查语法，再按发行版实际服务名重载ssh或sshd。保留原会话，同时新开终端验证SSH和SFTP均能连接，确认后才关闭旧会话。
scp也失败不一定是另一个故障
较新的OpenSSH的scp默认使用SFTP协议；因此同一台服务器可能出现SSH正常、SFTP和scp同时失败。不要因此急着开放额外端口。业务部署在萤光云或LightNode云服务器时，也应先通过控制台保留救援入口，再调整sshd配置。
如何确认传输恢复
用相同账户执行sftp 用户名@服务器地址并列出允许访问的目录，再传一个无敏感内容的小文件并校验大小。检查受限账户是否仍被限制在指定目录。SFTP可登录但越过了原有限制，不算修复完成。
FAQ
需要另开SFTP端口吗？SFTP运行在SSH连接之上，不靠单独开放FTP端口。配置里已有Subsystem仍报错？继续核对生效配置、外部程序路径、Match规则和chroot日志。
温馨提示
修改远程登录服务前，请保留当前会话及带外控制台。不要为解决传输故障而放宽整个目录权限或关闭SSH认证限制；先把失败位置定位到子系统、执行路径或受限账户规则。
