1. 为什么要在 Windows 11 上开一个 SSH 服务端手里那台常年开机的 Windows 11 主机硬盘里堆着项目代码、素材、虚拟机镜像和一堆懒得整理的下载文件。以前想从笔记本上取点东西要么开共享文件夹要么拿移动硬盘拷命令行操作更是想都别想。后来我把 Windows 11 自带的 OpenSSH 服务端打开顺手把默认的 22 端口改掉再切到密钥登录现在笔记本、平板、甚至手机都能一条命令连进来sftp 拖文件、VS Code 直接开远程项目体验完全是另一个档次。这篇内容就是把这套流程从头到尾捋一遍Windows 11 配置 SSH 服务器、修改监听端口、配置密钥登录。它不是什么高深的东西前后加起来二十分钟足够但有几个地方第一次做必然要绕一圈——比如管理员账户的公钥为什么放到自己家目录里就是不生效、改完端口为什么本机连得上外面连不上、密钥文件权限到底要不要收紧。这些细节网上零散的答案不少但凑不成一条完整的链路。适合谁看三类人比较对口一是手里有闲置 Windows 机器想当开发跳板或者文件中转站的二是在局域网里想给主机加一个远程命令行入口又不想装一堆第三方远程桌面软件的三是已经会用 Linux 那一套 sshd 配置换到 Windows 上发现路径、权限、服务管理逻辑全变了、想找对应关系的。整个过程用到的工具全是系统自带不需要额外买什么。1.1 内置 OpenSSH 与第三方方案的分界Windows 从 Windows 10 1809 开始就把 OpenSSH 客户端做成了默认安装服务端放在可选功能里等着你去开。到 Windows 11 这代这套东西已经相当成熟微软官方维护的 Win32-OpenSSH 分支一直在更新sshd_config 的语法和 Linux 版本基本一致。那为什么还有人去装第三方方案主要是几个历史包袱早期版本对 ed25519 密钥支持不完整只能用 RSA早几年的版本在非英文用户名下路径处理有问题部分人习惯了图形化配置工具觉得纯文本配置不直观。现在的实际情况是只要你系统更新到比较新的状态ssh -V看一下版本号在 8.x 以上ed25519 是完全没问题的。所以我个人建议优先用系统内置的 OpenSSH 服务端理由是它跟着系统更新走不需要自己维护进程守护和升级服务注册、防火墙规则、日志通道都是现成的。只有在两个例外情况下才考虑手动部署 zip 版一是家庭版或者某些精简镜像里可选功能列表里搜不到 OpenSSH 服务器二是你需要比系统自带更新的版本想单独控制安装目录。手动部署这套东西其实也不复杂思路是从官方发布页拿压缩包解压到一个固定目录然后用自带的install-sshd.ps1脚本注册服务。但这条路后续维护成本会转移到你身上每次升级都得手动替换文件、重启服务所以除非有明确理由否则不必折腾。1.2 三个真正用得上的场景我在实际使用中总结下来Windows 上跑 SSH 服务端最实用的场景有三个你可以对照一下自己的需求。第一个是跨设备取文件和执行命令。一台台式机放在书房当母机笔记本在客厅或者外出通过 SSH 连回去sftp拉文件、跑个脚本、看下某个服务的状态。相比远程桌面SSH 的带宽占用低得离谱而且不需要图形界面环境网络稍微差一点也能用。第二个是给 VS Code 做远程开发后端。这是现在最主流的用法之一。VS Code 装一个 Remote-SSH 插件配上主机地址和端口就能把远程机器当成开发环境代码存在台式机上编辑体验在笔记本上。本地的笔记本不用装任何运行时和依赖换个设备只要重新连一次就行。第三个是自动化脚本的执行入口。比如你在 Windows 上跑定时备份、批量转码、Git 拉取这些任务通过 SSH 触发一次就行不用为了跑一条命令去开远程桌面。配合密钥登录免密脚本里写一行ssh winbox backup.bat就完事了。反过来说有几种情况我不建议用 SSH需要完整图形界面操作的老老实实远程桌面、需要在同一台机器上做高强度图形渲染的、以及只想传一两个文件并且是同一局域网且经常做的共享文件夹更省事。SSH 的强项是命令行和轻量文件传输别指望它替代一切。2. 装好服务端可选功能、服务自启与第一次握手这一节把服务端从没有变成能连上的状态。整个过程分三步装功能、起服务、验证连通。听起来简单但每一步都有个容易忽略的点。2.1 两条安装路径的差别图形界面的路径是打开设置 → 系统 → 可选功能点查看功能在搜索框里输入OpenSSH。你会看到两个条目——OpenSSH 客户端和OpenSSH 服务器。客户端通常已经装好了你要加的是服务器。勾选、下一步、等它装完。命令行路径更快管理员权限打开 PowerShell# 先看看现在是什么状态 Get-WindowsCapability -Online | Where-Object Name -like OpenSSH* # 安装服务端 Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0两条路径的结果是一样的但命令行有个优势当图形界面搜索不到条目时命令往往还能装。这在家庭版或者某些定制镜像上很常见——界面里的功能列表被裁剪过但底层组件包其实还在系统里。如果命令行也提示找不到包那才需要考虑前面说的手动部署。装完之后验证一下版本和文件位置ssh -V Get-ChildItem C:\Windows\System32\OpenSSH\正常情况下会看到sshd.exe、ssh-keygen.exe、sftp-server.exe、scp.exe这一套。要注意sshd.exe服务端和ssh.exe客户端是两个独立程序别搞混。注意安装完成后不要急着改配置。先用默认状态连一次确认基础链路是通的再去动端口和认证方式。这样一旦后面出问题你能确定是配置改错了而不是安装本身就没成功。2.2 sshd_config 到底在哪默认值有哪些这是从 Linux 转过来的人最容易懵的地方Windows 上服务端的主配置文件不在/etc/ssh/而在C:\ProgramData\ssh\sshd_configC:\ProgramData是个隐藏目录资源管理器里默认看不到直接地址栏粘贴路径最快。同目录下还有ssh_host_rsa_key、ssh_host_ed25519_key这些主机密钥文件以及一个administrators_authorized_keys可能还不存在后面会用到。打开 sshd_config值得关注的就那么几行。默认状态下#Port 22—— 注释状态意味着实际监听 22。注意这里有个容易犯的错误如果你直接加一行Port 2222而不去动这行注释那实际只监听 2222因为#开头的就是注释不参与解析。但为了配置清晰我习惯把那行取消注释后直接改值。#PubkeyAuthentication yes—— 注释状态默认就是开启的。#PasswordAuthentication yes—— 注释状态默认开启密码认证。Subsystem sftp sftp-server.exe—— 这行是生效的别去动它动了 sftp 就废了。文件末尾这几行Match Group administrators AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys这几行是整篇内容里最关键的一个点。它的意思是当登录用户属于本机 administrators 组时服务端会忽略C:\Users\用户名\.ssh\authorized_keys转而去读C:\ProgramData\ssh\administrators_authorized_keys这个公共文件。很多人把公钥按 Linux 的习惯往自己家目录一放结果怎么都登不上就是被这段 Match 规则截胡了。顺便说个更高级的排查手段不管配置多复杂都可以用下面这条命令打印出最终生效的配置比一行行看原文靠谱得多 C:\Windows\System32\OpenSSH\sshd.exe -T -f C:\ProgramData\ssh\sshd_config它会把默认值和你的修改合并后输出你能立刻看到port、passwordauthentication、authorizedkeysfile这些项的真实取值是多少。这个命令我在排查改了没生效类问题时用得最多。2.3 本机回环测通不等于外部能连配置没改之前先把服务跑起来Start-Service sshd Set-Service -Name sshd -StartupType Automatic Get-Service sshd第二条命令把启动类型设成自动不然重启后服务不会自己起来你会以为是配置坏了其实是没启动。然后在本机开一个终端测一下ssh 你的用户名localhost第一次连接会提示主机密钥指纹输入 yes 接受。能弹出密码提示并登进去说明服务端本身是活的。这里有个特别容易误判的地方localhost 的回环连接不走 Windows 防火墙的入站规则。也就是说本机能连完全不代表局域网里的另一台机器能连。防火墙那边有没有放行、放行的是哪个端口是另外一回事。我见过不少人卡在这一步折腾半天密钥和配置最后发现是防火墙根本没开。所以本机测通之后一定要从另一台设备再做一次连接测试。这一步不能省。3. 换掉 22 端口配置、防火墙、验证的三件事端口这件事技术上就是把Port一改完事但实际做的时候有三件事要同时对齐配置文件、防火墙规则、以及验证方式。少做一件就会出现看起来改了但连不上的诡异现象。3.1 Port 指令的写法与多端口并存用管理员权限的文本编辑器打开C:\ProgramData\ssh\sshd_config。这里强调一下编辑器用记事本改配置文件没问题但保存时务必确认编码是 UTF-8。用某些老版本 PowerShell 的Set-Content -Encoding utf8会给文件加上 BOM 头sshd 解析时可能报奇怪的语法错误。稳妥做法是直接用记事本或者支持无 BOM UTF-8 的编辑器手动保存。把这一行#Port 22改成或者新增一行Port 2222关于端口号的选择我的建议是避开 1024 以下的低端口虽然 Windows 上不像 Linux 那样严格限制端口绑定权限但这些端口冲突概率高避开 135、139、445、3389、5357 这类系统服务常用端口推荐落在 20000 到 60000 之间随便挑一个自己好记的比如生日数字、常用数字组合。如果你想过渡期同时监听两个端口那就写两行PortPort 22 Port 2222sshd 会同时监听两个。这在灰度切换时很有用——老客户端继续走 22新客户端换到 2222等你把所有客户端都改完了再删掉 22 那行。不过要注意这期间 22 端口的暴露面还在切换完成后记得收尾。配置改完之后如果只是想让新端口生效单纯重启服务就够了。补充一个小技巧改配置前可以先做语法检查避免重启失败导致服务起不来 C:\Windows\System32\OpenSSH\sshd.exe -t返回空或者configuration OK就说明语法没问题。这条命令需要在管理员权限下跑因为 sshd 要读取主机密钥文件。3.2 防火墙规则要重新建一条旧的要收掉这是整个流程里最容易被忽略的一步。安装 OpenSSH 服务端时系统会自动创建一条名叫OpenSSH-Server-In-TCP的入站规则放行 TCP 22 端口。你把端口改成 2222 之后这条规则不会跟着变所以外部依然连不上。先看看现有的规则Get-NetFirewallRule -DisplayName *OpenSSH* | Format-Table Name, DisplayName, Enabled, Direction, Action新增一条针对新端口的规则New-NetFirewallRule -Name OpenSSH-Server-TCP-2222 -DisplayName OpenSSH Server (TCP 2222) -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 2222 -Profile Private, Domain这里的-Profile参数值得说一下。Windows 防火墙把网络分成 Domain域、Private专用、Public公用三类。SSH 服务端通常只需要在专用网络里可用比如你家里的局域网。把规则限制在Private, Domain上比默认的 Any 更克制一些——万一哪天笔记本带着规则连到咖啡店的公共网络也不会直接对外开着端口。旧规则的处理有两条路如果你已经确定不再用 22就把默认规则禁掉或者删掉# 方式一禁用保留下来方便随时恢复 Disable-NetFirewallRule -DisplayName OpenSSH SSH Server (sshd) # 方式二直接删掉 Remove-NetFirewallRule -Name OpenSSH-Server-In-TCP我个人的习惯是先禁用观察几天确认没有遗漏的客户端还在用 22再彻底删掉。直接删除虽然干净但真出问题的时候恢复要多花几分钟重建规则。提示如果规则加得完全正确外部却依然连不上可以临时把第三方安全软件退出一次做对照测试。某些安全套件会接管 Windows 防火墙或者自己拦截非常规端口的入站连接这种情况下 Windows 防火墙里加多少规则都没用。3.3 改完怎么确认它真的听在新端口上改完配置、重启服务、加完防火墙规则接下来要确认端口确实换了。重启服务Restart-Service sshd然后查监听状态两种方式随便挑# 方式一PowerShell 原生 cmdlet Get-NetTCPConnection -State Listen | Where-Object LocalPort -eq 2222 # 方式二老朋友 netstat netstat -ano | findstr :2222正常情况下能看到监听地址是0.0.0.0:2222或者::的 IPv6 版本。如果0.0.0.0后面跟的进程 ID 对应的正是 sshd那服务端这边就对了。还有一个隐藏的坑端口被别的程序占了。如果 2222 被某个软件先行占用sshd 启动时会绑定失败服务状态看起来是正在运行但实际没监听成功。所以查监听结果这一步不能只查一遍就完事得确认 PID 对应的是 sshd 本身Get-Process -Id (Get-NetTCPConnection -LocalPort 2222 -State Listen).OwningProcess最后从另一台设备做一次完整验证注意 SSH 客户端指定端口的参数是大写 Pssh -p 2222 你的用户名主机IPsftp也一样都是大写-Psftp -P 2222 你的用户名主机IP如果客户端那边嫌每次敲-p 2222麻烦下面第 6 节会讲怎么用客户端 config 把它省掉。4. 密钥登录落地生成、投放、收权、关密码四步密码登录能用了接下来做密钥登录。密钥登录的好处很直接不用记密码、不怕暴力猜解、脚本里可以无人值守执行。整个流程分四步其中第三步收权和第四步关密码是最容易出问题的。4.1 选 ed25519 还是 RSA密钥生成在客户端做也就是你用来登录的那台机器不是在服务器上做ssh-keygen -t ed25519 -C win11-desktop-2024参数说明-t ed25519指定算法-C后面跟注释随便写个能帮你识别这把钥匙用途的字符串它会附加在公钥文件末尾。为什么推荐 ed25519 而不是 RSA几个实际理由对比项ed25519RSA 4096公钥长度68 字符左右700 字符签名速度快慢一个量级抗侧信道算法层面有考虑依赖实现兼容性需要较新的客户端/服务端几乎全兼容密钥文件大小几百字节3KB 左右公钥长度这个差异看起来无关紧要但实际用起来是有感觉的短公钥在复制粘贴、往authorized_keys里追加、在配置管理系统里存的时候都清爽很多。只有在对接一些老旧的嵌入式设备或者非常老版本的服务端时才需要退回 RSA那时候用-t rsa -b 4096就行。生成过程中会问保存路径和 passphrase。路径直接回车用默认的C:\Users\你\.ssh\id_ed25519就好。passphrase 建议设一个——它是加密私钥文件的密码即使私钥文件泄露了没有 passphrase 也用不了。当然如果你的目标就是无人值守的脚本登录那就留空但要清楚这意味着私钥文件本身就是凭证得看紧。生成完会得到两个文件id_ed25519—— 私钥绝对不能外传留在客户端。id_ed25519.pub—— 公钥就是要放到服务器上的那个。4.2 普通用户与管理员用户的公钥投放路径完全不同现在回到第 2.2 节说的那段 Match 规则。投放路径取决于你用来登录的那个 Windows 账户是不是管理员普通用户公钥放到C:\Users\用户名\.ssh\authorized_keysadministrators 组成员公钥放到C:\ProgramData\ssh\administrators_authorized_keys。这个区分是 Windows 独有的Linux 上不存在这个问题所以从 Linux 转过来的人几乎百分百会踩一次。普通用户的操作流程在服务器上以该用户身份执行# 确保目录存在 New-Item -ItemType Directory -Force -Path $env:USERPROFILE\.ssh # 把公钥内容追加进去公钥内容从客户端复制过来 $pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... win11-desktop-2024 Add-Content -Path $env:USERPROFILE\.ssh\authorized_keys -Value $pub -Encoding ascii注意这里用的是-Encoding ascii。这里有个实际踩过的坑用 Windows PowerShell 5.1 的Add-Content -Encoding utf8会写入 BOM 头sshd 读这个文件时可能把 BOM 当成公钥内容的一部分导致密钥解析失败表现为密钥明明放对了却认证不通过。用 ascii 编码能规避这个问题因为公钥内容本身就是纯 ASCII 字符。管理员用户的操作流程$pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... win11-desktop-2024 Add-Content -Path C:\ProgramData\ssh\administrators_authorized_keys -Value $pub -Encoding ascii如果文件不存在Add-Content会自动创建。但创建出来的文件权限是继承自父目录的这就引出下一步。4.3 用 icacls 把文件权限收到最小Linux 上 authorized_keys 的权限问题会直接报错比如Permissions 0644 for xxx are too open一眼就知道该干嘛。Windows 上的表现要隐蔽得多sshd 发现文件权限过于宽松时往往不会给你明确的报错而是直接当作没有有效的公钥客户端那边只看到一句Permission denied (publickey)。所以不管是哪个路径的密钥文件都建议主动收一次权限。对管理员用的公共文件icacls.exe C:\ProgramData\ssh\administrators_authorized_keys /inheritance:r /grant Administrators:F /grant SYSTEM:F对普通用户的密钥文件icacls.exe $env:USERPROFILE\.ssh\authorized_keys /inheritance:r /grant $env:USERNAME:F /grant SYSTEM:F这两条命令做的事是/inheritance:r—— 断开从父目录继承来的权限/grant—— 只保留指定的两个主体有权限其余全部清掉。为什么管理员那个文件只给Administrators和SYSTEM因为这个文件是所有管理员共用的如果其中一个管理员能随意改写它等于他能以另一个管理员的身份登录。SYSTEM必须留着是因为 sshd 服务本身是以 SYSTEM 身份运行的它得能读这个文件。验证一下收权结果icacls.exe C:\ProgramData\ssh\administrators_authorized_keys输出里应该只看到 Administrators 和 SYSTEM 两个条目不能再出现Users、Authenticated Users、Everyone这类主体。注意有些教程会说Windows 上不需要管权限这个说法在当前版本上是不准确的。确实有一部分版本对权限检查比较宽松但只要你遇到过密钥内容完全正确却认证失败的情况第一件该做的事就是把权限收紧再试一次。4.4 关掉密码认证的正确顺序密钥能登上之后才考虑关掉密码认证。顺序不能反反了就有可能把自己锁在外面。标准流程应该是这样先用密钥成功登录一次确认无误保持这个 SSH 会话窗口不要关——这是你的安全绳另开一个窗口修改C:\ProgramData\ssh\sshd_config把PasswordAuthentication改成no重启服务Restart-Service sshd用密钥再连一次确认还能进确认没问题了再关掉第 2 步那个备用窗口。修改的内容就是这一行PasswordAuthentication no如果原来是注释状态把#去掉再改值。同时确保PubkeyAuthentication yes是开启的。这里有个特别容易被忽略的坑不要在自己的 SSH 会话里重启 sshd。Windows 上 sshd 会为每个连接派生一个子进程处理会话重启服务的时候这些子进程会被一起带走你当前的会话会直接断开。如果你正好是在这个会话里改的配置而且新配置有问题那就真的进不去了。所以配置改动尽量在本机的物理终端上做或者至少保证有一个不通过 SSH 的入口。真要是不小心把自己锁在外面了怎么办如果机器物理可达本机登录改回来就行。如果机器在另一个房间或者另一个城市那就比较麻烦了——所以第 2 步那个保持会话窗口不关的习惯一定得养成。关掉密码认证之后还有个细节值得处理Windows 账户本身的密码策略。既然 SSH 已经不用密码了本机登录密码仍然要保留但可以考虑把远程登录这条路彻底封掉。做法是在 sshd_config 里加AllowUsers alice bob或者反过来DenyUsers guest testAllowUsers是白名单只允许列表里的用户登录其余一律拒绝。这个比想象中有用——Windows 上可能有一堆账户你根本没意识到存在比如安装某些软件时自动创建的。5. 连不上时的排查链路从客户端 -v 到服务端 DEBUG3配置这种事一次成功的概率其实不高尤其是第一次做的时候。这一节把常见的失败表现和排查顺序整理出来你可以按着这个链路一步步走别东一榔头西一棒槌。5.1 Permission denied (publickey) 的四个排查点客户端报Permission denied (publickey)是最常见的一种。它只说明密钥认证没通过具体原因要靠下面四点逐个排除。第一客户端有没有把正确的密钥发出去。用-v参数看客户端日志ssh -v -p 2222 alice192.168.1.50在输出里找Offering public key这行看看它列出的指纹是不是你要用的那把。如果客户端发的是别的密钥或者压根没发只看到Will attempt key: ...之后就没有Offering了问题在客户端这边。常见原因是本地.ssh目录下堆了好几把密钥客户端挨个试试到被服务端拒绝次数上限。解决办法是在客户端 config 里指定IdentitiesOnly yes和IdentityFile。第二服务端读的文件对不对。用前面说的sshd -T打印生效配置看authorizedkeysfile这一项指向哪里。如果你的用户名在 administrators 组里而它指向的是C:\ProgramData\ssh\administrators_authorized_keys那公钥就必须放那儿。第三文件内容和编码有没有问题。用文本编辑器打开那个文件看看一行一条公钥有没有被换行拆断、有没有 BOM 头乱码、有没有把私钥误当成公钥粘进去。私钥文件的开头是-----BEGIN OPENSSH PRIVATE KEY-----公钥则是ssh-ed25519 AAAA...开头别搞混。第四文件权限是否过宽。回到第 4.3 节用 icacls 收一次权限再试。这四点基本能覆盖九成以上的密钥认证失败。5.2 打开 OpenSSH 操作日志与前台调试模式客户端日志只告诉你失败了服务端日志才告诉你为什么失败。Windows 上 OpenSSH 有独立的事件日志通道在事件查看器 → 应用程序和服务日志 → OpenSSH → Operational里。默认情况下这个日志可能没有启用用管理员权限打开 PowerShell 启用它wevtutil set-log OpenSSH/Operational /enabled:true不过默认的日志级别信息量有限。要做深度排查可以在 sshd_config 里临时加上SyslogFacility LOCAL0 LogLevel DEBUG3改完重启服务重新连一次然后去事件查看器里看。DEBUG3 会打印出密钥协商、认证尝试、授权文件路径这些细节基本上能一眼定位问题。但说实话事件查看器的体验不算好翻日志比较费劲。我个人更常用的是前台调试模式——把服务停掉直接在控制台里跑 sshd日志会实时打在屏幕上Stop-Service sshd # 管理员权限下前台运行-ddd 是最高调试级别 C:\Windows\System32\OpenSSH\sshd.exe -ddd -p 2222这个窗口会一直挂着你从另一个终端连过来连接到什么程度、在哪一步被拒、读的是哪个文件、文件权限判定结果是什么全部实时输出。排查完按 CtrlC 退出再Start-Service sshd恢复正常。这个方法的效率比翻事件日志高太多建议把它当成排查这类问题的首选手段。5.3 改了配置却没生效的常见原因还有一种情况是配置明明改了行为一点没变。常见的几个原因改的是用户级配置文件。Windows 上除了系统级的C:\ProgramData\ssh\sshd_config用户家目录下还可以有~/.ssh/sshd_config。如果你不小心改错了文件系统级的配置会覆盖它你改的那份自然不生效。改之前先确认路径。没重启服务。sshd 只会在启动时读取配置改完必须重启。Restart-Service sshd一下别指望它自动重载。配置项被后面的 Match 块覆盖了。sshd_config 是自上而下解析的Match块里的设置只对匹配到的连接生效并且会覆盖全局设置。如果你的全局设置和 Match 块冲突实际生效的是更具体的那个。服务启动失败实际跑的是旧进程或者压根没跑。改配置时手误打错一个字符sshd 启动就失败但因为系统里可能还有残留进程看起来像是服务在跑。所以每次改完都用Get-Service sshd确认状态配上sshd -T做语法验证。防火墙那边没跟上。改端口的场景下配置文件改了、服务重启了本机测试也通但外部还是连不上——九成是防火墙规则没同步更新。这个在第 3.2 节说过单独拎出来再强调一次是因为它真的太常见了。6. 日常使用打磨默认 Shell、客户端别名与文件互传到这一步服务端已经能用了剩下的都是提升日常体验的事。这些不是必须做的但做完之后使用频率会明显上升因为顺手程度完全不一样。6.1 把登录后的 Shell 换成 PowerShellWindows 上 SSH 登录之后默认进的是cmd.exe。对习惯了 PowerShell 的人来说这体验很割裂——管道语法不一样、命令不一样、连ls都要重新适应。改成 PowerShell 很简单改注册表就行$shell C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe New-ItemProperty -Path HKLM:\SOFTWARE\OpenSSH -Name DefaultShell -Value $shell -PropertyType String -Force如果你装了 PowerShell 7推荐路径换成$shell C:\Program Files\PowerShell\7\pwsh.exe New-ItemProperty -Path HKLM:\SOFTWARE\OpenSSH -Name DefaultShell -Value $shell -PropertyType String -Force改完不需要重启 sshd新登录的会话就会用新 Shell。已经连着的会话不受影响退出重连一次即可。这里有个反面例子值得提一下有人想直接把默认 Shell 设成某个交互式脚本或者带参数的启动命令这通常行不通。DefaultShell只接受一个可执行文件的完整路径不接受参数。如果你需要登录后自动执行某些初始化操作正确做法是在 PowerShell 的$PROFILE里写而不是在注册表里堆参数。还有一点如果这个账户同时用于本地登录和远程登录把远程 Shell 改成 PowerShell 不影响本地登录本地还是走你的默认设置。两者是独立的。6.2 客户端 config 写别名衔接 VS Code Remote-SSH每次都敲ssh -p 2222 alice192.168.1.50太累客户端 config 可以把这些都固化下来。在客户端的C:\Users\你\.ssh\config里加Host winbox HostName 192.168.1.50 Port 2222 User alice IdentityFile ~/.ssh/id_ed25519 IdentitiesOnly yes ServerAliveInterval 60 ServerAliveCountMax 3逐项说明一下因为好几个参数是有实际作用的Host winbox—— 起个别名之后ssh winbox就等价于那一长串。IdentitiesOnly yes—— 强制只使用IdentityFile指定的那把密钥。不加这个的话客户端会把本地所有密钥挨个试一遍服务端那边会记录大量失败尝试有些加固配置会因此直接封 IP。ServerAliveInterval 60—— 每 60 秒发一个心跳包。ServerAliveCountMax 3—— 连续 3 次心跳没响应才断开。后两个参数是解决发呆一会儿连接就断了的经典组合。因为长时间空闲的连接会被中间的网络设备清掉会话加了心跳之后连接能一直挂着。注意这两项是客户端配置写在服务端的 sshd_config 里也有对应的ClientAliveInterval但管的是不同方向的事别搞混。配好之后VS Code 的 Remote-SSH 也能直接吃这个配置。装了插件之后远程资源管理器里会列出你 config 里的所有 Host点一下就连上了不用再手动填地址端口。关于 VS Code Remote-SSH 有个实际问题要提醒第一次连接时它会在服务端下载并安装vscode-server这东西会占用几百 MB 到 1GB 左右的磁盘空间装在用户目录下。如果你的系统盘比较紧张建议先把用户目录迁到数据盘或者定期清理~/.vscode-server里旧版本的目录。它不会自动清理历史版本用久了会越堆越多。另外Remote-SSH 在 Windows 服务端上要求有 PowerShell 可用这个条件默认就满足。但如果前面把默认 Shell 改成了某些非标准的东西可能会影响插件的正常工作改之前建议先确认一下自己是不是重度依赖 Remote-SSH。6.3 sftp 与磁盘映射的取舍文件传输这块Windows 上主要有两条路。第一条是 sftp。命令行操作简单可靠sftp -P 2222 alice192.168.1.50进去之后就是熟悉的put、get、ls、cdsftp lcd D:\Downloads sftp cd /C:/Users/alice/Desktop sftp put report.zip sftp get data.csv注意路径写法Windows 上的盘符在 sftp 里表现为/C:/Users/...这种形式。这个反直觉的写法第一次见会愣一下。图形化的 sftp 客户端也可以用填主机、端口、用户名密钥文件选上就行。适合不想记命令的场景。第二条是 SMB 共享映射。把服务器的某个目录共享出来客户端映射成网络驱动器在资源管理器里像本地盘一样操作。适合大批量文件浏览和拖拽。两者的取舍很清楚sftp 传输单个文件、脚本自动化、跨平台的时候更合适SMB 适合频繁的图形化文件浏览。但 SMB 在网络条件差的情况下体验会明显下降而且共享权限和 NTFS 权限是两套东西配置起来比 SSH 密钥麻烦。所以我的习惯是——日常小文件用 sftp需要大幅浏览的时候才临时开共享。7. 踩过的坑和长期维护上的一些取舍最后聊聊那些文档里不太会写、但实际用起来一定会遇到的东西。7.1 中文用户名、WSL 冲突、端口占用中文用户名。这是我最想强调的一条。如果你的 Windows 账户名是中文OpenSSH 在路径处理上出问题的概率会明显升高表现五花八门——有的版本是认证直接失败有的是 sftp 进不去某个目录有的是authorized_keys读不到。这个问题排查起来很折腾因为日志里给的信息不一定能指向编码问题。我的建议是专门建一个英文用户名的账户只用于 SSH 登录。这个账户不需要是管理员反而更合适——普通用户的公钥路径更简单不涉及administrators_authorized_keys那套逻辑。日常操作需要提权的时候再在这个会话里用提权命令就行。WSL 冲突。如果你在 Windows 上装过 WSL并且在里面装过 openssh-server那就存在两套 sshdWindows 原生的一套WSL 发行版里的一套。两者是独立的系统配置文件、密钥、服务管理命令全都不一样。更麻烦的是端口冲突——WSL 里的 sshd 如果也监听 22 或者同一个端口Windows 原生这边的绑定就会失败。排查的时候先确认你现在改的是哪一套别在 WSL 里改了半天配置然后去 Windows 服务里重启服务。端口占用。前面提过一次这里再补一个实操细节。Windows 上有一个概念叫保留端口范围excluded port range某些端口会被系统预留普通进程绑定不了。用这条命令可以查netsh int ipv4 show excludedportrange protocoltcp如果挑的端口正好落在某个保留区间里服务会启动失败但报错信息可能很含糊。换成区间外的端口就好了。IP 地址变动。局域网里如果主机用的是 DHCP 分配的地址路由器重启或者租约到期后地址可能变化客户端 config 里写死的HostName就失效了。解决办法是在路由器上给这台机器做 DHCP 保留或者在 Windows 里直接设一个局域网内的静态地址。这一步和 SSH 本身无关但属于配好之后能不能一直用的关键前提。7.2 长期运行下值得定期做的事服务跑起来之后基本不需要管但有几件事隔一段时间看一眼会更省心。定期清理known_hosts里的过期条目。如果服务端重装过系统或者重新生成了主机密钥客户端会报主机密钥不匹配的警告然后拒绝连接。这是正常的保护机制不是 bug。处理方式是找到报错里提示的那一行号在客户端的known_hosts文件里删掉对应条目然后重新连接接受新指纹ssh-keygen -R [192.168.1.50]:2222注意主机加端口的时候要用[host]:port这种带方括号的写法不然-R找不到对应的条目。定期看一眼认证日志。前面启用了 OpenSSH/Operational 日志的话偶尔翻一眼有没有大量失败尝试。虽然密钥登录本身已经很难被猜中但日志能告诉你端口是不是被扫到了这有助于判断当前的暴露面。更新系统后重连一次。Windows 的大版本更新偶尔会把可选功能重置或者更新 OpenSSH 版本导致配置格式有细微变化。养成习惯大更新之后连一次确认服务还在、配置还生效。用sshd -T快速过一遍。备份配置和密钥。C:\ProgramData\ssh\整个目录值得定期备份里面装着主机密钥和配置文件。主机密钥丢了意味着所有客户端都要重新接受指纹虽然不影响使用但会烦人。放进一个加密的备份位置就行注意这个目录里的私钥文件ssh_host_*_key本身不能泄露。关于安全加固的取舍。网上有很多SSH 加固清单动辄几十条。我的实际建议是分层次必做的是密钥登录 关密码认证 权限收权这三件事覆盖了绝大部分风险可选的是AllowUsers白名单、改端口、限制防火墙 Profile这些是纵深防御做了更好但优先级低于前三件至于失败次数锁定、双因素认证这些在局域网自用的场景下投入产出比不高除非这台机器是长期对外暴露的。最后分享一个我自己的小习惯给每一台机器的 SSH 密钥都用不同的注释和文件名比如id_ed25519_winbox、id_ed25519_homepc。这样一旦某一把密钥需要作废你能立刻知道该删哪台机器上的哪个文件而不用去猜这把id_ed25519到底是配给谁的。配合客户端 config 里的IdentityFile指定管理起来非常清爽。这个习惯在机器数量超过三台之后价值会陡然上升——我在只有两台机器的时候完全不当回事等到了第五六台的时候回头整理密钥花的时间比当初多付出十秒钟要多得多。