基于PSO粒子群算法的无线传感器网络覆盖优化Matlab仿真
2026/10/1 3:58:57
在 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 | 认证直接失败，提示用户名或密码错误 |
| 用户服务类型包含 ssh | local-user xxx service-type ssh | 认证通过但被拒绝建立连接 |
| 用户权限级别足够 | local-user xxx privilege level 15 | 能登录但看不到配置、无法进系统视图 |
| SSH 用户认证方式 | ssh user xxx authentication-type password | 密码正确仍提示认证失败 |
| VTY 认证模式为 aaa | user-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 Huawei@123 [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 接入。如果不配，默认是 all（Telnet 和 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/24，R1 作为 SSH 服务端（10.0.0.1），R2 作为客户端。
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 Huawei@123 [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 登录失败十有八九不是某个高深的问题，而是某个不起眼的一行配置在悄悄使坏——而对照存档，是找这行配置最快的办法。