WinRM 远程连接 Windows 执行 cmd：批量运维配置、认证与排错实战

远程运维这件事，我踩过的坑比写过的脚本还多。今天要聊的是用 winrm 远程连接 Windows 并执行 cmd 这套组合拳——它不算新鲜技术，但在我经手的批量运维场景里，出场率一直排在前三。原因很简单：Windows 服务器默认就带 WinRM，不用装任何第三方客户端，一条命令就能在二十台机器上同时跑 dir、ipconfig、netstat 这类 cmd 指令，还能把输出回收到本地做二次处理。如果你手头管着几台到几百台 Windows，或者正在用 Python、Ansible 这类工具做自动化，却还在为"怎么把命令塞进别人的机器里"发愁，那这篇文章应该能帮你省下不少翻文档的时间。下面我按自己实际落地的顺序，从为什么选它、怎么配、怎么连、怎么排错，一路讲到底。

1. 为什么值得花时间搞明白 WinRM 这条路

1.1 从一次二十台机器的批量执行需求说起

事情的起点很朴素：一批 Windows 业务机需要定期收集磁盘占用、服务状态和最近的安全日志，人工登录显然不现实，RDP 一台台点开也扛不住。最初我想的是在每台机器上装一个自制的小 Agent，定时上报。方案跑了两周就放弃了，原因不在代码，而在分发和升级——二十台机器的 Agent 版本一旦不一致，排查问题的时间比解决问题还长。

后来换成 WinRM，思路一下子清爽了：不装任何常驻进程，不改变目标机器的软件结构，所有操作都是"连接-执行-断开"。目标机器上本来就有的 WinRM 服务负责接收指令，cmd 或者 PowerShell 负责干活，我在控制端收结果就行。整个过程对业务机几乎是零侵入，唯一需要动的就是开一个监听端口和一条防火墙规则。这种"用系统自带能力解决系统自身问题"的思路，在 Windows 生态里往往比引入新组件更靠谱。

再往后做横向扩展时，这套方案的优势更明显：控制端可以是一台 Linux 跳板机，也可以是一台 Windows 管理机，甚至可以直接嵌在 Python 脚本里，跟其他系统的运维逻辑共用一个调度器。目标端不需要关心控制端是什么系统，只要 Web 服务管理协议（WS-Management）能通就行。

1.2 WinRM 与常见远程方案的横向对比

选型这件事，最怕的就是"听别人说好用"就上手。我整理了一张表，把几种常见做法放在一起对比，你可以对照自己的场景挑：

这张表里最关键的一列是"目标端是否需要装东西"。运维方案的长期成本，几乎都花在分发和版本管理上，而不是第一次跑通的那一刻。WinRM 在这点上赢得很干脆:它没有分发成本，因为你不需要分发任何东西。

另一个容易被忽略的点是协议本身的定位。WinRM 是 WS-Management 协议在 Windows 上的实现，走的是标准的 SOAP over HTTP/HTTPS，跟 PowerShell Remoting 是同一套底层。这意味着你在 WinRM 上做的连接配置、认证配置，很多能直接复用到 PowerShell 远程会话上，学一次能用很久。

1.3 哪些场景适合上 WinRM，哪些别硬上

按我的经验，下面几类活儿上 WinRM 最合适：定期巡检（收集磁盘、内存、服务、事件日志）、配置下发（改注册表、调服务启动类型、铺配置文件）、批量执行一次性命令（重启服务、清理临时目录、触发某个批处理）、CI/CD 里对 Windows 构建机的调度。

反过来，下面这些场景我不建议硬上：需要长时间保持交互式会话的（比如要连续输入多条命令并根据中间输出判断），WinRM 的会话模型不太适合；需要图形界面的，直接上远程桌面；需要秒级高频通信的，自建 Agent 或者消息队列会更合适，因为 WinRM 每次建会话都有握手开销。

还有一个现实边界要提前说清楚：WinRM 的能力上限取决于你用的账号权限。用普通用户连过去，能干的事和他在本机登录时能干的事一样多，不会凭空多出权限。想执行需要提权的操作，得先把账号和令牌这件事理清楚，后面第 3 章会专门讲。

2. 服务端准备：把 WinRM 从"睡着"叫醒

2.1 三条命令搞定最简可用配置

Windows 上 WinRM 服务默认是存在的，但监听器和防火墙规则通常没配好，所以直接连大概率是不通的。最省事的做法是在目标机上用管理员权限打开 PowerShell，跑这一条：

Enable-PSRemoting -Force

它一次性做完了四件事：把 WinRM 服务启动类型设为自动、启动服务、创建 HTTP 5985 的监听器、放通对应的防火墙规则。如果你更习惯老式命令行，等价的还有：

winrm quickconfig -q

实测下来两者效果差不多，但Enable-PSRemoting在域环境下会额外处理一些组策略带来的冲突，我一般优先用它。跑完之后验证一下监听器是否真的起来了：

winrm enumerate winrm/config/listener

输出里应该能看到一个Transport = HTTP、Port = 5985、ListeningOn包含本机所有 IP 的条目。如果这一条看不到监听器，后面所有连接都免谈，先把这步解决掉再往下走。

2.2 监听器、端口和防火墙到底被改了什么

很多人配完就完事了，出了问题完全不知道从哪查。我把Enable-PSRemoting背后动的东西列一下，你心里有个数：

• 服务层面：WinRM 服务（服务名 WinRM）启动类型变为自动，服务立即启动。这个服务依赖 HTTP 服务（HTTP.sys），如果 HTTP.sys 有问题，WinRM 起不来。
• 监听器层面：默认创建一个 HTTP 监听器，绑定 5985 端口，监听所有网卡。HTTPS 监听器（5986）不会自动创建，需要手动配证书。
• 防火墙层面：创建名为"Windows 远程管理 (HTTP-In)"的入站规则，放通 TCP 5985。
• 配置层面：把服务的AllowUnencrypted保持为 false，Auth/Basic保持为 false，也就是默认只允许加密通道和较强认证。

端口这块记两个数就够了：5985 是 HTTP，5986 是 HTTPS。前者在 NTLM 认证下依然有消息级加密，后者是传输层加密，两者不是一回事，第 3 章细讲。

注意：如果目标机的网络位置被识别成"公用网络"，winrm quickconfig会直接拒绝执行并提示防火墙例外无法生效。这时候先跑Set-NetConnectionProfile -NetworkCategory Private把网卡位置改过来，再重新执行。

2.3 工作组环境绕不开的 TrustedHosts

域环境里，机器之间有 Kerberos 信任，WinRM 认证走得很顺。工作组环境就没这个待遇了，控制端第一次连过去大概率会看到"服务器名称无法解析"或者"Kerberos 认证失败"之类的提示。

解决办法是在控制端（注意，是发起连接的这一侧，不是被连的那一侧）配置 TrustedHosts：

# 追加单个主机 Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.1.101" -Force # 追加多个，逗号分隔 Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.1.101,192.168.1.102" -Force # 查看当前值 Get-Item WSMan:\localhost\Client\TrustedHosts

这里有个新手最容易搞反的地方：TrustedHosts 配在客户端，不是服务端。它的语义是"我信任这些目标主机，愿意把凭据发过去"，所以当然是发起方说了算。我见过不少人跑到目标机上改了半天，一点用没有。

用*可以把所有主机都加进信任列表，图省事的时候确实方便，但如果这台机器还要连别的不相干的环境，我建议还是按 IP 或者主机名精确添加。信任列表一放宽，凭据被发给谁就不完全由你控制了。

3. 认证方式怎么选：NTLM、Basic、Kerberos 的取舍

3.1 四种认证方式的能力边界

WinRM 支持好几种认证，第一次接触很容易挑花眼。我把常用的四种整理成表，重点看"是否加密"和"适用环境"两列：

NTLM 是工作组环境下的性价比之王。它不需要额外配证书，凭据不落明文，还自带消息级加密，日常批量运维用它基本够了。判断标准很简单：机器在域里，优先 Kerberos；不在域里，用 NTLM；两个都不行（比如某些老系统），再考虑 Basic 加 HTTPS。

Basic 认证要特别小心。它把用户名密码 Base64 编码后放在 HTTP 头里发出去，Base64 只是编码不是加密，随便抓个包就能还原。如果你在测试环境图省事开了Basic="true"和AllowUnencrypted="true"，用完一定要关掉：

# 只在测试环境临时启用 winrm set winrm/config/service/auth '@{Basic="true"}' winrm set winrm/config/service '@{AllowUnencrypted="true"}' # 用完立刻恢复 winrm set winrm/config/service/auth '@{Basic="false"}' winrm set winrm/config/service '@{AllowUnencrypted="false"}'

注意：AllowUnencrypted="true"打开的是一条明文通道，任何在链路上能看到流量的人都能读到你的操作内容和凭据。这个开关只应该出现在隔离的测试网络里，生产环境的机器上请保持它为 false。

3.2 HTTPS 监听器与证书那点事

如果业务要求传输层也加密，就得配 5986 的 HTTPS 监听器。核心是给机器准备一张证书，然后让 WinRM 用它建监听器：

# 查看本机已有的证书指纹 Get-ChildItem Cert:\LocalMachine\My # 创建 HTTPS 监听器 winrm create winrm/config/Listener?Address=*+Transport=HTTPS ` '@{Hostname="winrm-demo.local"; CertificateThumbprint="你的证书指纹"}'

证书这块有个坑：Hostname必须和证书里的 CN 或者 SAN 对得上，否则客户端校验会失败。另外防火墙要额外放通 5986：

New-NetFirewallRule -DisplayName "WinRM HTTPS" -Protocol TCP ` -LocalPort 5986 -Action Allow -Profile Any

自签名证书在测试环境够用，但生产环境建议用内部 CA 签发的证书，省得每台客户端都要手动信任。我自己在测试环境折腾自签名证书的时候，最常忘的就是把证书导入到"受信任的根证书颁发机构"，导致每次连接都要加跳过校验的参数，时间长了反而更容易出问题。

3.3 账号权限与远程令牌过滤这道坎

假设你用的是目标机上的本地管理员账号，在域环境下没问题，但在工作组环境下，连接过去之后你可能会发现：明明是本机管理员，很多需要提权的操作却报拒绝访问。

这不是 WinRM 的锅，是 Windows 的远程 UAC 限制在起作用。默认情况下，本地账号通过网络登录时，系统会把它的令牌降权，只保留标准用户权限，这叫"远程令牌过滤"。想让它拿到完整的管理员令牌，需要改一个注册表值：

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" ` -Name "LocalAccountTokenFilterPolicy" -Value 1 -PropertyType DWord -Force

改完不需要重启，但已经建立的会话要重新连。这个改动等于关掉了本地账号远程登录的降权保护，所以在生产环境改之前，先把账号策略和审计想清楚：能不能改用域账号？能不能只给特定账号开？如果必须开，至少保证这台机器的登录来源是受控的。

我个人的做法是：域环境一律用域账号，不碰这个注册表；工作组环境如果只是做巡检这类只读操作，也不开；只有当确实需要远程做服务管理、注册表修改这类动作时，才针对性地打开，并且记录在配置管理清单里。

4. 客户端实操：从三个入口把命令送进去

4.1 Windows 端自带客户端实操

如果控制端也是 Windows，最省事的就是用系统自带的winrs，不需要装任何东西。基本用法是把目标地址、账号、密码和要执行的命令一次给全：

winrs -r:192.168.1.101 -u:Administrator -p:P@ssw0rd cmd /c "ipconfig /all"

几个细节值得说一下。-r:后面跟目标地址，可以是 IP 也可以是主机名；-u:和-p:分别是账号和密码。如果命令行里带空格或者特殊字符的参数，一定要用引号包起来，否则会被当成 winrs 自己的参数解析，报出的错还特别误导人。

