返回

SSHFS-Win 连接重置怎么办?Windows SSH 挂载终极指南

windows

搞定 SSHFS-Win 连接重置:Windows 挂载 SSH 目录疑难排解

你是不是也遇到了这样的麻烦:在 Windows 10 上装好了 WinFsp 和 SSHFS-Win,想挂载 Windows 11 上 OpenSSH 服务器的一个目录,结果要么卡住不动,要么直接弹出“connection reset by peer”的错误?明明用 ssh 命令直接连服务器好好的,端口 22 防火墙也开了,甚至用同样的用户名密码,SMB 共享都能正常映射。这到底是哪里不对劲?

别急,这问题虽然有点绕,但通常不是什么玄学问题。咱们来一步步排查,把这个拦路虎给揪出来。

啥情况?SSHFS-Win 连不上,提示“connection reset by peer”

我们先梳理一下具体遇到的现象:

  1. 环境 :客户端是 Windows 10(安装了 WinFsp 和 SSHFS-Win),服务器是 Windows 11(安装了 OpenSSH 服务器)。
  2. 目标 :想通过 SSHFS 把服务器上的某个文件夹(比如 sharedfolder)映射到客户端(比如 Z: 盘)。
  3. 命令尝试 :类似这样 sshfs-win svc Z: \\sshfs\[email protected]\sharedfolder 或者带端口 sshfs-win svc Z: \\sshfs\[email protected]!22\sharedfolder
  4. 问题表现
    • 命令行执行 sshfs-win svc 命令时,有时报错 connection reset by peer
    • 有时命令执行后没有任何反应,直接卡住。
    • 在 Windows 文件管理器的“映射网络驱动器”中使用 \\sshfs\[email protected]\path 格式,提示“拒绝访问 (Access denied)”。
  5. 已知有效信息
    • 直接使用 ssh [email protected] 可以成功登录服务器。
    • 服务器防火墙已放行 TCP 端口 22。
    • 使用相同的用户凭据,通过 SMB 协议映射网络驱动器是成功的。
    • 尝试修改过服务器 sshd_config 文件(比如添加 AllowUsers *),也重启过服务,但没效果。

看起来,问题似乎集中在 SSHFS 协议的交互上,而不是基础的 SSH 连接或用户凭据本身。

为啥会这样?刨根问底找原因

“connection reset by peer” 这个错误,通常意味着 TCP 连接的一方(这里多半是服务器)在你发送数据后,强行关闭了连接。在 SSHFS 的场景下,可能的原因有不少:

  1. 服务器 SSH 配置问题 : OpenSSH 服务器(sshd)的配置是重点怀疑对象。默认配置可能没有显式启用或正确配置 SFTP 子系统,而 SSHFS 正是依赖 SFTP 协议来传输文件的。即使基础 SSH 登录没问题,SFTP 功能也可能被禁用了。
  2. 权限不足 :虽然 SMB 映射成功,但 SSHFS/SFTP 登录后,用户在服务器上实际访问目标文件夹 (sharedfolder) 时,可能缺乏必要的 NTFS 文件系统权限(读取、列出目录等)。或者,用户的 SSH 登录权限本身受限,不允许执行 SFTP 操作。特别是尝试使用“非交互式”或“来宾”账户时,权限限制更常见。
  3. SSHFS-Win 命令或参数错误 : 路径格式、用户名、主机名的写法,或者某些特殊参数的使用可能不符合 SSHFS-Win 的要求。
  4. WinFsp 或 SSHFS-Win 软件问题 : 软件本身可能存在 Bug,或者与特定版本的 Windows、OpenSSH Server 存在兼容性问题。
  5. 防火墙或安全软件干扰 : 虽然 22 端口开了,但某些高级防火墙或安全软件可能会对 SSH 流量进行深度包检测,误判 SSHFS 的特定数据模式为异常并阻止连接。这种情况相对少见,但不能完全排除。
  6. 服务器资源限制 : 极少数情况下,服务器资源(如内存、进程数)耗尽也可能导致连接被意外重置,但根据可能性不大。

既然直接 SSH 可以通,SMB 也能用,那多半是卡在 SFTP 子系统配置或者用户权限这块儿了。

咋解决?一步步来

下面我们针对可能性比较大的原因,逐个尝试解决。

1. 检查 SSH 服务器配置 (sshd_config)

这是最需要检查的地方。Windows OpenSSH Server 的配置文件通常在 %programdata%\ssh\sshd_config。你需要用管理员权限的文本编辑器(比如 Notepad++ 以管理员身份运行)来修改它。

