企业官网建设流程全解析

在eNSP里把SSH配置敲完，客户端一连却弹出一行no matching host key type found. Their offer: ssh-rsa，或者更干脆，TCP都建不起来，转圈转到超时——这种场面我碰过太多次。eNSP上的SSH登录失败，绝大多数时候不是"配置写错了"这么简单，它往往是三条线同时埋雷：设备侧VRP命令链路的完整性、客户端侧加密算法的协商能力、以及eNSP自身依赖的虚拟化环境是否正常。新手容易在第一条线上死磕，把配置删了写、写了删，其实问题出在Windows自带的OpenSSH客户端默认把ssh-rsa这一批老算法全部关掉了。

我把这套排查逻辑按自己的习惯整理成五块：先讲怎么分层定位，再逐条拆服务端配置的五个环节，接着处理客户端算法和模拟器环境这两类"非配置"故障，然后给一份能照着查的报错速查表和三个真实案例，最后补上设备做SSH客户端、多用户权限以及不同VRP版本的命令差异。刚上手华为模拟器的新手可以按顺序读，做过多年交换路由的老手可以直接跳到第3、4节。整套流程走下来，你至少能明确一件事：这次登录失败，到底该改哪里。

1. 先分层定位，别一上来就改配置

1.1 eNSP的SSH为什么比真机更容易翻车

真机上跑SSH，你面对的是厂商出厂就调好的硬件和一套相对新的VRP版本；eNSP不一样，它是在虚拟化环境里跑一段精简过的VRP镜像，常用的AR路由器镜像大多是V200R003C00这一代，交换机镜像也偏老。这就带来三个天然劣势：第一，这套老VRP支持的密钥交换算法、主机密钥算法、加密算法和HMAC算法都是十几年前的老面孔，而现在的客户端越更新越激进，默认只留新算法；第二，eNSP设备在模拟器里的启动过程本身就不太稳，设备图标还是红的、命令行只出来一半，你就急着去连SSH，自然连不通；第三，eNSP依赖虚拟化平台提供的虚拟网卡做桥接，网卡状态一变，链路层就断了。

我个人的经验是，真机上能通的配置搬到eNSP里失败，八成原因在客户端算法协商，剩下两成里又有一大半是密钥没生成或者设备没启动完全。真正因为AAA用户配错的，比例反而不高——因为那类错误通常报得很直白，比如密码错就是Permission denied，不会让你一头雾水。

1.2 一条SSH会话要跨过的三道坎

把一次SSH登录拆开看，它其实要连过三道关，每一关对应完全不同的报错和不同的处置手段。按顺序来分别是：

• 链路关：客户端到设备的IP可达性。接口是不是up、IP和掩码配没配对、中间有没有ACL拦着、ping得通不通。这一关过不了，报错是Connection timed out或者直接"无法访问目标主机"。
• 端口关：设备22端口有没有在监听。STelnet服务没使能，端口就不存在，报错是Connection refused（Windows上可能是"由于目标计算机积极拒绝，无法连接"）。
• 协商与认证关：算法协商能不能谈拢、用户名密码对不对、这个用户有没有SSH服务权限和足够的权限级别。这一关的报错最花哨，no matching host key type found、no matching key exchange method found、Permission denied、Server refused to open channel都属于这一类。

我排查时习惯从下往上走：先ping，再看端口，最后看协商日志。这样每一步都有明确的验证手段，不会在配置里瞎改。

提示：别跳过链路关。很多"SSH登录失败"最后查出来是接口被shutdown了，或者两台设备的接口IP不在同一网段，跟SSH本身一点关系都没有。

1.3 三个最容易被忽略的前置条件

除了上面三道关，还有三个前置条件经常被跳过，但它们恰恰是eNSP场景下的高频坑点。

第一，设备是不是真的启动完了。eNSP界面上设备图标从红变绿、双击进去能正常敲命令、display version能出结果，这三件事都满足了才算启动完成。有人的设备图标半绿不绿，SSH连上去就断，其实是VRP还在初始化。

第二，RSA密钥对到底生成了没有。SSH要靠非对称密钥来协商会话密钥，VRP里没生成RSA密钥，STelnet服务即使使能了也接不了连接。这是个硬前提，后面会详细讲生成方法和常见报错。

