一、为什么需要 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