eNSP 华为 SSH 登录失败：RSA、AAA、VTY、Cloud 排查

在 eNSP 里敲完stelnet server enable和 AAA 用户一点连接就提示连接被拒绝或者反过来宿主机能 ping 通设备SSH 却死死卡在认证阶段屏幕上只有一句含糊的失败提示——这种 eNSP 配置 SSH 登录失败的情况只要认真做过华为方向的实验基本都撞过。真正让人头疼的地方在于eNSP 的报错信息非常惜字如金它不会告诉你到底是链路不通、服务没起来还是认证参数没对上号。你要么凭经验猜要么从最下面一层慢慢往上排。这篇内容就是把我自己踩过的那些坑和排查顺序完整摊开来讲。我会先把 SSH 在 VRP 上的服务模型拆成三段链路说清楚rsa local-key-pair create、stelnet server enable、ssh user、local-user、VTY 下的authentication-mode和protocol inbound这几条命令各自作用在哪一环再给出一份可以直接照抄的 AR 路由器配置清单和验证流程最后聊从宿主机连进模拟网络时那条 Cloud 桥接链路上最容易翻车的地方。刚接触 eNSP 实验的同学可以顺着步骤走被密码明明是对的却登不上折磨过的老手也可以拿来复盘。1. SSH登录失败先别急着改配置把登录路径拆成三段SSH 登录失败这件事最忌讳的就是一上来乱改配置。今天加个用户明天换个密码后天把 VTY 全删了重配——最后连自己改过什么都不记得。我的习惯是先画一条路径图把一次成功的 SSH 登录拆成三个必须全部打通的环节然后逐段验证。只要某一段断了后面的配置写得再漂亮也是白搭。这三段分别是发起端到设备 VTY 接口的网络可达性、设备上 SSH 服务本体是否真正运行、AAA 与 VTY 的认证授权是否匹配。它们之间是串联关系不是并列关系。1.1 第一段从发起端到设备VTY接口的地址可达性这一段最基础也最容易被忽略因为很多人默认我在 eNSP 里连的线肯定通。实际上不通的情况非常常见接口没配 IP、接口被shutdown、两台设备之间跨了网段却没配路由、VLAN 没放通、或者干脆把线连到了错误的接口上。排查方法就是最朴素的那一招R2 ping 10.0.0.1如果 ping 不通别往下看 SSH 的配置了先把二层和三层打通。这里有个细节值得说能 ping 通不代表 SSH 就一定通但 ping 不通 SSH 一定不通。所以 ping 是我排查时的第一个动作它成本最低、结论最明确。还有一类更隐蔽的情况ping 通的是设备的某个业务接口但你实际连的地址指向另一个接口而那个接口所在的 VTY 访问路径被 ACL 挡住了。eNSP 里 ACL 误伤 VTY 的实验场景不算少尤其是做acl 3000配合 NAT 或防火墙实验时顺手把user-interface下的acl也配上结果自己把管理通道封死了。提示排查阶段建议先执行display current-configuration | include acl确认 VTY 下没有被acl绑定误伤。1.2 第二段设备上SSH服务本体是否真正运行这一段的核心是两个东西RSA 主机密钥对和SSH 服务开关。VRP 上的 SSH 服务端不是天生就开着的你必须显式地生成密钥、显式地开启服务缺一不可。很多人卡在命令敲了但没生效原因往往是顺序错了或者命令根本没执行成功。比如先敲stelnet server enable再去生成 RSA 密钥某些版本会提示密钥不存在、服务无法正常对外提供连接。正确顺序是先有密钥再开服务。验证服务有没有真正起来用这两条命令AR1 display ssh server status AR1 display rsa local-key-pair public前者能看到 SSH 服务器状态是否为 Enable后者能看到本机是否已经存在主机密钥对。如果密钥那一栏是空的说明生成动作根本没成功这时候再怎么改 AAA 都是徒劳。1.3 第三段AAA与VTY的认证授权是否匹配这是密码明明对却登不上的高发区。VRP 的 SSH 认证要同时满足三个条件我把它们列成一张表方便对照检查。检查项配置位置缺失后的典型表现本地用户已创建aaa视图下local-user认证直接失败提示用户名或密码错误用户服务类型包含 sshlocal-user xxx service-type ssh认证通过但被拒绝建立连接用户权限级别足够local-user xxx privilege level 15能登录但看不到配置、无法进系统视图SSH 用户认证方式ssh user xxx authentication-type password密码正确仍提示认证失败VTY 认证模式为 aaauser-interface vty下authentication-mode aaa登录被提示需要密码但怎么输都不对VTY 允许 SSH 接入user-interface vty下protocol inbound ssh连接被拒绝或直接超时断开这张表里的每一行我都真实踩过其中ssh user xxx authentication-type password和protocol inbound ssh这两行是最高频的遗漏项后面我会单独展开讲。2. stelnet服务起不来RSA密钥对生成的时机与常见报错SSH 和 Telnet 最本质的区别在于加密而加密的前提是双方能协商出一套密钥。服务端这一侧需要一个RSA 主机密钥对用来在握手阶段向客户端证明我是我。这也是为什么 VRP 上必须先生成密钥SSH 服务才有意义。2.1 为什么VRP必须先有RSA主机密钥从协议角度看SSH 建立连接时会经历版本协商、算法协商、密钥交换、用户认证四个阶段。在密钥交换阶段服务端必须向客户端提供自己的主机公钥客户端据此判断是不是第一次连接这台设备。如果服务端根本没有主机密钥握手在第一步就断了客户端看到的就是连接被拒绝或者握手中途断开。这就解释了一个大家常问的问题为什么 Telnet 什么都不用配就能连SSH 却要先生成密钥因为 Telnet 是明文协议压根没有密钥交换这一步也就没有身份证明的概念。理解了这一层你就不会再觉得生成密钥是个多余的仪式。2.2 生成密钥时的模数选择与eNSP卡死假象生成密钥的命令在 eNSP 的 AR 系列上是这一条AR1 system-view [AR1] rsa local-key-pair create回车之后设备会问你密钥长度The key name will be: AR1_Host The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, it will take a few minutes. Input the bits in the modulus[default 2048]:直接回车用默认的 2048 位就行。这里有个真实的坑选 2048 位时eNSP 里的设备可能会卡十几秒到几十秒界面没反应你以为是模拟器崩了然后强制关掉——结果密钥只生成了一半。这种情况下的表现是后续 SSH 怎么都连不上而且display rsa local-key-pair public里看不到完整的密钥信息。我的做法是敲完命令就耐心等观察设备窗口有没有滚动出新的提示行别急着点关闭。如果实在等太久可以退一步用 1024 位Input the bits in the modulus[default 2048]: 10241024 位在实验环境里完全够用生成速度快很多也不会影响你练习 SSH 配置这个目的。生产环境当然要用 2048 位及以上但实验室里的第一优先级是先跑通。2.3 用display命令确认服务真的在监听密钥生成完接着开服务[AR1] stelnet server enable然后务必验证不要凭感觉[AR1] display ssh server status正常的输出里应该能看到服务器状态为 Enable、SSH 版本信息、认证超时时间这几项。如果状态显示为 Disable说明你的开启命令没生效可能是权限不够没进系统视图也可能是当前镜像根本不支持。还有一条命令值得记住[AR1] display ssh server session当有客户端连上来之后这里会列出当前活跃的 SSH 会话。排查到底有没有连上来时它比任何猜测都可靠——如果这里为空说明连接压根没到服务端如果有会话但很快就消失说明是认证阶段被踢掉了。提示display ssh server status和display ssh server session这两条命令是我排查 SSH 问题时的固定组合一条看服务、一条看连接能快速把问题范围缩小一半。3. 密码明明是对的漏掉ssh user这一行的完整解释如果要说哪个配置项最容易被漏我投票给ssh user。很多教程只写了 AAA 里创建本地用户却没写服务端的 SSH 用户认证方式结果就是密码输入正确、用户名也正确认证依然失败。这一节把几个容易混淆的命令讲透。3.1 local-user的三个必备属性缺一不可在aaa视图下创建本地用户必须同时给三个属性[AR1] aaa [AR1-aaa] local-user admin password irreversible-cipher Huawei123 [AR1-aaa] local-user admin privilege level 15 [AR1-aaa] local-user admin service-type ssh [AR1-aaa] quit第一条设密码第二条设权限级别第三条限定这个用户能用来做什么服务。第三条是最容易漏的如果不写service-type ssh这个用户在 SSH 认证阶段会被直接拒绝因为 AAA 认为该用户不具备使用 SSH 服务的资格。顺便说一句密码存储方式。irreversible-cipher表示不可逆加密存储配置回显里看不到明文这是规范做法。有些老教程用cipher在较新的版本上可能会被提示为不安全写法。实验环境用哪个都能跑通但养成用irreversible-cipher的习惯没坏处。权限级别也要留心。级别太低比如 0 或 1时用户能通过认证但登录进去只能在用户视图里晃system-view进不去看起来就像登录成功了但什么也干不了。所以做 SSH 实验时统一给 level 15省心。3.2 ssh user authentication-type到底在管什么这条命令是全文我最想强调的一条[AR1] ssh user admin authentication-type password [AR1] ssh user admin service-type stelnet它管的是SSH 服务端对某个用户采用哪种认证方式。VRP 的 SSH 支持 password、rsa、password-rsa、all 等几种认证类型。如果你不显式声明服务端在某些版本上会采用默认策略而这个默认策略不一定匹配你用的密码认证方式结果就是AAA 里用户建得好好的SSH 就是认证不过。第一条声明用密码认证第二条声明这个用户可以用 stelnet 服务。这两条配完之后再配合 AAA 里的本地用户认证链路才算完整。这里补充一个经验在某些版本上如果ssh user没有配置服务端会回退到 VTY 的认证模式来处理此时可能反而能连上。这就导致同一个配置在不同人手里表现不一样有人在 AR2220 上通、换到 AR201 就不通。遇到这种玄学情况不要怀疑自己把ssh user补齐一半以上的问题会消失。3.3 VTY下的authentication-mode与protocol inbound最后是 VTY 这一段[AR1] user-interface vty 0 4 [AR1-ui-vty0-4] authentication-mode aaa [AR1-ui-vty0-4] protocol inbound ssh [AR1-ui-vty0-4] quitauthentication-mode aaa表示 VTY 的登录认证交给 AAA 处理也就是走本地用户那条路。如果不写VRP 默认可能是 password 模式此时你输的密码是 VTY 自己那套set authentication password设的密码和 AAA 里的用户密码完全无关——这就是密码明明是对的这类问题时最常见的真相你输的密码属于另一个认证体系。protocol inbound ssh表示这个 VTY 只允许 SSH 接入。如果不配默认是 allTelnet 和 SSH 都允许一般也能用但在做安全加固实验时会明确限定为 ssh。这里有个反向坑如果你为了做实验把protocol inbound设成了 telnet那 SSH 连接会被直接拒绝而且提示信息非常不明显。排查时记得看一眼这一行。提示如果设备里同时配了 VTY 的set authentication password和 AAA 的本地用户容易自己把自己绕晕。做 SSH 实验时统一走 AAA不要在 VTY 下额外设密码。4. 一份可以照抄的AR路由器SSH服务端配置与验证流程前面讲的是原理和排查思路这一节给一份完整可复现的配置。我把命令按执行顺序排列每一段都说明它在做什么方便你对照自己的环境检查。4.1 完整配置清单与逐段说明假设拓扑是 R1 和 R2 直连网段 10.0.0.0/24R1 作为 SSH 服务端10.0.0.1R2 作为客户端。R1 侧的完整配置AR1 system-view [AR1] sysname AR1 [AR1] interface GigabitEthernet0/0/0 [AR1-GigabitEthernet0/0/0] ip address 10.0.0.1 24 [AR1-GigabitEthernet0/0/0] undo shutdown [AR1-GigabitEthernet0/0/0] quit [AR1] rsa local-key-pair create [AR1] stelnet server enable [AR1] aaa [AR1-aaa] local-user admin password irreversible-cipher Huawei123 [AR1-aaa] local-user admin privilege level 15 [AR1-aaa] local-user admin service-type ssh [AR1-aaa] quit [AR1] ssh user admin authentication-type password [AR1] ssh user admin service-type stelnet [AR1] user-interface vty 0 4 [AR1-ui-vty0-4] authentication-mode aaa [AR1-ui-vty0-4] protocol inbound ssh [AR1-ui-vty0-4] idle-timeout 10 0 [AR1-ui-vty0-4] quit最后一句idle-timeout 10 0是把空闲超时设成 10 分钟 0 秒。默认值通常是 5 分钟做实验时经常出现我去查个资料回来会话就断了的情况把它调大一点能省不少事。R2 侧的客户端配置AR2 system-view [AR2] sysname AR2 [AR2] ssh client first-time enable [AR2] quit AR2 stelnet 10.0.0.1ssh client first-time enable这一条是客户端必备的。SSH 客户端第一次连接陌生服务器时需要确认对端主机公钥如果不开启首次认证客户端会直接拒绝建立连接提示大意是未启用首次认证无法继续。这个报错经常被误判成服务端问题实际上问题在客户端。如果你的版本上stelnet命令不识别可以试试ssh 10.0.0.1不同 VRP 版本对客户端命令的命名略有差异。4.2 用同一拓扑里的另一台设备做客户端验证我强烈建议第一轮验证就在 eNSP 内部完成先别急着从宿主机连。原因很简单内部验证排除了桥接、防火墙、虚拟网卡这些外部变量只要内部能连上说明服务端配置没问题剩下的都是桥接的事。验证顺序建议这样走在 R2 上ping 10.0.0.1确认三层可达。在 R1 上display ssh server status确认服务为 Enable。在 R2 上执行stelnet 10.0.0.1输入用户名 admin 和密码。在 R1 上display ssh server session确认能看到活跃会话。这四步里任何一步断了问题范围立刻缩小到对应那一段。比如第 2 步就失败了你根本不用看 AAA先解决服务开启的问题。4.3 验证成功的三个判据登录成功之后怎么确认是真的成功了而不是看起来像成功我给三个判据R2 侧提示符从AR2变成了AR1说明你已经站在对端设备上。display ssh server session里能看到一条状态为 established 的会话说明连接是真实存在的。在 R2 上执行display ssh client相关命令能看到对端信息部分版本支持说明协商参数正常。三个判据里我最看重第二个。有太多人看到提示符变了就以为万事大吉其实可能是 Telnet 会话残留或者别的东西。服务端能列出一条 established 的 SSH 会话才是硬证据。5. 从宿主机SSH登录eNSP设备Cloud桥接里最容易出错的几个点内部验证通了接下来很多人就想用 SecureCRT、PuTTY 或者系统自带的 ssh 命令从宿主机直接连进 eNSP 的设备。这一步比内部验证复杂得多因为它牵扯到 eNSP 的 Cloud 设备、虚拟网卡和宿主机防火墙。5.1 Cloud设备双端口绑定的原理eNSP 里的Cloud云设备本质是一个翻译器它负责把模拟器内部的虚拟网络和宿主机所在的真实网络连起来。理解它的关键就是一句话它需要两个端口一个对着模拟网络一个对着宿主机然后在这两个端口之间建立映射。大致操作流程是这样在 eNSP 里拖一个 Cloud 出来双击打开配置界面。在绑定信息里增加一个端口类型选 Ethernet绑定到一个自定义的 UDP 端口。再增加一个端口类型同样选 Ethernet绑定到宿主机的某块网卡比如 VirtualBox Host-Only 网卡或者某块物理网卡。在端口映射表里把这两个端口映射起来。不同版本的 eNSP界面上字段的叫法略有差异但只要抓住一个端口朝内、一个端口朝外、中间做映射这个核心就不会迷路。接好之后用一根线把 Cloud 的端口连到路由器的接口上然后给路由器接口配一个和宿主机对应网卡同网段的地址。比如宿主机 Host-Only 网卡是 192.168.56.1/24那路由器接口就配 192.168.56.10/24宿主机的 ssh 客户端连 192.168.56.10 就行。5.2 端口映射与防火墙的干扰这一步的坑基本集中在两个地方映射没做全和防火墙拦截。映射没做全的表现是你能 ping 通 Cloud但 ping 不通路由器或者设备侧能看到 ARP 但 ping 不回。这时候回去检查端口映射表确认两个端口之间确实建立了双向映射而不是只加了一个端口没做映射。防火墙的问题更隐蔽。Windows Defender 防火墙默认会拦截一部分进入本机的流量尤其是走虚拟网卡的那部分。表现是宿主机 ping 不通路由器或者能 ping 通但 SSH 连不上。排查时可以临时关闭防火墙验证一下# 以管理员身份运行 PowerShell临时关闭防火墙做验证 Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False验证完记得改回来。如果确认是防火墙的问题正确做法不是一直关着而是在防火墙里放行对应网卡和端口或者针对 SSH 的 22 端口加一条入站规则。关防火墙只是排查手段不是解决方案。还有一个容易被忽略的点宿主机网卡和路由器接口的 IP 必须在同一网段而且不能和其他设备冲突。Host-Only 网卡的网段如果被 VirtualBox 改过你的路由器接口地址就会失联。检查一下宿主机的ipconfig确认虚拟网卡的地址段。5.3 eNSP与VirtualBox版本错配引发的设备起不来这一类问题严格来说不是 SSH 配置问题但会直接导致你的 SSH 实验做不下去因为设备根本起不来。热词里出现的ensp 启动设备 ar1 失败 40就是典型症状。eNSP 依赖 VirtualBox 来做底层虚拟化。经验上eNSP 1.3.00.100 搭配 VirtualBox 5.2.x 系列最稳其中 5.2.44 是很多人推荐的组合。如果宿主机装了 VirtualBox 6.x 或更高版本经常会出现设备启动失败、错误码 40 或 41 的情况。处理思路是卸载当前 VirtualBox安装 5.2.x 版本然后重新安装 eNSP让它重新绑定。安装顺序也有讲究——先装 VirtualBox再装 eNSP反过来容易出现组件注册不全的问题。提示每次换 VirtualBox 版本都建议把 eNSP 里的设备全部删掉重建。旧设备实例是绑定在特定版本的虚拟化组件上的换版本后残留的配置文件会引发各种奇怪错误。如果你用的是 eNSP Pro 这类新形态的版本部署方式变成了虚拟机镜像网络桥接的思路类似但配置入口不一样别拿老教程硬套。离线版本在部署时还要注意导入的镜像完整性和宿主机资源分配内存给太少会导致设备启动后运行卡顿甚至服务起不来。6. 几类看着像SSH问题、其实根本不是的情况排查久了会发现有一类SSH 登录失败其实是误诊。错误信息长得很像但根因完全不在网络设备上。把它们分清楚能少走很多弯路。6.1 宿主机侧SSH服务端报错与eNSP无关有些朋友搜登录失败这个词的时候会搜到一堆和 Windows 服务端、Linux 服务端相关的报错。比如系统里启动某个 SSH 服务端组件时提示 failed to start login server或者 Windows 提示未授予用户在此计算机上的请求登录类型。这些提示描述的是宿主机自己作为服务端时的问题和你用 eNSP 做 SSH 客户端实验没有半点关系。判断方法很简单看这个报错出现在哪里。如果它出现在你启动某个本地服务、或者远程登录 Windows 桌面的时候那它属于宿主机的账户权限与服务配置范畴如果它出现在 eNSP 设备的控制台窗口里或者出现在 SecureCRT 连接 eNSP 设备的弹窗里那才是本节讨论的范畴。先定位报错的发生地再决定查哪一套资料这是省时间的关键。6.2 低端型号与镜像能力差异eNSP 里不同型号的 AR 设备功能支持度是有差异的。有些低端型号或较老的镜像对 SSH 相关命令的支持并不完整可能出现命令敲不进去或者配了但不生效的现象。遇到这种情况我的建议是换设备型号再试一遍。把 AR201 换成 AR2220 或 AR2240同样的配置往往立刻就能跑通。这不是你的配置写错了而是设备能力边界的问题。实验室里没必要和型号较劲能把原理验证清楚就行。同理某些路由器镜像的 VTY 用户界面数量也不一样有的是 vty 0 4有的是 vty 0 14。配置时如果不确定直接敲user-interface vty 0 4一般都能进进了之后用display this确认一下实际情况。6.3 会话被顶掉、超时断开与idle-timeout还有一类现象是能连上但很快断。这通常不是认证问题而是 VTY 的空闲超时在起作用。默认 5 分钟不操作就自动断开做实验时很容易被这个机制打断。调整方式就是在 VTY 下改超时时间[AR1] user-interface vty 0 4 [AR1-ui-vty0-4] idle-timeout 30 0另外还有用户数超限的问题。VTY 0 4 意味着最多 5 个并发会话0、1、2、3、4如果你同时开了好几个终端连同一台设备第 6 个就会被拒绝。表现是前面能连现在连不上很容易被误判成配置坏了。用display users看看当前有哪些会话占着必要时把空闲会话踢掉。AR1 display users AR1 display ssh server session这两条命令配合使用能快速判断是连不上还是连满了。最后分享一个我自己养成的习惯每次做完 SSH 实验我都会把关键验证命令的输出截图或者复制出来存档包括display ssh server status、display ssh server session和完整的display current-configuration。原因是有一次我在两个拓扑之间来回切换把 A 拓扑能用的配置套到 B 拓扑上死活连不通折腾了快两个小时最后翻出之前的存档一对比发现是 B 拓扑里 VTY 的protocol inbound被之前做 Telnet 实验时改掉了。从那以后我就明白了SSH 登录失败十有八九不是某个高深的问题而是某个不起眼的一行配置在悄悄使坏——而对照存档是找这行配置最快的办法。