第三，当前VRP版本支持哪些算法。这个决定了你客户端能不能连上。如果你不想折腾客户端，那就得确认设备侧有没有办法放开老算法；如果设备侧版本太老、不支持算法调优命令，那就只能反过来调客户端。

2. 服务端配置逐条拆：从RSA密钥到VTY线路的完整联动

2.1 第一步：生成RSA密钥对，这是SSH的地基

在eNSP的设备上开SSH，第一件事不是stelnet server enable，而是生成密钥。原因很直白：SSH会话建立时，客户端和服务器要先协商出一套对称密钥来加密后续通信，而协商过程本身要用服务器的主机密钥做身份确认和密钥交换保护。没有这对RSA密钥，服务器连"我是谁"都证明不了，后面的协商无从谈起。

命令在老版本VRP上就是一条：

system-view rsa local-key-pair create

敲下去之后会提示你输入密钥模数长度，一般长这样：

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 = 512]:

这里的"a few minutes"不是吓唬人。在eNSP里选2048位，运气不好要等上一两分钟，界面看着像卡死。我的建议是：eNSP里先用1024位，安全性对实验环境完全够用，生成速度快很多，等真正上生产设备再用2048。输入1024回车，看到RSA keys generated successfully才算成。

生成完可以用下面这条验证：

display rsa local-key-pair public

能看到公钥的模数和一串十六进制内容，就说明密钥对存在。

在部分较新的VRP版本上，命令形式变了，需要指定标签，比如rsa local-key-pair create label host之类，具体敲rsa local-key-pair create ?让设备告诉你。这个差异后面第5节会单独列表说明。

踩过的坑：有人敲rsa local-key-pair create之后报Error: Failed to create the RSA key pair。这个报错在eNSP里通常不是命令问题，而是设备没启动完全、虚拟化环境资源紧张，或者正好赶在VRP初始化阶段。处置办法是等设备彻底起来了再敲一次，实在不行就右键重启设备。还有一种情况是键盘大小写或者输入法问题导致长度值没被正确识别，回车后直接退出，密钥没生成，display rsa local-key-pair public是空的。

2.2 第二步：使能STelnet服务，确认22端口真的在监听

密钥有了，接下来开服务：

stelnet server enable

成功会回显Info: Succeeded in starting the STelnet server.。较新的VRP 8平台里这条命令可能是ssh server enable，两条都试一下，哪个能通就用哪个。

这一步很容易做完就以为万事大吉，其实应该再确认两件事。其一，用display ssh server status看服务状态，输出里会有SSH server status : Enabled这样的行，还有版本号、认证超时时间等。其二，确认22端口真的在监听：

display tcp status | include 22

或者直接display tcp status，找本机地址里0.0.0.0:22或者具体接口地址的22端口，状态应该是LISTEN。如果服务使能了但端口没监听，一般是密钥没生成好，或者STelnet服务使能失败而你没注意回显。

注意：stelnet server enable这条命令和RSA密钥的先后顺序，不同版本表现不一样。有的版本必须先有密钥才能使能成功，有的版本能先使能、连接时才失败。稳妥做法就是永远先建密钥、再开服务。

2.3 第三步：AAA本地用户，密码、级别、服务类型三件套

服务起来了，但设备还不认识任何一个能登录的用户。VRP里的SSH用户认证走的是AAA框架，本地用户要在AAA视图下创建。完整的一组配置是这样：

aaa local-user admin password irreversible-cipher Huawei@123 local-user admin privilege level 15 local-user admin service-type ssh quit

三行缺一不可，我们逐行看它们各自解决什么问题。

local-user admin password irreversible-cipher Huawei@123负责设密码。这里的irreversible-cipher表示密码以不可逆加密方式存储，配置文件里看不到明文。老一点的版本可能只认password cipher，新版本里cipher被替换掉了，敲?能看出来支持哪种。密码复杂度是个高频坑：V200R005之后的版本默认要求密码至少8位、包含大小写字母和数字，写成123456或者admin会直接被拒，回显Error: The password is too simple.或者提示不满足复杂度策略。eNSP上的AR镜像一般是V200R003，对复杂度要求宽松，但也别写太简单的，换设备、换镜像时容易踩坑。

local-user admin privilege level 15决定这个用户登录后是什么级别。级别0到15，15是最高。实验环境里直接给15最省事；如果要模拟分级管理，可以建两个用户分别给级别1和级别15，验证权限隔离。级别不够的典型表现是：能登录，但敲system-view提示没权限，或者很多命令看不见。

local-user admin service-type ssh是最容易漏的一行。它声明这个用户允许通过SSH方式接入。如果只写了密码和级别、没写服务类型，登录时会卡在认证阶段报Permission denied，或者提示用户不支持该服务。更隐蔽的情况是服务类型写成了telnet，那SSH直接登不上，telnet反而能进。

2.4 第四步：VTY用户界面的两行关键配置

AAA用户建好了，还得让VTY线路知道"来的SSH连接要去找AAA认证、而且只接受SSH协议"。这两行配置在user-interface vty视图下：

user-interface vty 0 4 authentication-mode aaa protocol inbound ssh quit

authentication-mode aaa把用户界面的认证方式指向AAA，这样设备才会去查刚才建的本地用户。如果这里写的还是默认的password模式，那就是另一套独立的登录密码体系，跟你建的AAA用户完全不相干，你在AAA里怎么改密码都没用。

protocol inbound ssh限定了这个用户界面允许接入的协议是SSH。这行的默认值在很多版本上其实是all，也就是SSH和Telnet都收，但由于VTY资源是共享的，如果已经有一个Telnet会话占着，或者早期配置里把inbound限死成了telnet，SSH连接就会在协议协商阶段被拒。显式写死protocol inbound ssh是最省心的做法，同时也顺手把Telnet通道关掉了，安全性更好。

还有一个容易被忽略的细节：user-interface vty 0 4里的0 4表示第0到第4号共5个VTY线路，也就是最多5个并发登录会话。实验环境够用了，但如果要模拟多用户并发，得把范围扩到vty 0 14。扩范围时记得把authentication-mode和protocol inbound重新配一遍，因为这两条是针对每个线路生效的。

2.5 第五步：ssh user 命令，服务器侧的"认证方式声明"

还有一组命令很多人第一次接触SSH配置时完全不知道它存在，就是ssh user：

ssh user admin authentication-type password ssh user admin service-type stelnet

这组命令的作用是告诉设备：对于用户admin，允许用哪种认证方式接入SSH。authentication-type password表示密码认证，也可以设成rsa、password-rsa、all等。service-type stelnet表示这个用户可以使用STelnet服务。

这组命令最坑的地方在于它的"默认行为"。某些版本上不配ssh user也能密码登录，因为默认认证方式是password；但只要你配了ssh user admin authentication-type rsa，那客户端再拿密码去登，就会一直失败，而报错信息还未必提示你是认证方式不匹配。所以在eNSP里做实验，要么不配这组命令，要么明确写清 password，别在不确定的时候乱设成 rsa。

配完这一整套，可以用下面几条命令做最终自检：

display ssh server status display ssh user-information display local-user display current-configuration | include ssh

到这里，一个标准的eNSP SSH服务端配置算是齐了。完整的一遍贴下来是这样：

system-view sysname R1 interface GigabitEthernet0/0/0 ip address 192.168.1.1 255.255.255.0 quit rsa local-key-pair create stelnet server enable aaa local-user admin password irreversible-cipher Huawei@123 local-user admin privilege level 15 local-user admin service-type ssh quit user-interface vty 0 4 authentication-mode aaa protocol inbound ssh quit ssh user admin authentication-type password ssh user admin service-type stelnet

2.6 配置之外：权限级别与ACL的隐性拦截

有一个问题值得单独拎出来说：配置都对，密码也对，但登录后立刻被踢，或者登录直接失败。这可能是ACL在拦。

VRP支持通过ssh server acl指定只允许某些源地址访问SSH服务，例如：

acl 2000 rule 5 permit source 192.168.1.100 0 quit ssh server acl 2000

这个功能本身很有用，但在eNSP做实验时特别容易翻车——你以为客户端IP是192.168.1.100，实际模拟出来的源地址可能不是，或者掩码写成了0.0.0.255而通配符没搞明白，结果把自己挡在外面。如果排查到最后怀疑是ACL问题，先用display current-configuration | include acl看看有没有相关的ssh server acl配置，有就临时undo ssh server acl排除干扰。

权限级别同样有隐性效果。如果某个用户级别只有1，登录进去后display类命令能看到一部分，但system-view直接拒绝。这不是登录失败，而是登录后无法操作，很多人会误以为是SSH配置坏了。区分方法很简单：登录提示符能出现，就说明SSH链路和认证都是通的，问题在权限。

3. 客户端算法协商失败与eNSP运行环境问题

3.1 Windows自带OpenSSH连不上，算法协商到底卡在哪

这部分是eNSP SSH登录失败里最经典、也最容易让人怀疑人生的场景。配置全对，端口也通，客户端一连就报：

Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa

或者：

no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

根因就一句话：eNSP里那套老VRP只支持ssh-rsa、diffie-hellman-group14-sha1这类老算法，而新版OpenSSH客户端把它们默认禁用了。OpenSSH 8.8以后默认不再接受ssh-rsa主机密钥，8.5以后默认不启用sha1系列KEX，而Windows 10/11自带的ssh客户端正好落在这个区间之后。两端各自都没错，就是谈不拢。

最直接的解法是在客户端命令行上放开这些算法。Windows的PowerShell或者cmd里可以这样连：

ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 -oHostKeyAlgorithms=+ssh-rsa -oPubkeyAcceptedKeyTypes=+ssh-rsa admin@192.168.1.1

参数里的+表示"在默认算法列表基础上追加"，不是覆盖，这样既保证兼容eNSP，又不会把客户端的安全性整体降级。根据设备实际报的offer，可能需要追加的项还不止一个，常见的还有：

ssh -oKexAlgorithms=+diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 \ -oHostKeyAlgorithms=+ssh-rsa \ -oCiphers=+aes128-cbc,3des-cbc \ -oMACs=+hmac-sha1 \ admin@192.168.1.1

每次手敲这一长串肯定受不了。更好的做法是把它写进客户端的SSH配置文件。Windows上的路径是C:\Users\你的用户名\.ssh\config，Linux和macOS是~/.ssh/config，内容这样写：

Host ensp-r1 HostName 192.168.1.1 User admin KexAlgorithms +diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 HostKeyAlgorithms +ssh-rsa PubkeyAcceptedKeyTypes +ssh-rsa Ciphers +aes128-cbc,3des-cbc MACs +hmac-sha1

配置好之后，直接ssh ensp-r1就能连，不用每次背参数。这个配置文件是按Host块匹配的，可以给每台eNSP设备都写一段，互不干扰。

提示：不同OpenSSH版本的参数名有细微差别，PubkeyAcceptedKeyTypes在较新版本里改成了PubkeyAcceptedAlgorithms。如果提示参数不认识，两个都试试。另外有些系统上写+追加也仍然失败，那是因为算法根本没编译进去，这种情况就只能换客户端。

3.2 换个客户端也许十秒钟就通了

如果你不想动命令行参数，还有个更省事的办法：换一个对老算法宽容的SSH客户端。PuTTY 在这一点上一直很友好，默认的KEX列表里就包含diffie-hellman-group14-sha1，主机密钥也接受ssh-rsa，装上直接连eNSP设备基本不会因为算法问题失败。SecureCRT 从9.0开始默认禁用了一批sh1老算法，需要在会话选项里手动勾选：

进入Session Options->Connection->SSH2->Key Exchange，把diffie-hellman-group14-sha1、diffie-hellman-group-exchange-sha1勾上；再到Host Keys里确认ssh-rsa没被排除；Encryption里确认aes128-cbc可用。三处都放开后再连，通常就通了。

Xshell 的思路类似，在会话属性的"连接 -> SSH -> 安全性"里把KEX、加密、MAC的算法列表调整为"优先使用旧算法"或手动勾选。

这里有个我个人很推荐的组合方案：日常连接eNSP用PuTTY或者配置好参数的OpenSSH，做自动化测试用脚本里的ssh命令加参数。别指望用一个刚更新的客户端不加任何设置就能连上V200R003的老VRP，那不现实。

