一、为什么需要 Linux 连接 Windows？
在日常开发中，我们通常使用 Windows 电脑，通过 SSH 连接 Linux 服务器，在远程机器上编辑代码、编译程序、执行测试。
但是，随着 AI 编程 Agent 的普及，这种开发模式会遇到一个问题：代码运行在 Linux 上，但部分开发工具只能在 Windows 上运行。
例如：
某些 Windows 专用的 CLI 工具，只提供
.exe程序。某些编译器、测试工具或内部工具依赖 Windows 运行环境。
AI Agent 在 Linux 服务器上分析和修改代码，但需要调用 Windows 程序完成测试或其他操作。
如果 Windows 只能作为 SSH 客户端，Linux 上的 Agent 就很难直接控制 Windows 上的命令行工具。
一种简单的解决方案是：在 Windows 上开启 SSH 服务端，让 Linux 主动 SSH 连接 Windows。
这样，两台机器之间就可以建立反向控制通道：
开发人员 | v Windows 11 电脑 ├── Cursor / VS Code ├── Windows 专用 CLI ├── 编译器 / 测试工具 └── OpenSSH Server ^ | SSH / TCP 22 | Linux 开发服务器 ├── AI Coding Agent ├── 源代码与任务文档 ├── Linux 编译和调试工具 └── 通过 SSH 调用 Windows 工具这种方式不需要把整个开发环境迁移到 Windows，也不需要把 Windows 工具强行安装到 Linux。Linux 继续负责主要开发任务，Windows 则作为一个可远程调用的工具执行节点。
本文以 Windows 11 为例，Windows 10 的较新版本也可以采用类似方法。
二、确认网络连通性
假设开发环境如下：
| 设备 | IP 地址 | 用途 |
|---|---|---|
| Linux 服务器 | 10.100.120.123 | 运行 Agent 和开发环境 |
| Windows 11 | 10.100.121.10 | 运行 Windows 专用工具 |
| SSH 端口 | 22 | Linux 连接 Windows |
这里的 IP 只是示例，实际使用时应替换为自己的地址。
首先确认两台机器处于可以互相通信的网络中。跨 VLAN、VPN 或公司网络隔离环境下，即使两台机器都能访问互联网，也不一定能够直接互连。
在 Windows PowerShell 中查看 IP 地址：
ipconfig在 Linux 上测试 Windows 的 SSH 端口：
nc -vz -w 5 10.100.121.10 22如果 SSH 服务还没有安装，这里出现连接失败是正常的。完成后面的配置，再执行一次测试。
三、安装 Windows OpenSSH Server
Windows 11 自带 OpenSSH 的可选功能，不需要额外安装第三方 SSH 服务端。可以通过 Windows 设置或 PowerShell 完成安装。官方参考：Microsoft Learn：安装并配置 OpenSSH Server。
方法一：通过图形界面安装
打开设置 → 系统 → 可选功能。
找到“添加可选功能”或“查看功能”。
搜索
OpenSSH Server。选中后安装。
注意不要只安装OpenSSH Client。Client 用于 Windows 主动连接其他 SSH 服务器；Server 才是让 Linux 连接 Windows 所需要的组件。
方法二：通过 PowerShell 安装
以管理员身份打开 PowerShell，先检查安装状态：
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'如果服务端显示NotPresent，执行：
Add-WindowsCapability -Online ` -Name OpenSSH.Server~~~~0.0.1.0安装完成后，检查状态：
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*'正常情况下，状态应为Installed。
如果安装失败，可以先检查 Windows Update、公司 WSUS 或组策略是否限制了可选功能的下载。
四、启动 SSH 服务并设置开机自启
仍然在管理员 PowerShell 中执行：
# 启动 SSH 服务 Start-Service sshd # 设置开机自动启动 Set-Service -Name sshd -StartupType Automatic # 检查服务状态 Get-Service sshd正常情况下，Status应为Running，StartType应为Automatic。
也可以使用 Windows 服务管理界面：
按
Win + R。输入
services.msc。找到
OpenSSH SSH Server。将启动类型设置为“自动”，然后启动服务。
五、配置 Windows 防火墙
安装 OpenSSH Server 时，Windows 通常会自动创建名为OpenSSH-Server-In-TCP的入站防火墙规则，允许 TCP 22 端口的连接。
检查规则：
Get-NetFirewallRule ` -Name OpenSSH-Server-In-TCP | Format-List Name, Enabled, Profile, Direction, Action如果规则不存在，可以在管理员 PowerShell 中创建：
New-NetFirewallRule ` -Name 'OpenSSH-Server-In-TCP' ` -DisplayName 'OpenSSH Server (sshd)' ` -Enabled True ` -Direction Inbound ` -Protocol TCP ` -Action Allow ` -LocalPort 22如果规则已经存在但被禁用，可以执行：
Enable-NetFirewallRule ` -Name OpenSSH-Server-In-TCP一个容易忽略的问题：网络配置文件
Windows 网络通常会被分类为：
DomainAuthenticated：域网络。Private：专用网络。Public：公用网络。
可以查看当前分类：
Get-NetConnectionProfile | Format-Table InterfaceAlias, NetworkCategory, IPv4Connectivity如果当前网络是Public，而防火墙规则只允许Private，即使 SSH 服务已经启动，Linux 仍然可能连接失败。
建议根据实际网络环境，检查防火墙规则的Profile是否包含当前网络类型。
如果是可信的家庭或受控开发网络，可以在确认网络安全后调整规则范围；如果是公司网络，则应优先遵循公司的安全策略，不要为了连接方便而无条件放开所有入站访问。
六、从 Linux 测试连接 Windows
完成服务和防火墙配置后，在 Linux 上测试：
nc -vz -w 5 10.100.121.10 22如果看到类似结果：
Connection to 10.100.121.10 22 port [tcp/ssh] succeeded!说明 TCP 连接已经建立。
接下来通过 SSH 登录。假设 Windows 登录用户名为devuser：
ssh devuser@10.100.121.10首次连接时，SSH 会提示确认 Windows 主机的指纹。确认它来自可信的目标机器后，再接受指纹。
随后输入 Windows 用户的登录凭据。如果认证成功，就会进入 Windows 远程命令行环境。
需要注意：这里使用的是 Windows 账户，而不是 Linux 账户。实际用户名可以在 Windows 上通过以下命令确认：
whoami如果返回：
desktop-abc123\devuser连接时通常可以使用：
ssh devuser@10.100.121.10如果用户名或域名包含特殊情况，可以根据实际账户格式调整。
七、验证能否执行 Windows 命令
成功登录后，可以在 SSH 会话中执行 Windows 命令。
例如：
hostname whoami where.exe python也可以直接在 Linux 上执行远程命令，不必进入交互式会话：
ssh devuser@10.100.121.10 "hostname"执行 Windows 专用工具时，建议先确认 SSH 登录后的默认 Shell。Windows OpenSSH 通常使用配置的默认 Shell，默认情况下为cmd.exe，也可以配置为 PowerShell。
如果希望统一使用 PowerShell，可以在管理员 PowerShell 中执行：
New-ItemProperty ` -Path "HKLM:\SOFTWARE\OpenSSH" ` -Name DefaultShell ` -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" ` -PropertyType String ` -Force然后重启 SSH 服务：
Restart-Service sshd重新连接后即可测试 PowerShell 命令。
注意：PowerShell 和cmd.exe的命令语法不同。例如，Linux 端传入的引号、管道符和变量展开可能受到本地 Shell、SSH 参数解析以及远程 Shell 三层处理的影响。复杂命令最好封装为.ps1脚本，再通过 SSH 调用。
八、配置 SSH 公钥认证
如果 Agent 需要频繁调用 Windows 工具，每次输入密码显然不合适。可以配置 SSH 公钥认证。
在 Linux 上生成一对密钥：
ssh-keygen -t ed25519 \ -f ~/.ssh/id_ed25519_windows如果这是专门用于 Agent 的密钥，可以为它设置独立的用途和权限；是否设置密钥口令，应结合自动化需求和密钥保护方案决定。
生成后会得到：
~/.ssh/id_ed25519_windows ~/.ssh/id_ed25519_windows.pub将公钥内容显示出来：
cat ~/.ssh/id_ed25519_windows.pub将输出的完整公钥添加到 Windows 账户对应的authorized_keys文件中。
对于普通的 Windows 用户账户，文件通常位于：
C:\Users\devuser\.ssh\authorized_keys可以在 Windows PowerShell 中创建目录：
New-Item -ItemType Directory ` -Force "$HOME\.ssh"然后将 Linux 生成的公钥写入authorized_keys，注意不要覆盖已有的其他公钥。
在 Linux 上测试：
ssh -i ~/.ssh/id_ed25519_windows ` devuser@10.100.121.10如果登录成功，可以在 Linux 的~/.ssh/config中配置别名：
Host win-dev HostName 10.100.121.10 User devuser IdentityFile ~/.ssh/id_ed25519_windows IdentitiesOnly yes以后就可以直接执行：
ssh win-dev或者：
ssh win-dev "hostname"公钥认证的一个 Windows 特殊情况
如果登录的是 Windows 管理员组账户，OpenSSH 默认可能通过%ProgramData%\ssh\administrators_authorized_keys读取公钥，而不是使用用户目录下的authorized_keys。
因此，普通账户和管理员账户的公钥配置方式可能不同。若公钥已经正确写入却仍然要求输入密码，需要检查实际使用的账户、sshd_config中的Match Group administrators配置，以及对应文件的 ACL 权限。
不要为了省事而给Everyone或其他无关账户授予密钥文件的写权限。
九、让 Linux 上的 Agent 调用 Windows 工具
完成前面的配置后，Linux 上的 Agent 就可以通过 SSH 调用 Windows 命令行工具。
例如，Windows 上安装了一个只能在 Windows 运行的测试程序：
C:\Tools\my-test-tool.exe可以先在 Windows 本地确认程序可以正常运行，再通过 Linux 调用：
ssh win-dev \ '"C:\Tools\my-test-tool.exe" --version'实际参数引号需要根据工具及远程 Shell 调整。对于复杂参数、文件路径或多行脚本，更稳妥的方式是在 Windows 上准备一个专用.ps1脚本，再通过 SSH 触发。
例如，Windows 上创建：
# C:\Tools\run-test.ps1 & "C:\Tools\my-test-tool.exe" --version if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }Linux 端可以通过 SSH 调用该脚本。具体的命令转义需要结合默认 Shell 测试；在自动化环境中，建议把脚本路径和输入参数固定下来，并明确约定退出码、日志位置和输出格式。
这种模式可以做什么？
让 Linux 上的 Agent 触发 Windows 编译器或测试工具。
调用仅支持 Windows 的内部 CLI。
在 Windows 上执行测试，再把标准输出、错误输出和退出码返回 Linux。
将代码分析、文件处理和 Linux 编译留在服务器端，把 Windows 专属任务交给本地电脑执行。
但 SSH 只是远程执行通道，并不会自动解决文件同步问题。如果 Windows 工具需要读取 Linux 上的源代码，可以通过 SMB、SFTP、共享目录或显式传输文件来完成。最好明确源代码和生成文件各自存放在哪里，避免两边执行的是不同版本的文件。
十、安全建议
把个人开发电脑开放为 SSH 服务端后，Windows 不再只是发起连接的一方，也会接受来自网络的远程登录请求，因此应注意：
限制访问来源。尽可能只允许开发服务器的 IP 或可信网段访问 SSH 端口。
使用专用账户。为自动化调用创建权限受限的 Windows 用户，避免默认使用管理员账户。
优先使用公钥认证。妥善保护私钥，避免将私钥放入代码仓库或共享目录。
避免直接暴露到公网。不要为了远程调用而无条件开放路由器端口转发；远程访问应使用经过批准的 VPN 或其他安全通道。
注意 Agent 的命令执行权限。可以远程执行命令，也意味着 Agent 可能误删文件、执行不可信程序或泄露凭据。对高风险操作应增加确认和权限隔离。
检查日志。Windows OpenSSH 的运行日志有助于排查登录失败和认证问题。
十一、常见问题排查
| 现象 | 优先检查 |
|---|---|
nc连接超时 | Windows 防火墙、网络分类、路由和 VLAN 隔离 |
Connection refused | sshd是否启动、监听地址和端口是否正确 |
| 可以连上但密码认证失败 | Windows 用户名、账户密码、认证策略 |
| 公钥配置后仍然提示密码 | authorized_keys路径、管理员账户特殊规则、ACL 和 SSH 日志 |
| 可以登录但找不到工具 | 默认 Shell、PATH、工具安装目录、运行账户权限 |
| Windows 工具无法读取文件 | 路径格式、目录权限、文件是否已同步 |
| 远程执行的退出码不正确 | PowerShell 的$LASTEXITCODE、脚本的exit和远程命令包装方式 |
如果认证问题比较难定位，可以检查 Windows 事件查看器中的 OpenSSH 日志；具体日志位置会随系统配置有所不同。
十二、总结
传统开发方式通常是 Windows 连接 Linux；而当 AI Agent 运行在 Linux、部分工具只能运行在 Windows 时，让 Linux 反向连接 Windows 是一种实用的补充方案。
整个配置的核心只有四步：
安装 Windows OpenSSH Server。
启动
sshd并设置开机自启。检查防火墙与网络连通性。
配置 SSH 登录，最好进一步使用公钥认证。
完成后，Windows 就可以作为 Linux 开发环境的远程工具执行节点。对于需要同时利用 Linux 开发环境和 Windows 专用工具的 AI 编程工作流，这种方案简单、易调试，也便于逐步扩展。
参考文档：Microsoft Learn — Get started with OpenSSH Server for Windowshttps://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse
