日常运维，或者自己在家里和办公室折腾服务器的时候，总会碰上这种场景：一边是Linux服务器，一边是Windows 10电脑，文件需要频繁倒来倒去。传日志、传脚本、传配置文件，这些文件说大不大说小不小，U盘来回插太麻烦，网盘中转绕一圈又总觉得数据过了一道别人的手。其实Win10系统内置了OpenSSH的服务端能力，Linux这边更是天生自带SSH客户端。只要把Win10的OpenSSH服务端启起来，让Linux能走SSH协议连过来，文件互传就变成了非常简单的事：日常用scp一条命令搞定，批量场景用sftp批处理脚本完成。这篇文章把整条链路拆开讲清楚，从为什么选OpenSSH、怎么配置Win10，到实际传输命令和常见问题排查，一步步写下来，给同样有“Linux服务器和Win10之间互传文件”需求的人做个完整参考。
1. 整体设计思路：为什么是OpenSSH
1.1 常见文件互传方案的对比
先说结论：文件互传这件事，可选方案非常多，但绝大多数都有明显的适用边界。SMB共享是Windows天然支持的方式，Linux端通过挂载cifs也能访问，单机场景确实顺手。但SMB在跨网段、跨复杂网络环境时经常遇到端口冲突、协议版本不一致、权限校验这些麻烦，而且只是为了传几个小文件专门开一个共享服务，显得很重。
FTP也算经典方案，但传统FTP默认明文传输，用户名密码直接在网络上裸奔。内网环境也许没人盯着，一旦数据稍微敏感一点，就得给FTP额外配置TLS加密，工作量又上去了。网盘中转确实方便，但上传下载都要走第三方服务，对于服务器上的配置文件、脚本、日志这种内容，绕路且隐私不受控。第三方局域网快传工具平时用着挺好，可有些需要两端都装客户端，还有些在Windows和Linux之间的兼容性并不稳定。
OpenSSH方案的本质是“两台机器之间直接建立一条加密通道”。Linux端自带ssh、scp、sftp命令，Win10也能通过系统可选功能安装OpenSSH服务端，不需要安装任何第三方商业软件。对比下来，它是成本最低、链路最短、默认加密的选择。
| 方案 | 加密传输 | 系统自带程度 | 适合场景 | 主要痛点 |
|---|---|---|---|---|
| SMB | 部分场景可加密 | Win10自带，Linux需额外客户端 | 长期目录共享 | 跨网段配置复杂 |
| FTP | 默认不加密 | 需搭建服务端 | 临时传输 | 明文密码风险 |
| 网盘中转 | 传输链路加密 | 依赖第三方 | 跨设备零配置 | 隐私不可控 |
| OpenSSH | 全程加密 | 两端几乎零依赖 | 服务器互传/脚本化传输 | 初次配置需要理解权限 |
1.2 一次配置、长期受益的链路设计
这套结构里，Win10扮演SSH服务端的角色，Linux作为客户端发起连接。用户从Linux上执行scp或sftp命令，通过Windows账户密码或公钥认证登录到Windows，然后在加密通道里完成文件传输。理解了这个角色关系，后面的配置思路就不会乱：Linux侧几乎不需要装东西，重点全部在Win10侧的“服务端能不能被连上”。
有人会问，为什么不让Win10做客户端、Linux做服务端？如果只是单向传文件，确实可以反过来。但我更推荐让Linux作为统一入口：后续无论是写同步脚本、加定时任务，还是对多台Windows机器做批量管理，操作都集中在一台Linux上完成，数据流向、日志记录、权限管控都更可控。SSH通道本身自带压缩能力，小文件传输时速度体感和FTP差不多，但安全性和可审计性好一个量级。实际用下来，这套链路特别适合“Linux服务器定期拉取Win10机器上的业务日志、配置备份、临时提数文件”这类重复性场景。一次配置好，后面就是敲命令和写脚本的事。
2. 环境准备与核心配置
2.1 在Win10上启用OpenSSH服务端
第一步先确认系统版本。较新版Win10都在系统能力列表里带了OpenSSH，不需要去网上下载安装包，只需要把功能打开。图形化操作路径是：设置 → 应用 → 应用和功能 → 可选功能 → 添加功能 → 找到“OpenSSH服务器”，点击安装。
如果习惯用命令行，管理员权限的PowerShell里执行这两条更直接：
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*' Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0第一条命令是确认当前系统里有没有可用的OpenSSH能力，第二条才是真正安装服务端。安装完成后，在“服务”里能看到ssh-agent和sshd两个服务，我们真正依赖的是sshd。手动启动并设置开机自动运行：
Start-Service sshd Set-Service -Name sshd -StartupType 'Automatic'验证服务是否正常运行：
Get-Service sshd如果状态显示Running，说明服务端已经起来了。但这时候还不能急，防火墙那一关没过，外部机器照样连不进来。
2.2 防火墙放行与网络侧准备
Windows默认防火墙在没有匹配规则时会拦截外部对22端口的访问。安装OpenSSH服务器时，系统有概率自动创建一条名为“OpenSSH-Server-Inbound-TCP”的内置规则，但我也遇到过精简版系统或手动安装OpenSSH的环境里没有自动生成规则的情况，所以建议手动确认一遍。
管理员PowerShell里执行：
New-NetFirewallRule -Name 'OpenSSH-Server-Inbound' -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22有一个细节特别容易忽视：Windows防火墙规则分为“公用网络”和“专用网络”配置文件。如果网卡被标记为公用网络，即使规则存在，也可能因为配置文件不匹配而照样拦截连接。建议把内网连接设置为“专用网络”，路径是设置 → 网络和Internet → 更改连接属性 → 网络配置文件选择“专用网络”。设置完先在Linux端ping一下Win10的IP，通了这个阶段才算过。
注意：以上配置场景是局域网内使用。如果要把Win10的22端口暴露到公网，强烈不建议直接裸奔开放，很容易被自动化扫描工具盯上。生产中至少要做端口更换、来源IP白名单、或者走跳板机，那是另一个话题。
2.3 准备登录身份：密码认证与公钥认证
SSH连接Windows需要一个能登录的Windows账号。这里有个容易混淆的点：如果你登录Windows用的是微软在线账户，SSH登录时使用的是Windows本地账户的密码，和微软账户云端那套不是一回事。如果本地账户没有设置密码，SSH服务会直接拒绝密码认证，所以第一步是给Win10当前用户设置一个密码。
内网环境用密码认证已经够用。但如果你希望后续写脚本定时同步文件、不想每次都输密码，就在Linux上生成一对密钥，把公钥放到Windows用户目录下。Linux端生成密钥：
ssh-keygen -t ed25519 -C "linux-to-win10"将公钥内容手动追加到Win10端对应的authorized_keys文件。Windows上不像Linux有ssh-copy-id命令，需要手动创建：
C:\Users\winuser\.ssh\authorized_keys公钥文件放置好之后，权限要求非常严格。权限不对，即使公钥内容完全正确，sshd也会拒绝使用，这是Windows OpenSSH最容易踩的坑之一，下面问题排查部分会专门展开。
2.4 调整默认Shell与配置文件关键项
Windows OpenSSH服务端的默认Shell通常是cmd.exe，意味着通过SSH登录Win10后执行的是cmd命令。对纯文件传输影响不大，但如果准备通过scp路径做更复杂的操作，或者希望登录后能用更接近Linux的习惯执行命令，建议把默认Shell改成PowerShell：
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force改完重启sshd：
Restart-Service sshdsshd的主配置文件在C:\ProgramData\ssh\sshd_config，有几个参数值得关注。内网环境建议确保PasswordAuthentication为yes，同时PubkeyAuthentication保持yes；如果只想让指定用户远程登录，可以在文件末尾加AllowUsers段落，比如AllowUsers winuser。每次修改配置后都重启sshd服务，这个习惯可以避免很多“改了半天没生效”的困惑。
3. 文件互传实操：scp与sftp
3.1 Linux向Win10推文件
scp是最直接的传输命令，基本格式是“scp 源路径 登录用户@主机IP:目标路径”。从Linux推一个文件到Win10桌面：
scp /home/linuser/test.txt winuser@192.168.1.10:/C:/Users/winuser/Desktop/注意Windows路径的写法，sshd服务端希望收到的是绝对路径，使用斜杠形式：/C:/Users/winuser/Desktop。如果目标路径包含空格，一定要加双引号包裹：
scp /home/linuser/test.txt "winuser@192.168.1.10:/C:/Users/winuser/My Documents/"复制整个目录加-r参数：
scp -r /home/linuser/logs winuser@192.168.1.10:/C:/Users/winuser/Desktop/反向操作同样简单，把源路径和目标路径对调即可：
scp winuser@192.168.1.10:/C:/Users/winuser/Desktop/report.log /home/linuser/如果SSH端口不是默认的22，注意是大写P参数指定端口：
scp -P 2222 /home/linuser/test.txt winuser@192.168.1.10:/C:/Users/winuser/Desktop/实测下来，小文件用scp基本是秒级完成，配合密钥认证后连密码都不用输，非常顺手。
3.2 sftp交互式浏览与批处理传输
scp适合单次、规律性复制，但如果你需要先看看Win10那边有哪些文件、再决定下载哪些，sftp更合适。连接方式：
sftp winuser@192.168.1.10进入交互模式后，经常用到的子命令有这些：
- pwd：查看远程当前目录
- lpwd：查看本地当前目录
- cd 路径 / lcd 路径：切换远程/本地目录
- get 文件名：把远程文件下载到本地
- put 文件名：把本地文件上传到远程
- mget *.log：批量下载
- mput *.txt：批量上传
- bye：退出
举例，把Win10桌面上所有log文件拉到Linux备份目录：
cd /C:/Users/winuser/Desktop lcd /home/linuser/backup mget *.log bye文件量大时，一个个交互操作还是麻烦，sftp支持批处理模式。把命令写进batch.sftp文件：
cd /C:/Users/winuser/Desktop lcd /home/linuser/backup mget *.log bye执行：
sftp -b batch.sftp winuser@192.168.1.10批处理模式很适合放进crontab定时任务。我实际配置过的最常用场景是：Linux服务器每天凌晨用sftp -b把Win10机器上的业务日志拉回本地归档，配合密钥认证，全程无人干预，连续跑几个月都很稳定。
3.3 效率优化：rsync、断点续传与目录同步
如果同步的是大量小文件，scp和sftp都偏慢，因为它们是逐文件拷贝，没有任何增量机制。Linux上更优的选择是rsync，通过SSH通道执行：
rsync -avz --progress /home/linuser/data/ winuser@192.168.1.10:/C:/Users/winuser/data/但这里有个前提：Windows端必须能执行rsync命令，而原生OpenSSH for Windows并不包含rsync。如果不想在Windows上额外装软件，普通文件互传保持scp/sftp就够了，不要为了增量同步引入一套复杂依赖。我见过有人为此在Windows上装了一整套模拟环境，最后维护成本比传文件本身还高，完全不划算。
如果遇到大文件传输中途网络闪断，scp和sftp都没有断点续传能力，只能重传。这种情况下我建议先压缩再传，既减少文件数量，也降低中断概率：
tar czf logs.tar.gz /home/linuser/logs scp logs.tar.gz winuser@192.168.1.10:/C:/Users/winuser/网络实在不稳定时，还可以配合split把压缩包切成多个分段。这些土办法虽然不优雅，但确实管用。真正常态化的大文件增量同步，还是优先考虑给Windows端补上rsync能力，或者把传输方向反过来，用Linux的rsync daemon模式处理。
4. 常见问题与排查思路
4.1 端口通、服务没起：藏在服务窗口里的问题
现象是Linux端执行ssh连接时报Connection refused，或者直接timeout。两者的排查方向不同：timeout多半是防火墙拦着，connection refused则大多数是sshd服务没在运行。连接前先在Linux端测一下端口：
nc -vz 192.168.1.10 22如果返回refused，去Win10上检查sshd服务状态：
Get-Service sshd服务没启动就Start-Service sshd，并顺手把启动类型改成Automatic。安装完OpenSSH后服务默认不是自启，很多人配置完一切正常，重启一次Win10就再也连不上了，原因就在这。
4.2 密码正确但登录被拒
现象是密码输入多次还是Access denied。通常有三个原因。第一，sshd_config里的PasswordAuthentication被改成了no，改成yes并重启服务。第二，Windows本地账户没设密码，SSH服务不允许空密码登录，给账户设个密码就好。第三，登录使用的是微软在线账户，却拿微软账户的密码去连，SSH只认本地账户体系。
还有一个经常被忽略的情况：Windows的Administrator账户默认是禁用的，打算用Administrator登录需要先在“计算机管理 → 本地用户和组”里启用。出于安全考虑，日常使用建议单独建一个普通用户来登录SSH，别全程用管理员。
4.3 公钥认证报权限错误
现象是Linux端已经把公钥放到Windows用户目录的authorized_keys里，但登录时仍然要求密码，或者sshd日志中出现类似“bad ownership or modes for file”的错误。
Windows OpenSSH对文件权限和ACL要求很严格：authorized_keys文件不能允许其他用户有写权限，整个.ssh目录也不能带着乱七八糟的继承权限。在cmd或PowerShell里重置ACL是标准操作：
icacls "C:\Users\winuser\.ssh\authorized_keys" /inheritance:r /grant "winuser:F"如果不知道当前授权状态，先用icacls查看：
icacls "C:\Users\winuser\.ssh\authorized_keys"还有一个细节：公钥文件内容末尾要有换行符，别用老版本记事本把它存成带BOM的UTF-8格式，否则解析公钥时会报错。新版Win10记事本默认无BOM，但老旧机器还是要检查一下。
4.4 连接缓慢的常见原因
现象是SSH连接能通，但输密码前或进入会话前总要卡几秒。最大的嫌疑是DNS反向解析和GSSAPI认证。在sshd_config里把UseDNS设为no，同时Linux客户端侧ssh命令加参数去掉GSSAPI认证：
ssh -o GSSAPIAuthentication=no winuser@192.168.1.10更省事的方式是写进~/.ssh/config，以后每次连接都自动生效：
Host 192.168.1.10 GSSAPIAuthentication no ServerAliveInterval 30ServerAliveInterval可以保持长连接不假死，对长时间sftp会话特别友好。这个配置同样作用于scp，因为底层走的是同一条SSH通道。
4.5 特殊文件名与中文路径的处理
现象是Windows文件名里带空格或中文字符，scp/sftp时提示找不到路径。核心解法是把目标路径用双引号保护起来，尽量避免裸奔的特殊字符。sftp交互模式下，路径含空格时可以输入cd "C:/Users/winuser/My Documents"这样带引号的路径，能正常工作。
但最省心的办法其实是从源头规避：在Win10上建一个专门用于文件互传的短目录，比如C:\data_share，路径里不要有空格、中文和特殊符号，所有互传操作都限定在这个目录里。这样能省掉大量转义问题，尤其是写脚本的时候，路径越简单越不容易翻车。
4.6 传一半断线怎么办
大文件传输中网络闪断，sftp会直接中断并且不续传，scp同样如此。唯一的办法是重传，或者退一步用压缩方案：
tar czf logs.tar.gz /home/linuser/logs scp logs.tar.gz winuser@192.168.1.10:/C:/Users/winuser/压缩后再传有几个好处：文件数量从一大摞变成一个，小文件传输的握手开销全减掉了，传输时间更短，中断概率也更低。还可以配合split把大压缩包切成若干段分批传。对于隔三差五传大文件的场景，我建议别每次都现场临时处理，直接在脚本里加上压缩步骤，稳定很多。
5. 我在实际使用中的一点体会
OpenSSH连接Win10这套方案，我在不同机器上反复配置过多次，整体感受是“一次配置，长期免维护”。只要把sshd服务设为自动启动、防火墙规则加好、公钥权限放对，后面就是随时敲命令传文件的事，根本不需要再折腾第三方工具。
还有个小细节分享一下：Windows端的ssh-agent服务，如果平时不用证书转发可以保持手动，但如果你用密钥登录且密钥本身设置了密码，建议把ssh-agent启用并把密钥加进去，这样scp传文件时不用反复输密钥密码。配置好之后，从Linux到Win10的文件互传体验和Linux机器之间几乎没有任何区别。
对于刚上手的人，我给的建议是：先在Linux端用命令行手动跑通一次密码登录，确认整条链路没问题，再升级成公钥认证。每次修改sshd_config后，在Win10本地先用ssh回环连一下localhost做验证，如果连localhost都连不上，多半是配置改坏了，而不是网络问题。这套检查顺序能帮你快速缩小问题范围，省下大量排查时间。