3.3 eNSP设备起不来，自然也就没有SSH可连

有一类"SSH登录失败"根本不是SSH的问题，而是eNSP设备压根没跑起来。表现是：拓扑搭好了，点启动，设备图标迟迟不变绿，或者干脆弹出"启动设备AR1失败 错误代码40"这种提示。设备没起来，22端口当然不存在，客户端只会报连接超时。

这类问题的常见成因有这么几个。一是虚拟化平台的兼容性冲突，eNSP依赖的虚拟化组件和系统里其他的虚拟化功能（比如某些内存完整性保护、虚拟机监控程序平台）会打架，导致设备起不来。处置办法是检查系统中与虚拟化相关的功能开关，把冲突项关掉再重启。这个坑在近几年的Windows版本上出现频率明显变高。

二是虚拟化平台版本与eNSP不匹配。eNSP对底层虚拟化平台的版本有过明确要求，装了太新的版本反而起不来设备。查一下自己装的是哪个版本，必要时换成eNSP文档里推荐的那一版。

三是资源不够。同时启动七八台设备，内存不够的时候后面的设备就会启动失败，或者启动了但VRP初始化不完全。实验拓扑别铺太大，需要多设备的时候分批启动。

四是启动顺序和等待时间。点完启动按钮就去点设备控制台，经常只能看到一半的启动日志。耐心等图标全绿，或者等控制台里出现可用的提示符之后再操作。

还有一个链路层的坑来自桥接。如果你用了"云"设备把eNSP里的设备桥接到本机或者物理网络，云设备上绑定的网卡选错了、网卡被禁用、IP地址冲突，都会导致客户端ping不通eNSP设备。验证方法很朴素：先在eNSP设备上用display ip interface brief确认接口up、有IP，再从客户端ping一次，不通就先解决链路，别管SSH。

4. 报错对照表与逐层排查实录

4.1 常见报错速查表

下面这张表是我这些年攒下来的，左边是客户端原文报错，中间是根因，右边是处置动作。遇到失败先在这张表里对一遍，多数情况能直接锁定方向。

4.2 一套可复用的逐层验证命令清单

我把排查过程固化成了一段固定的检查顺序，每次遇到SSH失败就按这个走，省得乱试。第一步在服务端设备上执行：

display ip interface brief display ssh server status display tcp status | include 22 display rsa local-key-pair public display local-user display current-configuration | include ssh

这六条分别回答：接口有没有IP、SSH服务是否使能、22端口是否监听、密钥是否存在、用户和权限是否齐全、有没有残留的SSH相关配置在捣乱。第二步在客户端执行：先ping目标地址，确认链路；再用带算法参数的ssh -v连接，-v会打印详细的协商日志，能看到卡在KEX、主机密钥还是认证阶段：

ssh -v -oHostKeyAlgorithms=+ssh-rsa -oKexAlgorithms=+diffie-hellman-group14-sha1 admin@192.168.1.1

日志里如果出现debug1: kex: algorithm: ...，说明KEX谈成了；出现Authentications that can continue: password，说明算法阶段全过了，问题在密码或用户；直接停在no matching ...，那就还是算法列表的事。-v这个参数是排查SSH问题的核心工具，比盯着客户端的弹窗猜有用得多。

4.3 三个真实案例的复盘

案例一：配置全对，客户端报no matching host key type found。设备是eNSP里的AR路由器，V200R003镜像，服务端配置反复检查无误，用PuTTY能连上，用Windows自带ssh就连不上。结论很清楚：服务端没问题，是客户端算法的事。在Windows的.ssh\config里加了一行HostKeyAlgorithms +ssh-rsa，问题消失。这个案例的价值在于提醒人们：用PuTTY能通不等于配置没问题，反过来也一样，客户端差异是真实存在的变量。

案例二：密码明明设对了，一直Permission denied。排查过程是先在设备上display local-user，发现用户建了、密码设了、级别也给了15，但service-type那一栏是空的。补上local-user admin service-type ssh后立刻能登。这个坑的隐蔽性在于，很多教程在讲AAA配置时会把服务类型这一行带过去，读者抄配置时漏掉，结果密码怎么改都不对。

