一、为什么需要 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 编程工作流,这种方案简单、易调试,也便于逐步扩展。