Windows 11 里本身就藏着一套完整的 OpenSSH 组件多数人只把它当客户端用其实掉过头来把它跑成一台正儿八经的 SSH 服务器前后也就十几分钟。我最早动手是因为手头三台机器一台放书房的主力台式、一台接电视当播放器和编译节点的迷你主机、一台出差随身带的轻薄本。编译产物在三台之间来回倒插 U 盘太慢走网盘又嫌绕一圈索性在台式机上把 SSH 服务器开起来默认的 22 端口换成一个自己记得住的高位端口密码登录直接关掉只留密钥vscode 远程开发、scp 推文件、脚本批量执行全走这一条链路用了挺长一段时间没出过岔子。这篇就把这套 Windows 11 SSH 服务器的配置从头到尾写一遍服务怎么装、端口怎么改、防火墙规则怎么跟着动、密钥怎么落地、权限上那两个最容易翻车的坑在哪以及改完之后连不上时按什么顺序去排查。适合两类人看——一类是完全没碰过 SSH 服务端、只想让手上的 Windows 机器能被远程连上的新手另一类是在 Linux 上折腾惯了、第一次在 Windows 上配 sshd 结果被administrators_authorized_keys和 ACL 权限搞懵的老手。文中所有操作我都在 Windows 11 专业版上实测过家庭版同样适用命令以 PowerShell 为主需要图形界面的地方也会把点击路径写清楚。1. 先把方案想清楚Windows 上开 SSH 服务到底解决什么问题1.1 三个我实际遇到的场景决定了这套配置的取舍第一个场景是远程开发和编辑。主力台式放在书房人有时候在客厅用轻薄本需要直接改台式机上的代码仓库、跑构建、看日志。装了 vscode 之后用 Remote-SSH 插件连过去编辑体验和本地几乎没差别终端、调试器、端口转发全都在远端那台机器上跑。这个场景对 SSH 的要求是长连接稳定、支持端口转发、不依赖图形界面密钥登录在这时候不只是安全考虑更是省事——脚本和插件不会弹出密码框等你输入。第二个场景是跨设备传文件。三台机器之间传几十 GB 的数据集或者二进制产物走 sftp、scp 比网盘靠谱得多速度基本跑满内网带宽也不用担心同步延迟和链接过期。sftp 子系统在 Windows OpenSSH 里是默认开启的这点很省心。第三个场景是无人值守的批处理。比如晚上十一点在台式机上跑一批数据清洗人已经离开书房用另一台机器一句ssh win11 powershell -File D:\scripts\run.ps1就把活派下去。这种场景下密码登录是硬伤因为非交互式执行根本没法输入密码必须走密钥。这三个场景叠加起来配置上的取舍就很清楚了端口必须换默认端口在局域网里被各种设备扫描的频率高得离谱日志会被噪声刷满、密钥必须配交互和非交互都要能用、密码登录要关减少暴露面同时避免有人拿弱密码试。而 Windows 独有的坑主要集中在用户权限模型和文件 ACL 上这部分后面单独用一节讲。1.2 OpenSSH 在 Windows 上的两种安装方式怎么选Windows 11 提供了两条路。第一条是系统自带的可选功能通过设置 → 系统 → 可选功能或者 PowerShell 命令安装装完之后 OpenSSH 的服务、配置、二进制都落在C:\Windows\System32\OpenSSH\下跟随系统更新稳定性最好。这也是我推荐的方式尤其是准备长期当服务用的机器。第二条是用 winget 或者直接下官方压缩包。winget install Microsoft.OpenSSH.Beta这条路装出来的版本往往比系统自带的新支持一些新特性但服务注册、路径、更新方式都得自己管出问题的时候排查链条更长。我的建议是如果只是想要一个稳定可用的 SSH 服务端用系统可选功能如果明确需要新版本里的某个特性比如某些新的密钥算法或配置指令再去考虑独立安装。还有一种情况是 Windows Server 或者某些精简版系统可选功能列表里可能看不到 OpenSSH 服务器这时候用 PowerShell 的Add-WindowsCapability命令通常能装上。1.3 和 Linux 上的 sshd 比差异点在哪差异不小配之前心里得有数否则很容易按 Linux 的直觉去操作然后卡住。对比项Linux (OpenSSH)Windows 11 (OpenSSH)主配置文件位置/etc/ssh/sshd_configC:\ProgramData\ssh\sshd_config主机密钥位置/etc/ssh/ssh_host_*C:\ProgramData\ssh\ssh_host_*服务管理systemd / sysvinitWindows 服务sshd、ssh-agent防火墙iptables / firewalld / ufwWindows Defender 防火墙规则普通用户公钥~/.ssh/authorized_keysC:\Users\用户\.ssh\authorized_keys管理员用户公钥同上C:\ProgramData\ssh\administrators_authorized_keys权限模型POSIX 权限位NTFS ACL日志/var/log/auth.log 等事件查看器 OpenSSH/Operational最后两行是关键。Windows 没有 600、700 这种权限位sshd 校验的是 NTFS ACL而属于 Administrators 组的用户公钥文件的位置和普通用户完全不一样这个是新手最容易卡住的地方配了半天一直提示Permission denied (publickey)多半就是踩了这个。2. 安装与验证把 sshd 服务先跑起来2.1 用 PowerShell 安装 OpenSSH 服务器组件图形界面的路径是设置 → 系统 → 可选功能 → 查看功能 → 搜索 OpenSSH会看到两个条目OpenSSH 客户端和OpenSSH 服务器。Windows 11 默认已经装了客户端需要手动勾选的是服务器。命令行更快先用一条命令确认当前状态Get-WindowsCapability -Online | Where-Object Name -like OpenSSH*输出里State字段是NotPresent就表示没装。装服务器组件Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0注意这个命令需要管理员权限的 PowerShell 窗口普通窗口会报拒绝访问。安装过程会联网拉取组件包几十兆的样子一分钟内能结束。装完之后C:\Windows\System32\OpenSSH\目录下会出现sshd.exe、ssh-keygen.exe、sftp-server.exe这些可执行文件。客户端如果也没装把上面命令里的Server换成Client再跑一次就行。客户端在服务端机器上不是必须的但留着方便本地自测我一般都会装。2.2 启动服务并设置开机自启OpenSSH 服务器装完之后注册了两个服务sshd和ssh-agent。前者是服务端主进程后者负责管理私钥只有在用到密钥转发之类的高级功能时才需要它常驻。Start-Service sshd Set-Service -Name sshd -StartupType Automatic Get-Service sshd, ssh-agent | Select-Object Name, Status, StartType第一行把服务拉起来第二行改成开机自动启动——这一步很多人会漏结果重启一次机器服务就没了第二天连不上还以为配置坏了。第三行是确认正常应该看到sshd的Status是Running、StartType是Automatic。ssh-agent我一般设成手动启动需要的时候再开。它常驻会占用一点内存而且 Windows 上私钥的存储和 Linux 的行为不完全一致除非要做密钥转发或者多个密钥频繁切换否则没必要一直挂着。提示如果Start-Service sshd报错先去看事件查看器里的OpenSSH/Operational日志。九成情况是配置文件语法有问题或者主机密钥生成失败。首次启动时 sshd 会在C:\ProgramData\ssh\下自动生成ssh_host_rsa_key、ssh_host_ed25519_key等主机密钥如果这个目录被权限锁住了服务起不来。2.3 防火墙放行与本地自测安装过程中Windows 一般会自动创建一条入站规则OpenSSH-Server-In-TCP放行 22 端口。先确认一下规则存不存在Get-NetFirewallRule -Name *ssh* | Select-Object Name, DisplayName, Enabled, Direction, Action理想输出是能看到OpenSSH-Server-In-TCP并且Enabled为True。如果没看到手动建一条New-NetFirewallRule -Name OpenSSH-Server-In-TCP -DisplayName OpenSSH Server (sshd) -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22防火墙规则这一步先按默认端口建等下面改成自定义端口时再回来改LocalPort顺序上更清楚。服务起来、规则放行之后先在本机自测一次把「服务能不能被连」和「网络通不通」这两个问题拆开ssh 127.0.0.1首次连接会问Are you sure you want to continue connecting输入yes然后输入当前 Windows 账号的密码能进到一个命令行提示符就说明服务端基本正常。这一步没通过的话后面所有配置都是白搭必须先把这里打通。注意如果当前账号没有设置密码或者用的是 Microsoft 账号登录、本地密码和账户密码不一致密码登录会失败。这种情况先用net user 用户名 *设置一个本地密码或者直接跳到第 4 节配密钥登录。Microsoft 账号登录的机器SSH 用的密码是你账户的密码但如果开了 PIN 或 Windows HelloPIN 是不能用于 SSH 的。3. 改端口从 22 换到一个自己记得住的高位端口3.1 为什么要改以及改端口解决不了什么默认 22 端口在局域网里被扫描的频率非常高。各种网络设备、NAS、打印机、其他装了扫描功能的软件都会定时往 22 端口敲门结果是OpenSSH/Operational日志里塞满失败的连接尝试真出问题的时候根本找不到有用的信息。换一个非标准端口最直接的好处就是日志干净了排查问题时一眼能看到自己的连接记录。另外改端口能挡掉绝大部分自动化扫描和弱密码尝试。这不是什么高深的安全手段本质上就是降低被随机撞上的概率——攻击面从「所有扫 22 的设备」缩小到「知道你这个端口的设备」。但要说清楚改端口的边界它不能替代密钥登录也不能替代防火墙限制来源 IP。如果端口是通过某种方式泄露出去的或者有人在内网做了全网段端口扫描改端口的防护就基本失效了。所以端口、密钥、来源 IP 限制这三件事是叠加关系不是替代关系。我个人的习惯是选一个 20000 到 60000 之间、和自己其他服务不冲突的端口记在密码管理器里客户端通过~/.ssh/config配置平时不用手敲。3.2 找到 sshd_config 并逐条读懂关键参数Windows 上 sshd 的主配置文件在C:\ProgramData\ssh\sshd_config。这个路径有两个特点要注意一是ProgramData默认是隐藏目录资源管理器里得先打开「显示隐藏项目」才能看到二是这个文件编辑需要管理员权限用记事本直接打开保存会提示权限不足。我一般用管理员权限的记事本或者 vscode 打开notepad C:\ProgramData\ssh\sshd_config打开之后会看到一份带大量注释的默认配置绝大多数行前面都有#表示用内置默认值。需要动的其实只有几行。先把关键的几项列出来参数默认值作用我的建议Port22注释状态监听端口改成自定义高位端口ListenAddress0.0.0.0监听的网卡地址多网卡机器可指定内网 IPPasswordAuthenticationyes是否允许密码登录密钥配好后改 noPubkeyAuthenticationyes是否允许密钥登录保持 yesAuthorizedKeysFile.ssh/authorized_keys普通用户公钥路径保持默认MaxAuthTries6单次连接最大认证尝试次数可以降到 3LoginGraceTime2m认证超时时间局域网可以降到 30sClientAliveInterval0服务端保活探测间隔设 60 减少断连Subsystem sftp已启用sftp 子系统保持启用改端口就是找到#Port 22这一行去掉注释改成自己的端口号。这里有个细节Windows 版 sshd_config 里Port默认是注释掉的如果你只改数字不删#配置不会生效服务重启后还是监听 22。我见过有人改完发现没反应折腾半天就是这个原因。3.3 完整的改端口流程与防火墙同步把下面这几步按顺序做完中间不要跳步。第一步备份原配置出问题能立刻回滚Copy-Item C:\ProgramData\ssh\sshd_config C:\ProgramData\ssh\sshd_config.bak第二步编辑配置。把#Port 22改成Port 22222同时把保活相关的两行也放开长时间挂着 vscode 远程的时候很有用ClientAliveInterval 60 ClientAliveCountMax 3第三步校验配置语法。sshd 提供了一个测试模式能在不重启服务的情况下检查配置有没有语法错误 C:\Windows\System32\OpenSSH\sshd.exe -t输出为空表示没问题如果有bad configuration option之类的提示说明某个参数拼错了或者这个版本不支持改回去再测。这一步能省掉很多「重启完服务起不来」的麻烦。第四步改防火墙规则的端口。前面如果已经建了OpenSSH-Server-In-TCP直接改它的LocalPortSet-NetFirewallRule -Name OpenSSH-Server-In-TCP -LocalPort 22222 -Protocol TCP如果原来的规则是安装时自动创建的名字可能带后缀先用Get-NetFirewallRule -DisplayName *OpenSSH*确认一下实际名称。也可以不删旧规则、直接新建一条旧的那条禁用掉即可。我倾向改而不是新建规则列表干净。第五步重启服务让配置生效Restart-Service sshd Get-NetTCPConnection -LocalPort 22222 -State Listen第二行是验证能看到一条Listen状态的记录就说明服务真的在监听新端口了。第六步用新端口连接测试ssh -p 22222 127.0.0.1注意改端口和验证的顺序很关键。一定要在断开当前会话之前先在另一个窗口用新端口连上一次。如果你是通过远程连接在操作这台机器改完端口重启服务当前连接会断而新端口万一没配好你就彻底连不上了只能去物理机器前或者用其他远程手段救。我吃过这个亏后来养成了「开两个终端窗口一个不动另一个测新配置」的习惯。3.4 端口被占用怎么办三步定位到进程选端口的时候偶尔会撞上已经被人占用的端口表现是 sshd 服务启动失败事件日志里提示bind: Address already in use或者类似信息。Windows 上查端口占用的手段比 Linux 直观一些。第一步看这个端口有没有人在听netstat -ano | findstr :22222输出最后一列是进程 PID。或者用更现代的 cmdletGet-NetTCPConnection -LocalPort 22222 | Select-Object LocalAddress, LocalPort, State, OwningProcess第二步拿 PID 反查进程Get-Process -Id PID | Select-Object Id, ProcessName, Path第三步如果确认是别的软件占着换一个端口就行没必要去动别人的服务。如果那个进程是某个系统组件的保留端口那就更不要碰。补充一个排查连接问题的命令比 telnet 好用Windows 11 上自带Test-NetConnection -ComputerName 192.168.1.10 -Port 22222它会依次报告 DNS 解析、ICMP ping、TCP 握手的结果一眼就能看出是网络不通还是端口没开。很多「连不上」的问题在这一步就能定性TcpTestSucceeded是False说明防火墙或者服务监听有问题是True但还是连不上那就是认证层面的问题往第 4 节看。4. 密钥登录把密码关掉才算真的配好了4.1 生成密钥对算法和参数怎么选在客户端机器上生成密钥对。Windows 11 自带ssh-keygen直接在 PowerShell 里敲ssh-keygen -t ed25519 -C win11-home-desktop -f $env:USERPROFILE\.ssh\win11_home参数逐个解释一下。-t ed25519指定算法Ed25519 是目前的主流选择密钥短、生成快、安全性足够兼容性也早就不是问题了。如果客户端是某些老旧的嵌入式设备或者老版本的 SSH 实现可能不支持 Ed25519那就退回-t rsa -b 4096RSA 4096 位兼容性最好代价是密钥文件大一点、握手时计算量高一些。-C后面跟的是注释会写进公钥文件的末尾。这个字段看起来没用但当你手上攒了七八个密钥、known_hosts和authorized_keys里一堆长得差不多的字符串时注释就是唯一的身份标识。我现在的命名习惯是设备-用途比如laptop-work、mini-pc-deploy一眼就能看出该不该吊销。-f指定输出路径。不指定的话默认是~/.ssh/id_ed25519多密钥场景下很容易互相覆盖所以我一律显式指定。执行之后会提示输入 passphrase这个可以留空也可以设一个。留空的好处是自动化脚本不用交互坏处是私钥文件一旦泄露就等于直接交出访问权。折中方案是设 passphrase然后用 ssh-agent 加载一次之后会话内都不用再输。桌面环境下我建议设纯自动化节点上留空、靠文件权限保护。生成完会得到两个文件win11_home私钥绝对不能外传和win11_home.pub公钥就是要往服务端放的那个。先确认一下权限icacls $env:USERPROFILE\.ssh\win11_home正常的私钥文件应该只有当前用户有完全控制权SYSTEM和Administrators可能有读取权限Windows 上很难完全去掉但不应该有 Users 组或其他普通用户的权限。如果发现权限过宽用下面命令收紧icacls $env:USERPROFILE\.ssh\win11_home /inheritance:r /grant:r $env:USERNAME:(R)4.2 公钥落地普通用户和管理员用户是两个完全不同的位置这是 Windows 上配 SSH 密钥最容易翻车的地方单独拎出来说。服务端上的公钥文件位置取决于登录用户是不是属于 Administrators 组普通用户不在 Administrators 组C:\Users\用户名\.ssh\authorized_keys管理员用户属于 Administrators 组C:\ProgramData\ssh\administrators_authorized_keys为什么会有这个区别因为 Windows 版的默认sshd_config末尾有这么一段Match Group administrators AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys意思是如果登录用户属于 administrators 组那么公钥只从C:\ProgramData\ssh\administrators_authorized_keys里找C:\Users\用户名\.ssh\authorized_keys里放了也没用。很多人包括我第一次配的时候公钥老老实实放到用户目录下然后一直Permission denied (publickey)看日志也看不出所以然就是这个原因。而且这个文件是所有管理员共用的多个管理员账号的公钥都往这一个文件里追加。先把公钥内容取出来如果客户端和服务端是同一台机器直接读文件即可跨机器的话用 scp 或者复制粘贴Get-Content $env:USERPROFILE\.ssh\win11_home.pub然后在服务端上按用户类型选择路径写入。这里以管理员用户为例$pubkey ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... win11-home-desktop Add-Content -Path C:\ProgramData\ssh\administrators_authorized_keys -Value $pubkey -Encoding ascii注意-Encoding ascii这个参数。用默认的 UTF-8 写入某些情况下文件开头会带上 BOM 或者行尾变成 CRLF导致 sshd 解析公钥失败。ASCII 编码最保险。如果是普通用户把路径换成C:\Users\用户名\.ssh\authorized_keys并且要先手动创建.ssh目录New-Item -ItemType Directory -Force -Path $env:USERPROFILE\.sshadministrators_authorized_keys这个文件还有个特殊要求ACL 必须非常严格。sshd 检查到这个文件权限过宽会直接拒绝使用而且日志里的提示往往很含糊。正确权限是只有Administrators组和SYSTEM有完全控制权其他任何主体都不应该有权限。一条命令搞定icacls.exe C:\ProgramData\ssh\administrators_authorized_keys /inheritance:r /grant Administrators:F /grant SYSTEM:F/inheritance:r是断开从父目录继承的权限/grant是重新授予。执行完再icacls看一次输出里除了这两个主体不应该有别的条目。这一步做对90% 的Permission denied (publickey)就消失了。提示文件的行尾和编码是最隐蔽的坑。如果公钥是用记事本从网页或者聊天软件里复制粘贴过来的很可能被自动折行一行的公钥变成两行sshd 会解析失败。稳妥做法是用ssh-copy-id的思路或者干脆用 scp 把.pub文件原样传过去再在服务端用命令追加Get-Content .\win11_home.pub | Add-Content C:\ProgramData\ssh\administrators_authorized_keys -Encoding ascii4.3 关闭密码登录的时机与回滚预案公钥验证通过之后才是关密码登录的时候。顺序不能反反了就是自己把自己锁在外面。验证方法很简单用-i指定私钥连接如果没提示输入密码就直接进去了说明密钥生效ssh -p 22222 -i $env:USERPROFILE\.ssh\win11_home 用户名192.168.1.10注意这里用户名要写对。Windows 上whoami的输出可能是desktop-abc\dev这种带计算机名的格式SSH 登录时通常只写dev就行但如果机器加了域或者有其他情况写全计算机名\用户名也可以。连不上先怀疑用户名写错了。密钥确认可用后编辑服务端的sshd_config把这两行改成PasswordAuthentication no PubkeyAuthentication yes如果原来这两行是注释状态就把#去掉再改值。改完还是老三步sshd.exe -t检查语法、Restart-Service sshd重启、另开窗口测试。注意关闭密码登录之后如果哪天私钥丢了或者损坏就只能去物理机器前面操作了。所以我的习惯是保留一套「应急通道」——要么在服务端保留一个本地账户专门用于控制台登录要么在网络层面留一条只在特定条件下可用的访问路径。总之不要让自己处于「密钥是唯一入口且密钥还在唯一一台机器上」的境地。还有一个细节关闭密码登录后MaxAuthTries的作用会更明显因为它只统计密钥尝试次数。多个密钥的用户比如 ssh-agent 里加载了好几个可能因为尝试次数超限被拒绝。如果遇到这种情况把MaxAuthTries从 6 提高到 10 试试或者在客户端显式指定IdentitiesOnly yes只发对应的那把密钥。4.4 客户端 config 文件把端口、密钥、用户名一次配好每次连接都敲-p 22222 -i ... 用户名IP太累~/.ssh/config就是干这个的。在客户端创建或编辑C:\Users\用户名\.ssh\configHost win11 HostName 192.168.1.10 Port 22222 User dev IdentityFile ~/.ssh/win11_home IdentitiesOnly yes ServerAliveInterval 60 ServerAliveCountMax 3 TCPKeepAlive yes配好之后连接只需要ssh win11三个字。逐条说明一下为什么这么写。IdentitiesOnly yes是配合IdentityFile用的告诉 SSH 只发这一把密钥不要把 ssh-agent 里加载的其他密钥全试一遍。这在服务端设了MaxAuthTries的时候特别重要也避免在不同服务器上泄露「你有哪些密钥」这个信息。ServerAliveInterval 60和ServerAliveCountMax 3是客户端侧的保活每 60 秒发一个探测包连续 3 次没响应就断开。配这个是因为家用路由器、运营商网关经常会把空闲的 TCP 连接静默回收导致 vscode 远程窗口挂那儿半小时没动回来一看连接已经死了。配上保活之后这种情况基本消失。TCPKeepAlive yes是 TCP 层面的保活和服务端的ClientAliveInterval是两回事两边都配上效果更稳。同一份 config 里可以写多个 Host 块笔记本、迷你主机、VPS 各一段用起来非常顺手。vscode 的 Remote-SSH 插件会直接读取这份 config所以配好之后在 vscode 里选主机时也是列表里点一下的事Port和IdentityFile会自动带上不用在插件里重复填。5. 账号隔离与默认 Shell别拿管理员账号裸奔5.1 建一个专用账号把权限收窄用管理员账号做日常 SSH 登录风险在于一旦登录凭据泄露对方直接拿到的是最高权限。合理的做法是建一个专用账号只给它需要的最小权限。net user sshdev 一个足够长的密码 /add这条命令创建的是标准用户不属于 Administrators 组。好处是公钥路径简单——直接放C:\Users\sshdev\.ssh\authorized_keys不用碰administrators_authorized_keys那个权限敏感的文件而且就算账号被攻破影响范围也有限。代价是这个账号做事受限比如装软件、改系统设置、访问某些受保护目录都需要提权。如果你的远程操作主要就是写代码、跑脚本、传文件标准账号完全够用我强烈推荐这个方案。确实需要管理员权限的再单独为这个账号配置 UAC 白名单或者用计划任务做提权而不是直接把账号加进管理员组。添加完账号后记得给.ssh目录和authorized_keys设好权限$sshDir C:\Users\sshdev\.ssh New-Item -ItemType Directory -Force -Path $sshDir icacls $sshDir /inheritance:r /grant sshdev:(OI)(CI)F /grant SYSTEM:(OI)(CI)F icacls $sshDir\authorized_keys /inheritance:r /grant sshdev:F /grant SYSTEM:F/grant里的(OI)(CI)是对象继承和容器继承标记作用是新目录会把这些权限传递给里面的子文件否则新建文件会丢权限导致下次连接失败。5.2 切换默认 Shellcmd、PowerShell、WSL 三选一Windows 上 SSH 登录后默认进的是cmd.exe用起来别扭尤其是习惯 Linux 的人。可以通过注册表改默认 Shell。切到 PowerShellNew-ItemProperty -Path HKLM:\SOFTWARE\OpenSSH -Name DefaultShell -Value C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -PropertyType String -Force如果装了 PowerShell 7路径改成C:\Program Files\PowerShell\7\pwsh.exe体验更好支持更多现代语法和跨平台命令别名。切到 WSL 里的 bashNew-ItemProperty -Path HKLM:\SOFTWARE\OpenSSH -Name DefaultShell -Value C:\Windows\System32\wsl.exe -PropertyType String -Force这个方案我很喜欢因为登录进去就是一个完整的 Linux 环境各种命令行工具、包管理器都在写脚本的体验和远程 Linux 服务器几乎一样同时又能在需要的时候通过/mnt/c/访问 Windows 文件系统。注意改默认 Shell 后ForceCommand之类的参数可能和它冲突如果配了ForceCommand又发现执行结果不对先检查这两个。另外 WSL 方案有个小坑如果 WSL 没装或者默认发行版没设置SSH 登录会失败或者落到一个奇怪的 Shell 里先在本机wsl --status确认一下。5.3 转发功能按需开启不用就关sshd_config里有几个和转发相关的开关默认是注释状态也就是按内置默认值走AllowTcpForwarding yes AllowAgentForwarding yes GatewayPorts no PermitTunnel no X11Forwarding noAllowTcpForwarding是本地和远程端口转发vscode 远程开发依赖它来把远端服务映射到本地浏览器需要保留yes。AllowAgentForwarding是密钥转发方便从这台机器再跳到别的机器但它意味着中间这台机器上能拿到你的 agent安全性上是有代价的。如果不需要跳板功能把它改成no更稳。GatewayPorts保持no这样远程转发只能绑定到回环地址不会意外把内网服务暴露到整个局域网。PermitTunnel是二层隧道基本用不到保持关闭。这一节的原则很简单默认关闭确认要用再打开。每多开一个功能就多一条可能的路径。6. 常见问题与排查技巧实录6.1 高频问题速查表下面这些是我自己踩过或者帮别人看过的典型问题按现象归类。现象最可能的原因处理方法Connection refused服务没起或端口没放行或端口写错Get-Service sshdGet-NetTCPConnection -LocalPort 端口检查防火墙Permission denied (publickey)公钥位置错管理员组或 ACL 过宽或编码问题管理员用户确认公钥在administrators_authorized_keys重置 ACL用 ASCII 编码重写Permission denied (publickey,password)密码登录已关且密钥没生效临时把PasswordAuthentication改回yes排查改了端口但连不上Port前的#没删或防火墙还是旧端口sshd.exe -t检查重看sshd_config改防火墙规则的LocalPort服务重启后端口还是 22配置文件路径不对sshd 用了另一份配置用sshd.exe -T打印实际生效配置确认读取的是哪一份REMOTE HOST IDENTIFICATION HAS CHANGED主机密钥变了或端口变了但对端复用旧记录删除~/.ssh/known_hosts里对应条目连上几秒后自动断开空闲被中间设备回收或保活没配两端都配ServerAliveInterval/ClientAliveIntervalvscode 连不上但命令行能连插件配置里端口或密钥没带用~/.ssh/config的 Host 名让插件自动继承Bad owner or permissions on ...客户端私钥或 config 文件权限过宽用icacls收紧到只有当前用户中文乱码客户端和服务端编码不一致服务端默认 Shell 换成 PowerShell 7或配置chcp 650016.2 日志在哪里看怎么把它变成有效信息Windows 上 sshd 的日志在事件查看器里路径是应用程序和服务日志 → OpenSSH → Operational。命令行也能看Get-WinEvent -LogName OpenSSH/Operational -MaxEvents 50 | Select-Object TimeCreated, Id, Message | Format-Table -Wrap日志默认级别是INFO记录连接建立、认证结果、断开等关键事件。排查认证问题时如果需要更多细节可以在sshd_config里临时把LogLevel调到VERBOSE它会记录每一步认证尝试、尝试了哪个公钥、为什么失败。排查完记得调回去VERBOSE在有人反复尝试连接的场景下会产生大量日志。更彻底的调试手段是让 sshd 在前台跑一个独立实例把调试信息直接打到控制台Stop-Service sshd C:\Windows\System32\OpenSSH\sshd.exe -ddd -p 22223这样它会监听 22223 端口所有调试输出都在当前窗口。因为是前台运行CtrlC就能停不影响正常服务。这种「旁路调试」的思路在配置出错、但又不想反复重启正式服务的时候特别有用。用完Start-Service sshd把正式服务拉回来。6.3 三个我踩过的坑细节比结论重要第一个坑sshd.exe -T才是看生效配置的正确姿势。我一开始排查「配置改了不生效」的问题靠的是反复打开sshd_config肉眼核对效率极低。后来发现sshd.exe -T会打印最终生效的完整配置包括内置默认值和 Match 块展开后的结果直接搜关键参数就行 C:\Windows\System32\OpenSSH\sshd.exe -T | Select-String -Pattern port|password|pubkey|authorizedkeys一次性就能确认Port、PasswordAuthentication、PubkeyAuthentication、AuthorizedKeysFile的真实取值。有次我明明改了AuthorizedKeysFile却没生效用这个命令一打才发现Match 块里的配置在用户属于管理员组时覆盖了全局设置优先级关系一目了然。第二个坑authorized_keys文件里的空行和注释。文件里可以有空行也可以有#开头的注释行但注释必须单独占一行。公钥后面跟的注释就是-C参数写进去的那部分是公钥本身的一部分不能删。我有一次手动整理文件把几行公钥的尾部注释当垃圾清掉了结果那几把密钥全部失效。这个错误恢复起来不算难但发现的过程很折磨因为从现象上看不出任何线索只会一直Permission denied。第三个坑换端口之后忘了更新客户端的known_hosts心理预期。同一个 IP、同一个主机名端口变了SSH 会把它当成一台新主机首次连接会再问一次Are you sure you want to continue connecting。这不是问题。但如果反过来端口没变而主机密钥变了比如重装了 OpenSSH 或者迁移了系统就会报WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!并拒绝连接。这时候的处理办法是删掉known_hosts里的对应行ssh-keygen -R [192.168.1.10]:22222注意带端口的写法是[IP]:端口不带端口就只写 IP。写错了删不掉对应的记录会一直报同样的错。再补充一个关于known_hosts和长期维护的建议。如果你像我一样经常重装系统、换虚拟机、给测试机改配置known_hosts会积累大量失效条目。定期清理是个好习惯~/.ssh/known_hosts里那些已经不存在的主机条目留着也没用反而会在真正的密钥变更告警里制造噪声。我更倾向于把重要主机用HashKnownHosts yes做哈希存储这样即使文件泄露也不会暴露内网主机清单。最后一个实用的小技巧关于连接速度和稳定性。Windows 上的 sshd 默认会尝试对客户端 IP 做反向 DNS 解析如果内网 DNS 配置不当或者响应慢每次连接都要等几秒。在sshd_config里加上UseDNS no能显著加快连接速度同时避免因 DNS 超时导致连接失败。这个参数在 Linux 上也是常见的优化项Windows 上同样有效加了之后我的连接建立时间从两三秒降到几乎瞬间完成。