原理和作用 :
sshd_config 控制着 SSH 服务器的所有行为,包括允许哪些用户登录、使用何种认证方式、以及是否启用像 SFTP 这样的子服务。SSHFS 能不能用,关键看 SFTP 子系统有没有配好。

操作步骤 :

  1. 找到并备份配置文件
    打开文件资源管理器,地址栏输入 %programdata%\ssh 并回车。找到 sshd_config 文件,先复制一份做备份,以防改错了还能恢复。

  2. 编辑 sshd_config 文件
    用管理员权限打开 sshd_config 文件。查找以下几项配置,确保它们是这样设置的(如果某行前面有 # 号,表示是注释,需要把 # 去掉让它生效):

    # 这个是必须的,指定 sftp 服务器程序的路径
    # OpenSSH Server 8.1 及更新版本推荐使用 internal-sftp
    Subsystem	sftp	sftp-server.exe 
    # 或者,对于新版本,更推荐使用内置 SFTP 服务,效率可能更高
    # Subsystem sftp internal-sftp 
    # (注意:上面两个 Subsystem sftp 你应该只启用一个,根据你的 OpenSSH 版本选择)
    # 如果不确定,可以先试试 sftp-server.exe,不行再换 internal-sftp
    
    # 确保密码认证是开启的 (如果你打算用密码登录)
    PasswordAuthentication yes
    
    # 确保 ChallengeResponseAuthentication 关闭,除非你确定需要它
    # ChallengeResponseAuthentication no 
    
    # PubkeyAuthentication yes # 如果你用密钥登录,这个也要是 yes
    
    # 关于用户/组的限制,可以先放宽测试,确认连接成功后再收紧
    # AllowUsers your_username another_user # 只允许指定用户登录
    # AllowGroups your_groupname # 只允许属于指定组的用户登录
    # 如果不确定,可以先注释掉 AllowUsers 和 AllowGroups 这两行,允许所有用户尝试连接
    # (测试通过后务必根据安全需求配置好!)
    
    # 文件末尾可能有的 Match Group administrators ... 部分,
    # 暂时可以不用管它,除非你登录的用户属于 administrators 组且遇到问题。
    
  3. 特别注意 Subsystem sftp :

    • 请务必确保只有一行 Subsystem sftp没有被注释掉 (没有 # 开头)的。
    • 路径 sftp-server.exe 通常是正确的,它是 OpenSSH 安装时自带的。如果用了 internal-sftp,就不用管路径了。
    • 如果你不确定 sftp-server.exe 在不在系统路径里,可以用绝对路径,例如 Subsystem sftp C:\Windows\System32\OpenSSH\sftp-server.exe (具体路径以你服务器上的实际安装位置为准)。
  4. 保存修改并重启服务
    保存对 sshd_config 的修改。然后,打开 PowerShell(管理员权限),运行以下命令重启 OpenSSH Server 服务让配置生效:

    Restart-Service sshd
    

    或者在“服务”(services.msc)里找到 OpenSSH SSH Server 服务,右键点击“重新启动”。

  5. 再次尝试连接
    回到你的 Windows 10 客户端,再次尝试 sshfs-win svc 命令或映射网络驱动器。

安全建议 :

  • 测试时可以暂时放开 AllowUsers / AllowGroups 的限制,但一旦连接成功,强烈建议根据实际需要配置它们,只允许必要的用户或组通过 SSH 访问。
  • 如果可能,优先使用密钥认证(PubkeyAuthentication yes)替代密码认证(PasswordAuthentication yes),安全性高得多。如果使用密钥,确保服务器上对应用户的 .ssh/authorized_keys 文件配置正确。

进阶技巧 :

  • sshd_config 中把日志级别调高,方便排错。找到 LogLevel 配置项,改成 DEBUGVERBOSE。这样在服务器的 OpenSSH 日志(通常在 %programdata%\ssh\logs 目录下)里能看到更详细的连接过程和错误信息。改完记得也要重启 sshd 服务。例如:
    LogLevel DEBUG
    

2. 权限!权限!权限!重要的事说三遍

就算 SFTP 子系统启动了,用户登录也成功了,但如果这个用户对想要挂载的那个服务器文件夹(比如 C:\path\to\sharedfolder)没有足够的访问权限,SSHFS 照样会失败,可能会报“拒绝访问”或者连接直接断开。

原理和作用 :
SSHFS 挂载后,你在本地对 Z: 盘的操作,最终都会转换为 SFTP 命令在服务器上以你登录的那个用户身份执行。所以,这个用户必须拥有对目标目录至少是“读取”和“列出文件夹内容”的 NTFS 权限。如果想写入,还需要“写入”权限。

操作步骤 :

  1. 确认目标文件夹路径 : 在 Windows 11 服务器上,搞清楚你要挂载的文件夹的确切物理路径。比如,你命令里写的 sharedfolder 对应的是 D:\data\shared
  2. 检查 NTFS 权限
    • 在服务器上,右键点击那个目标文件夹 (D:\data\shared),选择“属性”。
    • 切换到“安全”选项卡。
    • 点击“编辑...”或“高级”按钮,查看用户列表里是否包含你 SSHFS 登录时使用的那个用户名(比如 myuser)。
    • 如果列表里有这个用户,选中他,查看下面的权限列表,确保至少勾选了“读取和执行”、“列出文件夹内容”和“读取”这几项。如果需要写入,还要勾选“写入”。
    • 如果列表里没有 这个用户,你需要点击“添加...”,输入用户名,然后“检查名称”确认无误后点“确定”,再给他分配合适的权限。
    • 特别注意 : 如果你用的是 [email protected] 这样的格式,要检查的是 myuser 这个用户;如果是本地账户,就是本地账户名;如果是域账户,就是 DOMAIN\user 格式。确保检查的是同一个用户
  3. 考虑用户组 : 权限也可能通过用户所属的组来继承。检查用户所属的组,看看这些组是否有对目标文件夹的权限。
  4. 非管理员用户 : 如果你用的是一个普通用户账户(非 Administrators 组成员),尤其要注意权限问题。Windows 对非管理员用户的操作限制通常更严格。
  5. 来宾账户/非交互式账户 : 如果你尝试创建“访客”或专门用于文件传输的非交互式账户,情况会更复杂。这类账户可能默认就没有远程登录或执行某些操作的权限。你可能需要在本地安全策略(secpol.msc)里调整“用户权限分配”,比如“允许本地登录”、“允许通过远程桌面服务登录”、“从网络访问此计算机”等策略,虽然不全是直接相关,但可能影响 SSH/SFTP 登录后的能力。不过,对于 SSHFS,最核心的还是目标文件夹的 NTFS 权限。

再次尝试连接 : 调整完权限后,再次尝试 SSHFS 连接。

3. SSHFS-Win 命令和参数,姿势要对

有时候,就是命令敲错了或者路径格式不对。

原理和作用 :
sshfs-win svc 命令后面跟的参数格式是固定的,包括驱动器号、挂载点格式 \\sshfs\\sshfs.r 等,以及目标地址和路径。搞错了自然连不上。

操作步骤 :

  1. 确认基本格式 :
    标准的挂载命令格式是:

    sshfs-win svc <DriveLetter>: \\sshfs\[email protected]<ServerAddress>\/<ServerPath> [-p <Port>] [-o <Options>]
    

    或者,如果要直接挂载服务器用户的根目录或需要管理员权限操作的路径:

    sshfs-win svc <DriveLetter>: \\sshfs.r\[email protected]<ServerAddress>\/<ServerPath> [-p <Port>] [-o <Options>]
    

    .r 表示 "remote",有时用于需要更高权限或不同根路径的情况。

  2. 检查你的命令 :
    对比一下你用的命令:
    sshfs-win svc Z: \\sshfs\[[email protected]](/cdn-cgi/l/email-protection)\sharedfolder

    • Z: 驱动器号没问题。
    • \\sshfs\ 是标准前缀。
    • [email protected] 用户名@服务器地址 格式正确。
    • \sharedfolder 这里可能有点问题 。SSH/SFTP 世界里,路径通常用正斜杠 / 而不是反斜杠 \。并且,这个路径是相对于用户在服务器上的登录主目录 而言的,还是一个绝对路径
  3. 尝试修正路径 :

    • 使用正斜杠 / :
      sshfs-win svc Z: \\sshfs\[[email protected]](/cdn-cgi/l/email-protection)/sharedfolder 
      
    • 指定绝对路径 : 如果 sharedfolder 是服务器根目录下的,比如 C:\sharedfolder,你应该这样写(注意 C: 盘符的特殊表示):
      # 挂载 C:\sharedfolder
      sshfs-win svc Z: \\sshfs\[[email protected]](/cdn-cgi/l/email-protection)/C:/sharedfolder
      
      或者对于 D 盘的 D:\data\shared:
      # 挂载 D:\data\shared
      sshfs-win svc Z: \\sshfs\[[email protected]](/cdn-cgi/l/email-protection)/D:/data/shared 
      
    • 指定相对于家目录的路径 : 如果 sharedfolder 就在用户 myuser 的家目录(比如 C:\Users\myuser\sharedfolder)下,那么可以直接写相对路径:
      sshfs-win svc Z: \\sshfs\[[email protected]](/cdn-cgi/l/email-protection)/sharedfolder
      
      或者甚至只挂载家目录本身:
      sshfs-win svc Z: \\sshfs\[[email protected]](/cdn-cgi/l/email-protection)/
      
  4. 端口号 :
    sshfs-win svc Z: \\sshfs\[[email protected]](/cdn-cgi/l/email-protection)!22\sharedfolder 这种用 ! 加端口号的格式,也是支持的。如果你的 SSH 服务器确实监听在 22 端口(默认),其实可以不写。如果改了端口,比如 2222,那就要写 !2222 或者使用 -p 2222 参数:

    sshfs-win svc Z: \\sshfs\[[email protected]](/cdn-cgi/l/email-protection)/path -p 2222
    
  5. 使用 -o 选项增加调试信息 :
    在命令后面加上 -o LogLevel=DEBUG 可以让 SSHFS-Win 在客户端输出更详细的日志,有助于定位问题。日志文件通常在 %USERPROFILE%\AppData\Local\sshfs-win\log

    sshfs-win svc Z: \\sshfs\[[email protected]](/cdn-cgi/l/email-protection)/path -o LogLevel=DEBUG
    

再次尝试连接 : 用修正后的命令再试试。

4. 防火墙和网络,再瞅瞅

虽然你说 22 端口开了,但还是值得复查一下,特别是 Windows Defender 防火墙的高级设置。

原理和作用 :
防火墙规则没配对,或者有其他网络中间设备(虽然这里是直连局域网,可能性小)捣乱,都可能导致连接在特定阶段被切断。

操作步骤 :

  1. 确认服务器防火墙规则 :

    • 在 Windows 11 服务器上,搜索“高级安全 Windows Defender 防火墙”。
    • 检查“入站规则”。确保有一条规则允许 TCP 端口 22 的连接。
    • 双击该规则,确认其“已启用”,操作是“允许连接”,“配置文件”(域、私有、公用)至少覆盖了你当前客户端连接所处的网络类型(比如“私有”)。“作用域”里远程 IP 地址通常是“任何 IP 地址”,除非你有特定限制。
    • 临时测试 : 作为最后的排查手段,极其不推荐在生产环境操作 ,但可以临时 禁用服务器上对应网络配置文件的防火墙(比如“私用配置文件”),然后立刻尝试 SSHFS 连接。如果能连上,说明确实是防火墙规则问题,需要仔细调整规则而不是一直关着。测试完务必 重新启用防火墙。
  2. 客户端防火墙 : 客户端(Windows 10)的防火墙通常只管出站连接,默认策略一般比较宽松,不太会阻止 SSHFS,但也值得一看。

再次尝试连接 : 检查或临时调整防火墙后重试。

5. 更新和重装,终极大招?

如果上述方法都不行,可以考虑是不是软件本身的问题。

原理和作用 :
软件旧版本可能存在已知的 Bug,新版本可能修复了这些问题,或者与操作系统的兼容性更好。重装可以解决因安装过程中断、文件损坏等引起的问题。

操作步骤 :

  1. 检查更新 :
    • 访问 WinFsp 官网 和 SSHFS-Win GitHub Releases 页面,看看有没有更新的版本。
    • 在 Windows 11 服务器上,检查 OpenSSH Server 是否是最新版本(可以通过 Windows Update 或者手动安装 OpenSSH 的方式来更新)。
  2. 卸载重装 :
    • 在 Windows 10 客户端:
      • 先尝试卸载 SSHFS-Win。
      • 然后卸载 WinFsp。
      • 重启电脑。
      • 下载最新稳定版的 WinFsp 并安装。
      • 下载最新稳定版的 SSHFS-Win 并安装。
    • 在 Windows 11 服务器:
      • 如果怀疑 OpenSSH Server 安装有问题,可以在“应用和功能”或通过 PowerShell 卸载 OpenSSH Server 功能,重启,然后再重新安装它。记得备份你的 sshd_config 文件。

再次尝试连接 : 更新或重装后,用之前确认过没问题的命令和配置再试一次。

希望通过上面这些步骤,你能找到导致 SSHFS-Win "connection reset by peer" 或 "Access denied" 的真凶,顺利挂载你的 SSH 目录。记住,排查这类问题,耐心和细致最重要,一步步来,多看看日志信息,往往就能找到突破口。