简介：堡垒机作为集中管控远程设备的关键系统，常被企业用于安全运维。这份PDF以图文形式整理了堡垒机从登录到远程连接的完整使用流程，面向网络运维新手与需要快速上手的IT支持人员，重点说明了首次登录改密、设备资源列表查看，以及基于Linux SSH、Windows RDP等不同系统的连接方式选择，同时涉及登录后查看网卡信息、远程桌面连接等常用操作。资源为单个PDF文件，容量461KB，内容紧凑清晰，已有268人学习使用。除基础操作外，文档还针对Windows 7等环境下的JAVA验证拦截问题给出了处理思路，并比较了CRT、Putty、Web页面三种登录方式的适用场景，涵盖Linux设备选SSH、Windows设备选RDP的登录方式，可帮助读者避开通配工具版本与安全策略方面的常见坑，直接提升远程维护效率。整体而言，内容精炼，适合作为内部培训或自学入门资料。
1. 堡垒机不是跳板机：从一次失败的登录说起
堡垒机这三个字，在运维圈里常被当成跳板机的同义词，实际上它比跳板多了一层核心逻辑：放行之前先做身份与授权校验，放行之后留全过程审计。我最近在整理内网运维交接时重过了一遍手头这份使用说明，发现它对新人最珍贵的一点是老实——入口地址、首次登录改密、JAVA例外、CRT/Putty和Web三种登录方式，全都按照操作顺序排好了。像我这边的明御堡垒机就在 192.168.200.38，登录后只显示 yibo 这个账号被授权的设备，其他资产一概看不见。适合谁：第一次接触堡垒机的运维、给部门内部配权限的同事，以及临时要连某一台 Linux 或 Windows 服务的同事。对照本文走一遍，能少踩一半的证书和客户端版本坑。
2. 接入层与选型逻辑：堡垒机登录到底放行了什么
2.1 浏览器接入层：为什么所有入口都要收拢到一个地址
文档开头那行地址写得非常简略，s://192.168.200.38/user/requireLogin，去掉协议前缀，剩下的是一个统一登录门户。堡垒机的设计逻辑和传统跳板有一个明显差异：跳板机只负责把流量转进去，而堡垒机把“你能访问什么资产”的决策收敛到了登录这一步。只要你没有在这个地址通过账号密码审计，就算你知道背后有 10.80.4.201 或 10.80.4.138，也无法直连到内网里。
这种收敛带来的操作变化是：我们不再在电脑里维护一个庞大的 SSH/RDP 主机列表，而是登录堡垒机之后看它给你开放的资源列表。文档里那句“这时候能看到 yibo 可以访问的设备资源”说的就是这个授权模型。它同时解决了两件事：一是新人接手时不用问前辈要几十个 IP；二是离职或转岗时关闭一个账号就能收回全部权限，不需要逐台服务器去删公钥。
我一般建议运维不要把这些校验步骤当成纯流程负担，它其实是把“谁能连谁”变成了一个可管理的清单。登录前先问三个问题：身份是否通过、授权是否覆盖目标资产、行为是否留痕。对应到这份文档里就是：首登改密、看到资源列表、连接过程可审计。这三层如果都成立，再往下配置客户端才有意义。
2.2 账号与资产授权：首次改密不是走过场
文档里有一条容易被一带而过的规则：第一次登陆需要修改密码。很多人会当成普通的“强制改初密”处理，随手改成一样的密码又去连接，结果发现某些功能仍然不可用。原因是堡垒机的账号状态和授权策略是绑定的，初始密码在数据库里标记为“待修改”，未完成的账号可能会被策略限制发起新会话。
我习惯在改密后用新密码重新登录一次，确认能够回到资源列表再做其他操作。这能避免一种尴尬：在本地客户端里把密码改了，但堡垒机侧状态没刷新，等真正连接目标资产时反复提示认证失败。文档后面提到的“win7 需要把当前页面添加例外”也属于这一类前置条件——先把浏览器信任链打通，再谈登录。
这里可以整理成一张简单的对应关系表，方便对照自己的环境排查：
| 层 | 常见实现 | 文档中对应步骤 |
|---|---|---|
| 身份校验 | 账号 + 密码 + 首登强制改密 | 输入 yibo 账号，首次登录修改密码 |
| 授权校验 | 绑定账号可访问的资产列表 | 登录后只看到授权设备资源 |
| 操作审计 | 会话录像与命令记录 | 整个远程连接过程走堡垒机转发 |
2.3 证书与本地客户端的取舍：先配浏览器还是先装客户端
实操中大多数人第一步就是打开浏览器输入 IP，然后被证书警告卡住。堡垒机网关通常使用内部证书，浏览器默认不信任，这在 Win7 的 IE 里尤其明显。文档把“添加例外”放在远程连接之前，说明作者吃过这个亏：不在浏览器层放行，后续 SSH/RDP 的原生客户端也可能会因为同样的证书信任问题被拦。
处理顺序我认为应该是：先把堡垒机地址加入浏览器受信任站点，用 Web 方式登录一次确认账号和授权正常；接着再配置 CRT、Putty 这类本地客户端。先验证入口，再优化体验。如果第一步就卡在证书上，后面配置得再熟练也没用。至于选型偏好，我看到大多数长期维护环境的同事都倾向“能调本地客户端就尽量调本地客户端”，因为浏览器内嵌的 Web 方式依赖 Java 或 ActiveX 组件，版本变动和环境兼容性问题更多。
3. 远程登录方式三选一：CRT、Putty 与 WEB 页面的取舍
3.1 CRT 与 Putty 调用本地工具：版本匹配是第一道坎
文档里写得很清楚：登录 Linux 的 10.80.4.201 有三种方式，CRT、Putty、自带 WEB 页面。前两种需要调用本地工具，而且有相应版本要求。这里“版本要求”不是随便写的，堡垒机升级后，加密算法和密钥交换算法会更新，老版本 CRT 或 Putty 在 SSH 握手阶段就可能被断开。
我上手第一件事是先确认本地 SSH 客户端可用。Windows 上可以在命令行直接验证：
# 查看 Windows 自带 OpenSSH 客户端版本 ssh -V # 测试从本机到目标资产 22 号端口的连通性 Test-NetConnection 10.80.4.201 -Port 22第一行命令能确认系统里至少有一套可用的 SSH 工具；第二行命令测试的是网络链路。需要注意，Test-NetConnection返回的TcpTestSucceeded为True只代表目标端口可访问，不代表堡垒机会放行，因为你还没过认证。真正判断是否能连，要以堡垒机资源列表里的实际会话为准。
CRT 和 Putty 的区别在于前者是商业化客户端，会话管理和多标签体验更好；后者是免费绿色工具，适合临时拷贝到其他机器上使用。如果公司内网经常有新人入职，我一般会在共享盘放一个固定版本的 Putty，避免每个人下载的版本不一致导致无法复现问题。版本匹配这件事，没有玄学，只有一致。
3.2 自带 WEB 页面登录：不装客户端的兜底方案
第三种方式是堡垒机自带的 WEB 页面登录，不需要在本地安装任何 SSH 客户端。这种方案适合在临时工位、外部电脑或者本地工具受限的终端上使用。代价是首次使用通常会触发 Java 安全提示，文档里的原话是“若弹出 JAVA 验证，点允许通过”。
这里要特别说明：网页内嵌的 SSH 终端本质上是浏览器通过 Java Web Start 或 ActiveX 调用本地运行时，它在身份认证通过后直接在网页里给你一个终端窗口。相比 CRT 的好处是不挑客户端软件，坏处是每次打开可能都会弹一次安全提醒，而且维持长连接时如果浏览器自动更新导致插件失效，终端会直接关闭。
我自己对这种方式的使用建议是：应急用、临时用、跨设备用；高频日常操作还是老老实实装一个本地客户端。文档把 WEB 方式列在第三位，也说明它属于兜底方案而不是首选。登录进去后记得先看一眼whoami和hostname，确认你进的确实是目标资产，而不是一台跳板中转区主机。
3.3 Windows 资产 RDP 的两种路径差异
文档对 Windows 资产的描述更细致，登录 10.80.4.138 时有两条路径。第一种是“远程桌面连接”，需要调用本地资源，大多数使用此方式；第二种是自带 WEB 登录方式，点击后浏览器运行一个应用程序。这两条路径的本质区别在于是本地mstsc直连还是浏览器内嵌的远程桌面控件。
选第一种时，不需要修改计算机 IP 地址，像正常终端远程连接 4.138 服务器一样，输入用户名密码即可。这里有个细节：RDP 端口是 3389，但门禁地址是堡垒机的，所以你在远程桌面客户端里填的目标电脑仍然是 10.80.4.138，不是堡垒机地址。如果填错了，会连到另一台机器或直接提示找不到主机。
两种方式的对比可以归纳成一张表：
| 登录客户端 | 是否需要本地组件 | 典型适用场景 |
|---|---|---|
| 远程桌面连接（mstsc） | 系统自带远程桌面 | 日常办公机、高频操作 |
| 自带 WEB 登录 | Java / ActiveX 运行时 | 临时终端、本地无工具 |
文档里提到“进去后可以查看本地网卡信息，为本机 4.138 地址信息”，意思是登录成功后你在会话内看到的 IP 应该是对应目标资产的。如果看到的 IP 是堡垒机分配的中转地址，说明选的登录路径不是直连型，需要回到会话入口重新选择。
4. 避坑清单：五个能把人卡住的常见问题
4.1 浏览器与证书层面
第一条坑：浏览器输入地址后直接提示“您的连接不是私密连接”。现象很明确，Chrome 或 Edge 整页告警，点“高级”才看到“继续前往”链接。原因基本是堡垒机用了自签证书，浏览器默认不信任这个证书颁发者。解决办法是手动把证书加入信任列表，或者在浏览器设置里允许该地址的不安全内容。需要注意，不同浏览器入口不同，但都必须明确操作一次，不是刷新就能解决。
第二条坑：Windows 7 下 IE 登录堡垒机一直提示证书不受信任。现象是页面能打开但 Java 组件不加载，整页处于空白或不断刷新。原因是 IE 的受信任站点和 Java 的例外站点是两个独立列表，只加了一个不够。解决办法是在 IE 的 Internet 选项 -> 安全 -> 受信任站点里添加堡垒机 IP，同时打开 Java 控制面板，在安全 -> 例外站点列表里也加上同一条地址。文档里说的“添加例外”指的就是这个双列表操作。
4.2 会话与客户端层面
第三条坑：改完初始密码后第二天登录又提示密码错误。现象很迷惑，明明确认过密码没问题。原因多半是 Windows 凭据管理器或浏览器保存了旧的登录凭据，在你输入新密码后系统自动填充了旧值。解决办法是打开控制面板 -> 用户账户 -> 凭据管理器，把 Windows 凭据里对应堡垒机 IP 的记录删掉，再重新登录。这条血泪经验值得前置，因为很多时候不是堡垒机出了问题，而是本机在跟你作对。
第四条坑：老版本 Putty 或 CRT 登录 Linux 资产时秒断。现象是 SSH 握手结束后立即断开，日志也没有明确报错。原因是堡垒机的加密策略升级后，推送的密钥交换算法与本地客户端不匹配。解决办法有两个方向：一个是把 CRT/Putty 升级到官方新版本；另一个是在 CRT 会话属性里调整 Key Exchange 算法列表，与堡垒机侧策略对齐。如果不想折腾新版本，直接换用堡垒机自带 WEB 方式也能绕过这个问题，但就失去了本地客户端的操作手感。
第五条坑：RDP 登录后提示会话被中断或自动注销。现象是用户名密码都正确，进度条走完却回到登录界面。原因是堡垒机侧配置了会话时长限制或改密后强制注销策略。解决办法是先看堡垒机管理后台对当前账号的会话策略，如果设了短时限，就要在策略允许的窗口内完成操作；临时需要干长活可以申请延时长或选择调度任务方式，不要硬顶着策略重试。翻车次数多了就会发现，这类问题大部分不是技术难点，而是策略边界没搞清楚。
5. Linux SSH 登录细节：从 JAVA 验证到 sshpass not found
5.1 JAVA 验证弹窗为什么反复出现
登录 Linux 资产时最常遇到的是 JAVA 验证弹窗，文档里的操作顺序是：选择 SSH 登录方式 -> 出现 JAVA 验证 -> 点允许通过 -> 正常输入操作。这个弹窗不是每次都出现，但第一次遇到时很容易因为它不够熟悉而误点“不允许”，导致会话直接终止。
查这种玄学问题，核心要看 Java 的受信任站点列表。路径是控制面板 -> Java -> 安全 -> 编辑站点列表，把堡垒机的地址加进去。这里有个容易忽略的细节：JAVA 例外站点要求输入具体地址，不能只写域名，最好把s://192.168.200.38完整填进去。如果还弹，就要检查本机 Java 版本，太旧的 JRE 在 Web Start 场景下兼容性很差，不如直接换一条登录路径。
此外，点击“允许”后终端窗口打开的一瞬间不要立刻输入命令，等底部状态变成可输入状态再操作。现实中不少误操作是因为用户点完允许后连续敲击键盘，前几个字符被丢进了 Java 加载器的缓冲里，看起来像命令输入错乱。
5.2 MobaXterm 登录服务：报 sshpass not found 怎么处理
MobaXterm 是近年来用得最多的 Windows 终端工具，但很多人用它连堡垒机时会在登录服务里遇到sshpass not found。现象是输入账号密码后终端窗口没进入交互界面，而是直接回显一行错误：sshpass not found。
原因是 MobaXterm 的登录服务在调用本地 SSH 时依赖sshpass工具完成密码交互，而它自带的发行包在部分版本里没有捆绑这个工具，或者环境变量指向了不存在的路径。这也是为什么文档里反复强调“前二种需要调用本地工具，有相应版本要求”——版本要求指的不只是客户端本身，还包括它依赖的外部命令。
处理步骤我一般这样走：
# 在 MobaXterm 自带的终端里确认是否已有 sshpass which sshpass sshpass -V如果输出里能找到安装路径并能打印版本信息，说明 sshpass 存在，问题大概率出在客户端加载路径；如果找不到，说明发行包本身没带这个工具。此时最快的做法是把 MobaXterm 升级到官方最新打包版，或者放弃登录服务方式，改为手动建立 SSH 会话并选择“使用 MobaXterm 的 SSH 助手”来处理密码交互。不要试图通过修改系统全局 PATH 引到外部安装的 sshpass，Windows 环境下的路径混合容易引入新的变量，排查起来更费劲。
5.3 自带 WEB 方式登录 Linux 后第一件事做什么
无论用哪种方式进入 Linux 资产，我建议在会话建立后先跑三条命令确认身份与位置：
# 确认当前登录用户，避免拿错账号操作 whoami # 确认主机名，防止会话列表与实际机器不一致 hostname # 查看 IP 地址，重点确认是否命中预期目标网段 ip a文档里只提到输入正常操作即可，但在真实生产环境里，这一步是必须做的。堡垒机资源列表如果维护不及时，会存在名称和 IP 错位的情况；进错主机后的任何操作都可能影响错误的服务。whoami确认权限角色，hostname确认机器身份，ip a确认网络归属，三秒就能完成，挽回的却是误操作成本。我自己接手过的环境里，因为跳过这条检查而在错误主机上重启服务的事情并不少见，从那以后我每次进会话都强制走一遍这三连确认。
6. 验证登录链路的习惯：批量检查脚本把排查压缩到三分钟
6.1 一个把端口与连通性合并检查的小脚本
堡垒机环境里最难定位的问题，是“不知道卡在哪一段链路”。是堡垒机门户不可达，还是本地客户端版本不兼容，还是目标资产端口根本没有监听。这里我平时会跑一个极简的端口自检脚本，把要连的资产按“IP 端口 名称”三列写进去，统一检查。
#!/usr/bin/env bash # 目标列表：资产IP 端口 名称 declare -a TARGETS=( "10.80.4.201 22 linux-web" "10.80.4.138 3389 win-web" ) for entry in "${TARGETS[@]}"; do ip=$(echo $entry | awk '{print $1}') port=$(echo $entry | awk '{print $2}') name=$(echo $entry | awk '{print $3}') # nc -z 做零数据探测，-w 3 控制超时 if nc -z -w 3 "$ip" "$port" 2>/dev/null; then echo "[OK] $name: $ip:$port 端口可达" else echo "[FAIL] $name: $ip:$port 端口不可达" fi done脚本里的nc -z表示只探测端口不发送实际数据，-w 3是三秒超时。awk '{print $1}'从每条记录里切出 IP 字段，端口和名称同理。这个脚本的作用不是替代堡垒机登录，而是把本机到目标资产这段网络链路单独剥离出来验证。如果脚本显示端口不可达，问题大概率出在网络或目标主机本身；如果端口可达但堡垒机连接失败，那就要转向客户端版本和协议配置去排查。Windows 上没有nc时，可以直接改用 PowerShell 的Test-NetConnection -ComputerName 10.80.4.201 -Port 22做同样判断。
检查出来后你再回看堡垒机入口，就能快速区分是“入口坏了”还是“出口坏了”，不用在客户端配置里反复试错。真正难缠的问题往往是本机端口已经通过、堡垒机页面也显示连接成功，但会话建立后立刻掉线，那通常指向算法或策略层，而不是连通性。从那以后我每次接手带有堡垒机的环境，都会先跑一遍这个脚本，再把堡垒机地址加进浏览器与 JAVA 例外，最后才打开 CRT 建会话。这套顺序帮我避开过至少五次无意义的客户端重装。希望帮到你。
本文还有配套的精品资源，点击获取