还有一种我不太推荐但确实有人用的写法，是交互式会话：

winrs -r:192.168.1.101 -u:Administrator -p:P@ssw0rd cmd

进去之后就像在本地开了一个 cmd 窗口，但每一行输入都要走一次网络往返，延迟高的环境里体验很差，而且一旦网络抖动，会话直接断掉，前面的输出也拿不回来。批量场景里我只用它做临时验证。

如果控制端是 Windows 且想用 PowerShell 那一套，Enter-PSSession和Invoke-Command也是走 WinRM 的，前面配好的连接参数能直接复用：

$cred = Get-Credential Invoke-Command -ComputerName 192.168.1.101 -Credential $cred ` -ScriptBlock { Get-Service | Where-Object Status -eq 'Running' }

Invoke-Command的好处是支持-ComputerName传数组，天然批量，返回结果里自带 PSComputerName 字段，哪台机器返回了什么一目了然。

4.2 Linux 控制端用 Python 把流程串起来

真正的自动化场景，控制端往往是一台 Linux 机器。这时候用 Python 的 pywinrm 库是最顺手的路径：

pip install pywinrm

连接和执行的骨架大概是这样：

import winrm session = winrm.Session( 'http://192.168.1.101:5985/wsman', auth=('Administrator', 'P@ssw0rd'), transport='ntlm', ) result = session.run_cmd('cmd', ['/c', 'dir C:\\Windows\\Temp']) print(result.status_code) print(result.std_out.decode('gbk', errors='replace'))

这里有三处我一开始都栽过。第一，run_cmd的第一个参数是可执行文件名，后面的参数要用列表传，不能把一整条命令塞进一个字符串里。第二，像dir、copy、type这些是 cmd 的内建命令，它们不是独立可执行文件，必须通过cmd /c才能跑起来。直接run_cmd('dir')会报找不到文件。第三，Windows 中文环境默认代码页是 936，输出要按 GBK 解码，用 UTF-8 解会看到一堆乱码。

如果你想统一成 UTF-8，可以在命令开头临时切代码页：

result = session.run_cmd('cmd', ['/c', 'chcp 65001 >nul & ipconfig /all']) print(result.std_out.decode('utf-8', errors='replace'))

不过chcp 65001对某些老程序的输出会有副作用，所以我的习惯还是按 GBK 解码更稳，只有在明确知道输出包含非 GBK 字符时才切代码页。

4.3 长任务、超时和输出量这三个坑

跑短命令一切顺利，一旦遇到耗时任务，问题就来了。pywinrm 默认的操作超时是 20 秒，读超时是 30 秒，超了就直接抛异常，命令在远端可能还在跑，但你已经拿不到结果了。解决办法是建 session 的时候显式调大：

session = winrm.Session( 'http://192.168.1.101:5985/wsman', auth=('Administrator', 'P@ssw0rd'), transport='ntlm', read_timeout_sec=180, operation_timeout_sec=150, )

这里有个硬性约束：读超时必须大于操作超时，一般建议至少多 10 秒。这个顺序搞反了，连接会直接报参数错误，而且错误信息不会告诉你是因为这个原因，我第一次遇到的时候排查了很久。

另一个坑是输出量。WinRM 单次返回的结果有个信封大小限制，默认 500KB 左右，超出会报错。如果命令输出特别大（比如遍历整个磁盘），要么在命令侧做过滤（只取前 N 行、只统计行数），要么把这个限制调大：

Set-Item WSMan:\localhost\MaxEnvelopeSizekb -Value 2048 Restart-Service WinRM

调完记得重启服务，不然不生效。我的经验是，能不给服务端改参数就不改，优先在命令侧收敛输出，这样对目标机器的影响最小。

还有一点容易被忽略：WinRM 启动的进程工作目录默认是C:\Windows\System32，而不是用户的主目录。所以脚本里如果有相对路径，十有八九会找不到文件。稳妥的做法是全部用绝对路径，或者在命令开头先cd /d到目标目录。

5. 常见报错与排查实录

5.1 连接阶段的报错速查

连接不通是最常见的一类问题，我把遇到过的整理成表，按这个顺序查基本能覆盖大部分情况：

排查顺序我一般是这样的：先在控制端用Test-NetConnection 192.168.1.101 -Port 5985确认端口通不通。端口不通，问题在网络或者防火墙；端口通了还连不上，问题在服务或者认证。这一步能砍掉一半的排查工作量。

端口通了但认证失败，就去控制端看 TrustedHosts 配了没有，目标端的认证方式开了没有。winrm get winrm/config/service/auth能一次看到所有认证开关的状态，比一个个查快得多。

5.2 认证阶段的报错

认证类的报错信息通常比较含蓄，常见的有这么几种：

• "Kerberos 认证错误：找不到指定的主体名称"：一般是在工作组环境里错误地选了 Kerberos 传输。改成 NTLM 即可，或者把目标地址换成主机名并确认 SPN 存在。
• "拒绝访问，错误代码 5"：账号密码是对的，但权限不够。大概率是前面说的远程令牌过滤，或者账号根本不在管理员组。
• "凭据被拒绝"：密码里带了特殊字符，在命令行里被 shell 吃掉了。用引号包起来，或者改用交互式输入凭据。

我遇到过一次很隐蔽的情况：账号密码完全正确，从 A 机器连 B 机器通，从 A 机器连 C 机器就不通，最后发现 C 机器的系统时间比 A 机器慢了两分钟，Kerberos 因为时间偏移过大直接拒绝了认证。域环境下 Kerberos 默认容忍的时间偏差是 5 分钟，超过就会失败。所以排查认证问题时，顺手看一眼两边的时间也是个好习惯。

5.3 大内存机器上 WinRM 起不来的那个坑

这个坑我印象最深，因为它看起来跟 WinRM 毫无关系。有一批配置很高的机器，Enable-PSRemoting跑完之后服务就是起不来，事件日志里报的是存储空间不足之类的错误。折腾了一阵才定位到，问题出在 WinRM 承载进程的内存参数上，跟机器物理内存大反而有点关系。解决办法是把 shell 的内存上限显式调一下：

Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB -Value 2048 Restart-Service WinRM -Force

调完之后服务就正常了。这个参数限制的是每个远程 shell 能用的最大内存，默认 1024MB，绝大多数场景够用，但在一些特殊环境下需要调大或者配合其他参数一起处理。遇到"服务起不来"这类看起来不相关的问题，先翻一下 WinRM 自己的操作日志，位置在事件查看器的"应用程序和服务日志 → Microsoft → Windows → WinRM → Operational"，比瞎猜有效得多。

5.4 执行阶段的异常

连上了也认证过了，命令执行还是可能出问题。几种我遇到过的：

返回码正常但输出为空。多数是命令本身没产生标准输出，比如net stop之类的操作只写事件日志。也有可能是输出被写到了标准错误流，而脚本只打印了std_out。稳妥的做法是两个流都看：

print("OUT:", result.std_out.decode('gbk', errors='replace')) print("ERR:", result.std_err.decode('gbk', errors='replace'))

命令明明在本地能跑，远程就是不行。九成是环境和路径问题。远程会话不加载用户的配置文件，环境变量、PATH、工作目录都跟交互式登录不一样。把命令写成完全不依赖环境的形式，是远程执行的第一原则：可执行文件写全路径，配置文件写全路径，需要环境变量的先在命令里显式设置。

并发一多就开始失败。WinRM 对并发会话数是有上限的，服务端有 MaxConcurrentUsers、MaxShellsPerUser 这些参数。批量跑的时候，我一般会把并发控制在 10 到 20 之间，并且给每次连接加一个随机的小延迟，避免瞬时冲击。为了快而把并发拉到很高，最后往往是大量失败重试，总耗时反而更长。

6. 生产环境落地时我坚持的几个做法

6.1 凭据管理别写成硬编码

这个看起来是常识，但我在实际项目里见过的硬编码凭据太多了。脚本里的密码一旦进了代码仓库，后面想清理非常麻烦。我的做法是分环境处理：测试环境用环境变量，生产环境接统一的凭据管理服务，脚本里只保留一个取凭据的调用。

import os import winrm user = os.environ["WINRM_USER"] password = os.environ["WINRM_PASSWORD"] session = winrm.Session( f'http://{host}:5985/wsman', auth=(user, password), transport='ntlm', )

用环境变量至少能保证密码不进代码文件，比硬编码强一档。如果条件允许，再往上一层用专门的密钥管理服务，把轮换也一起管起来。

6.2 幂等和超时重试要一起设计

批量执行最怕的不是失败，而是"不知道有没有成功"。脚本发出去之后网络断了，命令到底执行没执行，这个状态如果不明确，后续处理就会很被动。我的做法是把所有操作都设计成幂等的——重复执行结果一样，这样重试就没有心理负担。

重试策略上，我只对连接类错误重试，命令返回非零退出码的不重试，因为那通常意味着命令本身有问题，重试一百次也是一样的结果。重试次数控制在 3 次以内，间隔指数退避，避免给目标机器造成额外压力。

6.3 把输出处理成结构化数据

原始的命令输出是一堆文本，直接塞进日志里既不好读也不好查。我一般会在拿到输出之后立刻做一次解析，转成字典或者 JSON，再往下游传。比如收集磁盘信息，与其保存wmic的原始输出，不如解析成{"C:": {"total": 500, "free": 120}}这样的结构，后续做告警、做报表都方便得多。

解析这一步要特别小心编码和格式差异。不同版本的 Windows，同一条命令的输出格式可能有细微差别，列宽、表头、空行都可能不一样。解析逻辑一定要加容错，遇到解析不了的行就跳过并记录，不要让整个流程因为一行意外输出而中断。

6.4 审计和可追溯

远程执行这件事，最大的风险是"谁在什么时候对哪台机器做了什么"。我的做法是在控制端记录每一条执行日志，包含目标主机、执行的命令、发起账号、开始结束时间和返回码，写到独立的日志文件或者日志服务里。目标端也可以打开 WinRM 的操作日志，两边对得上，出了问题才追得清楚。

需要留意的是，日志里不要记录完整的命令行参数，尤其是带密码的那种。执行日志记的是操作意图，不是操作细节，这条线要划清楚。

6.5 一个我用了很久的小模板

最后分享一个我在批量巡检里反复用的结构，把连接、执行、解析、记录串成一条流水线，改改就能套到别的任务上：

import winrm def run_on_host(host, user, password, command, args): session = winrm.Session( f'http://{host}:5985/wsman', auth=(user, password), transport='ntlm', read_timeout_sec=120, operation_timeout_sec=100, ) try: result = session.run_cmd(command, args) return { "host": host, "rc": result.status_code, "out": result.std_out.decode('gbk', errors='replace'), "err": result.std_err.decode('gbk', errors='replace'), } except Exception as exc: return {"host": host, "rc": -1, "out": "", "err": str(exc)} hosts = ["192.168.1.101", "192.168.1.102"] for h in hosts: print(run_on_host(h, "Administrator", "改成从凭据服务取", "cmd", ["/c", "ipconfig /all"]))

这个模板的价值不在于代码有多巧妙，而在于它把异常也当成正常结果返回，不会因为一台机器连不上就让整批任务崩掉。批量运维里，单点失败是常态，让失败变成一条可记录的数据，比让它变成一次异常抛出要实用得多。

还有个小技巧值得一试：第一次接入一批新机器时，先用一条最简单的cmd /c echo ok做连通性验证，跑通了再上真正的业务命令。这条命令几乎不依赖任何环境，返回也快，能最快地把"连不上"和"命令写错了"这两类问题区分开。我现在的习惯是把它做成巡检脚本的第一步，二十台机器十几秒就能筛出哪些还没配好，剩下的时间专心处理真正的业务逻辑。