案例三：SSH服务使能成功，但22端口始终不监听。在设备上敲stelnet server enable回显成功，display ssh server status也显示Enabled，但客户端一直Connection refused。后来用display tcp status发现根本没有22端口，再查display rsa local-key-pair public，输出为空——密钥压根没生成成功，之前那次rsa local-key-pair create因为设备刚启动完、资源紧张报了个错，被忽略了。重新生成密钥、把服务关掉再开一次，端口就监听上了。这个案例说明一件事：服务使能成功不代表服务真的可用，端口监听状态才是硬证据。

5. 进阶：设备做SSH客户端、多用户与版本差异

5.1 让eNSP里的设备当SSH客户端去登录另一台设备

大部分实验里我们是拿Windows或者PuTTY去连eNSP设备，但在综合实验里经常需要让一台eNSP设备主动SSH到另一台，模拟远程管理。VRP设备做SSH客户端的用法是这样的：

system-view ssh client first-time enable stelnet 192.168.1.2

ssh client first-time enable是必须的一步，它的含义是：首次登录一台陌生的SSH服务器时，自动接受对方的主机公钥而不弹确认。不开启这个功能，第一次连接会提示你确认公钥并且卡在那里，脚本和实验都会很难受。

登录时按提示输入用户名密码即可。如果要做免密登录，就要涉及公钥方式：在客户端设备上用rsa local-key-pair create生成密钥对，把公钥内容导出，粘贴到服务端设备的rsa peer-public-key配置里，再配ssh user xxx authentication-type rsa。这一套在eNSP里能做，但调试成本比密码方式高得多，实验环境里我一般推荐先用密码方式把链路跑通，再考虑公钥。

设备作客户端时还有个常见坑：客户端设备本身也必须先有RSA密钥对，因为SSH客户端也需要自己的密钥参与协商。很多人只记得服务端要生成密钥，忘了客户端也要，结果stelnet命令直接报错。

5.2 多用户、多级别与并发登录

做综合实验时，往往需要模拟不同权限的运维人员。做法是在AAA视图下建多个本地用户，分别给不同级别：

aaa local-user ops password irreversible-cipher Ops@12345 local-user ops privilege level 1 local-user ops service-type ssh local-user admin password irreversible-cipher Admin@12345 local-user admin privilege level 15 local-user admin service-type ssh quit

级别1的用户登录后只能看部分状态信息，级别15的用户可以进系统视图改配置。这个设计在做权限管理类实验时很有用。

并发登录方面，user-interface vty 0 4只支持5个会话，如果同时有多个客户端连进来，第六个就会连接失败或者被排队。把范围改成vty 0 14可以支持15个。改的时候记得重新配认证方式和协议限制，因为新增的VTY线路如果没配protocol inbound ssh，默认行为可能和已有的不一致。

另外VRP支持在VTY下配idle-timeout控制空闲超时，默认一般是10分钟。做长时间实验时如果被踢下线，可以把它调长：

user-interface vty 0 4 idle-timeout 30 0

5.3 不同VRP版本的SSH命令差异对照

eNSP里换一个设备型号、换一个镜像版本，SSH相关命令就可能不一样。下面这些差异我实际遇到过，列出来方便对照：

如果你的设备上敲某条命令提示不认识，第一时间敲?看补全，或者display version确认VRP版本。不同版本之间并没有一个"统一写法"，硬抄网上的配置容易在版本差异上翻车。

关于算法调优，较新版本的VRP允许在服务端侧放开某些老算法，比如通过ssh server key-exchange指定可用的密钥交换算法。设备侧放开之后，客户端就不用加那一长串参数了。但这条命令的支持范围和参数取值各版本差异很大，实际操作时要靠?一步步确认。

有个小技巧分享：如果你在eNSP里同时做多个实验，把服务端的那一整套SSH配置写成一个文本文件放在桌面，用的时候直接复制粘贴到命令行，比每次手敲快得多。粘贴时注意eNSP的命令行窗口有粘贴速率限制，粘太快可能丢字符，一条一条粘或者放慢节奏更稳。粘完之后用display current-configuration | include ssh核对一遍，确认每一条都进去了，这一步能挡掉不少"我明明配了"的乌龙。