企业官网建设流程全解析

做网络运维的人应该都有这种经历：新设备拆箱连上 console 线，敲半天命令，就为了让后续能通过 SSH 远程登录管理。可每次配 Stelnet 都容易翻车，一会儿认证失败，一会儿提示算法不匹配，一会儿连上了又发现用户权限不对。说实话，把一台华为设备配置成 Stelnet 服务器这件事本身并不复杂，但里面涉及 AAA、VTY、SSH 算法协商、主机密钥等多个环节，任何一个细节没对齐，登录就是失败。

这篇文章就拿一台常见的 VRP 设备举例，完整走一遍“设备作为 Stelnet 服务器”的配置过程。从为什么要用 Stelnet、配置前要准备什么、具体命令怎么敲，到登录验证、常见问题排查，一次性讲透。适合刚接触华为设备、被 SSH 登录折磨过的网络工程师，也适合做等保整改时需要对设备加固的运维老手。

1. Stelnet 到底解决了什么问题：从明文到加密的必然选择

1.1 为什么不能再迷信 Telnet

Telnet 作为老牌远程登录协议，在早期网络设备管理里确实是主力。但它的致命伤是全程明文传输，包括用户名和密码。打个比方，Telnet 相当于把登录口令写在明信片上寄出去，中间经过的每一个节点都能顺手抄一份。在网络环境越来越复杂的今天，用抓包工具在管理网段跑几分钟，基本就能拿到设备账号，这种风险对生产网络来说是完全不可接受的。

SSH(Secure Shell)协议的出现就是为了解决这个痛点。它通过加密通道传输所有数据，即使报文在网络上被截获，攻击者看到的也只是一堆密文。Stelnet 是华为等设备厂商对“基于 SSH 协议登录网络设备”这一功能的叫法，本质上就是把设备自己变成一个 SSH 服务器，让运维人员可以用 SSH 客户端安全地远程管理设备。

这里顺便纠正一个常见误区：Stelnet 并不是一个新协议，它依然运行在 TCP 22 端口上，底层走的是标准 SSH 协议。所以任何支持 SSH 的客户端工具，比如 PuTTY、Xshell、MobaXterm，甚至是 Windows 10/11 自带的 OpenSSH，都能直接连接配置好的 Stelnet 服务器。

1.2 SSH 带来的三重安全保障

SSH 的价值不只是一层加密，它实际上提供了三个层面的保护。第一是机密性，所有传输内容都经过加密算法处理，中途截获也读不懂；第二是完整性，每条报文都带有 HMAC 校验值，数据在传输过程中只要被篡改，接收端立刻就能发现；第三是身份认证，客户端可以通过主机密钥校准确认“正在登录的设备确实是设备本身”，而不是攻击者伪造的假设备。

这三个特性，对应到实际运维场景里意义很大。机密性保护账号密码不被偷，完整性防止报文被篡改后执行了恶意命令，身份认证则防止中间人攻击——也就是攻击者在客户端和设备之间建立伪装节点，把两条合法连接骗过来。关于身份认证这一点，很多刚接触 SSH 的人容易忽视，连接时提示“是否信任该主机密钥”就直接回车，这个习惯最好改掉。

1.3 Telnet 与 Stelnet 的直观对比

我用一张表把两者的区别列一下，方便做方案汇报或者写运维规范时直接参考：

一比较就很清楚了：Telnet 省的那点配置时间，远不够弥补安全风险带来的代价。现在很多行业的等保测评、安全检查里，明文 Telnet 往往都是明确的整改项。与其等测评机构开整改单，不如一开始就把 Stelnet 配好。

2. 配置前准备与整体方案设计

2.1 环境要求与版本确认

配置 Stelnet 之前，先确认设备硬件和软件环境满足条件。首先要确认 VRP 系统的 SSH 服务端功能可用，一般建议 VRP V200R003 及以上的版本。太老的版本虽然也能配 SSH，但算法、命令格式上和新版本差异较大，配置时容易踩坑。

第二个需要准备的是 SSH 客户端。这一步很简单：Windows 10/11 系统自带 OpenSSH，直接打开命令行就能用；如果你习惯图形化工具，PuTTY、Xshell、MobaXterm 都是不错的选择。我个人更推荐后两者，因为它们可以保存多台设备的连接配置，对管理大量设备的人来说效率高很多。

第三个是网络连通性。设备的管理地址和电脑之间必须能正常通信，建议先 ping 一下确认，不要等到 SSH 连不上时再排查网络问题。以下是一个常见的小型管理组网环境：

2.2 账号与权限规划

第二个重要的准备工作是把账号和权限规划好。很多人在配置时图省事，所有运维人员共用一个 level 15 的管理员账号，这种做法在小型网络里暂时可行，但如果团队多人同时运维，账号混用带来的安全风险和审计问题会非常头疼。

建议至少规划两个账号：一个 level 15 的管理员账号，用于日常变更和设备管理；一个 level 1 或者 level 2 的只读账号，用于日常巡检、查看配置。这样即使有人的账号被泄露，攻击者拿到的也只是只读权限，无法对设备做破坏性操作。在 AAA 配置里，每条账号对应的服务类型、权限级别都要明确写出来。

把账号规划成表格，方便归档和管理：

密码建议同时满足复杂度要求：至少 8 位以上，包含大小写字母、数字和特殊字符。如果设备支持密码策略，顺手把密码老化周期配置上，一般建议 90 天左右强制更换一次。

2.3 配置流程总览

整个配置过程可以拆成五个环节：基础网络配置、生成 RSA 主机密钥、启用 Stelnet 服务器、配置 AAA 认证和 VTY 用户界面、客户端验证。前两步是基础，中间两步是核心，最后一步是验收。建议按顺序操作，不要为了省时间跳步。

有一个细节值得注意：如果需要在设备上对 SSH 服务做访问控制，比如只允许管理网段的电脑连接，那么 ACL、源接口绑定这类限制最好在服务启用后、正式上线前配置好。避免设备已经放到机架上，才发现所有人都能尝试 SSH 登录设备，那又得返工清理。

3. 详细配置步骤：把设备“变成”Stelnet 服务器

3.1 基础网络配置与连通性验证

首先进入系统视图，修改设备名为 AR1，方便后续多设备场景下的标识区分，然后给管理接口配置 IP 地址。下面是完整的配置命令：

system-view sysname AR1 interface GigabitEthernet0/0/0 ip address 192.168.10.1 24 quit

接口配置完成后，一定不要急着往下走，先在电脑上确认两台机器能通。用命令行执行：

ping 192.168.10.1

这里有一个实操细节：如果设备接口是独享的管理口，比如不少路由器上的 MGMT 口，记得确认端口的 portswitch 属性。华为很多交换机接口默认是二层口，不能直接配置 IP，如果出现这种情况，接口下加一条undo portswitch，再配置 IP 即可。不少新手在这里卡了很久，底下一看才发现地址根本没生效。

3.2 生成 RSA 主机密钥对

SSH 服务要正常工作，设备必须有一对 RSA 主机密钥，用来证明设备身份。这个密钥就是前面说的“身份认证”环节的基础。在系统视图下执行：

rsa local-key-pair create

执行后设备一般会提示输入密钥模长，默认值是 2048，直接回车即可。如果设备支持 3072 或 4096，从安全角度考虑建议选高位，但需要注意，密钥越长，连接协商和加解密的消耗也略高，对现代设备来说差异基本感知不到。生成过程的输出大致如下：

The key name will be: Host The key modulus can be any one of the following : 2048, 3072, 4096. Key modulus [2048]: Generating keys... ....++++++++++++++ ..............................++++++++++++++

密钥生成后，可以通过下面的命令查看公钥信息：

display rsa local-key-pair public

输出内容是一大串十六进制编码，这就是设备的主机公钥。注意保存好这个输出，后面客户端首次连接时，如果提示校验主机密钥指纹，可以和这里的内容做比对。

3.3 启用 Stelnet 服务器功能

密钥生成完毕，接下来打开 Stelnet 服务器功能。在系统视图下执行：

stelnet server enable

这一步很容易漏。如果执行完 SSH 连接提示Connection refused或者No supported authentication methods，大概率就是这条命令没配。有些老版本设备还需要额外配置ssh server port 22指定监听端口，大多数情况下默认就是 22，不用特别改。

如果设备支持，还可以把 SSH 服务绑定到指定源接口，比如管理用的 Loopback 接口：

stelnet server source-interface loopback 0

这样 SSH 服务只会从 Loopback0 的地址发出响应，对于有多个 IP 的设备，能避免 SSH 暴露在非预期接口上。不过这个配置依赖 Loopback 接口存在且网络可达，需要结合实际组网决定是否使用。

3.4 配置 AAA 本地认证用户

SSH 服务已经打开，但设备还没有可用的认证用户。这一步配置 AAA 本地认证，创建刚才规划好的两个账号。进入 AAA 配置：

aaa local-user operator password irreversible-cipher Admin@2024 local-user operator service-type ssh local-user operator privilege level 15 local-user viewer password irreversible-cipher View@2024 local-user viewer service-type ssh local-user viewer privilege level 1 quit

这里重点说明几个细节。第一，irreversible-cipher是华为推荐使用的密码存储方式，密码在配置文件中以不可逆密文形式保存，即使配置文件泄露，也无法直接反推出明文密码。如果你的设备版本不支持 irreversible-cipher 而只支持 cipher，说明密码虽然也是密文存储，但安全性相对弱一些，有条件建议升级版本。

第二，service-type ssh一定不能漏。很多认证失败案例都是因为忘了指定服务类型，导致该账号虽然存在于 AAA 中，但无法用于 SSH 登录。如果这个账号将来还需要用 Web 登录设备，可以在后面追加web，比如local-user operator service-type ssh web。

第三，关于认证域的问题。华为设备在用户登录时会匹配认证域，默认使用 default 域。如果设备上配置了其他域，并且用户登录时没有带域名后缀，可能会因为匹配不到正确的域导致认证失败。遇到这种情况，可以尝试用username@domain的格式登录，比如operator@default。

3.5 配置 VTY 用户界面与登录协议

有了用户，接下来配置 VTY 用户界面，也就是远程登录的“入口”。VTY 线路决定了登录方式、认证方式和并发会话数量。执行以下配置：

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

第一条user-interface vty 0 4表示配置 0 到 4 号共 5 个虚拟终端线路，也就是同时最多支持 5 个远程登录会话。如果现场并发运维的人多，可以适当增加，比如vty 0 20，但也要注意：会话越多，暴露面越大，够用就好。

第二条authentication-mode aaa把登录认证方式指向 AAA，这样上一节创建的账号就能派上用场。如果这里写的是authentication-mode password，那 SSH 登录时会要求输入 VTY 线路密码，和 AAA 账号是另一条路线，两者不要搞混。

第三条protocol inbound ssh非常关键：它限定这条 VTY 线路只接受 SSH 连接。如果设备上同时跑了 Telnet，并且你想把两者都停掉，又或者想兼容临时需求，可以配成protocol inbound all，但生产环境不推荐这么做，明文协议能关就关。

第四条idle-timeout 15 0表示空闲 15 分钟后自动断开连接。这是很实用的安全细节，避免运维人员离开工位后，会话一直挂在设备上，被人趁虚而入。

配置完成后，建议确认一下当前 VTY 配置是否生效：

display user-interface vty 0 4

这里也可以核对一下 VTY 线路的默认权限级别。有的版本在 VTY 线路下还有user privilege level配置，如果这里设置了级别，可能覆盖 AAA 用户本身的权限，建议统一在 AAA 里管理权限级别，不要两边混着配置。

3.6 配置 SSH 用户与算法协商

在大多数主流 VRP 版本中，前面的配置已经足够支撑 SSH 登录了。但在部分版本里，还需要单独创建 SSH 用户并把认证方式指定为密码认证：

ssh user operator ssh user operator authentication-type password ssh user viewer ssh user viewer authentication-type password

配置完成后用display ssh user-list确认用户列表。如果这一步不配置，SSH 协商时可能提示认证方式不匹配。

接下来是算法协商。SSH 连接建立时，客户端和设备需要协商出一套双方都支持的密钥交换算法、加密算法和 HMAC 算法。新版本的华为设备默认算法已经比较安全，一般不需要额外调整。但如果等保测评要求必须支持高强度算法，或者客户端连不上，报no matching key exchange method之类的错误，可以针对性配置：

ssh server kex dh_group16_sha512 ssh server cipher aes256_ctr ssh server hmac hmac_sha2_256

需要提醒的是，不同版本的命令格式差异较大。有的设备把算法分成 kex、cipher、hmac 三类分别配置，有的版本又支持一次性配置多个算法用逗号或空格分隔。配置前最好用display ssh server status查看当前算法列表，再决定如何调整，避免把设备上的可用算法配没了，导致所有客户端都连不上。

3.7 客户端连接验证与指纹比对

设备侧配置完成后，从运维电脑发起 SSH 连接验证。如果电脑是 Windows 10/11，直接打开命令行：

ssh operator@192.168.10.1

第一次连接时，系统会提示确认设备主机密钥的指纹：

The authenticity of host '192.168.10.1' can't be established. RSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx. Are you sure you want to continue connecting (yes/no/[fingerprint])?

这一步一定要认真对待。建议回到设备上执行display rsa local-key-pair public，把输出的公钥信息和屏幕提示的指纹做个比对，确认没有差异后再输入 yes。确认过一次之后，客户端会把主机密钥缓存到本地，以后连接不再重复提示。

如果你用 PuTTY，操作方式类似：Host Name 填 192.168.10.1，Port 填 22，Connection type 选 SSH，然后点击 Open。首次弹出的是主机密钥缓存的确认窗口，点击 Accept 即可。

输入密码后能正常进入系统视图，就说明 Stelnet 服务器配置成功。此时可以在设备上验证在线会话：

display ssh session

正常会显示当前通过 SSH 登录的会话信息，包括用户、源地址、登录时间等。这些信息在做安全审计时非常有用。

4. 核心原理与容易踩的坑

4.1 SSH 协商过程拆解

把配置做完之后，值得花点时间理解一下 SSH 协商的过程，因为很多连接问题本质上是协商失败。

整个协商大致分三个阶段：TCP 连接建立后，客户端和服务器先交换协议版本信息，确认双方都支持 SSH 2.0；然后进入密钥交换阶段，通过类似 Diffie-Hellman 的算法协商出会话密钥，同时服务器把自己的主机密钥公钥发给客户端用于身份确认；最后是用户认证阶段，常见的密码认证方式下，客户端把用户名密码通过加密通道发送给服务器，服务器到 AAA 里验证。

理解了这三阶段，排查问题的思路就清楚了。连接直接被拒，问题大概率出在 TCP 层面或 SSH 服务没有启动；协议版本协商失败，基本是两端 SSH 版本差异太大；密钥交换报错，一般是算法列表没有交集；认证失败，则是账号、密码、服务类型或认证域的问题。

4.2 三个高频失败场景与解决思路

第一个高频场景是Connection refused。正常情况下，这说明 TCP 22 端口没有进程在监听。可能原因有几种：设备没有执行stelnet server enable；SSH 服务被 ACL 限制了；或者是源接口绑定导致地址不可达。先用display ssh server status确认服务状态，再排查 ACL 和源接口设置。

第二个高频场景是认证失败。提示Permission denied或者Authentication failed时，先确认账号密码有没有输错，再确认local-user里有没有指定service-type ssh。如果密码里用了特殊字符，还要注意终端软件会不会对字符做了转义处理，导致实际发送的密码和配置的不一致。

第三个高频场景是算法协商失败。这种错误提示通常很直接，比如：

Unable to negotiate with 192.168.10.1 port 22: no matching key exchange method found.

这种情况往往是客户端 OpenSSH 版本太新，默认禁用了一些旧算法，而设备只支持这些旧算法。临时解决办法是在 SSH 命令里手动指定算法，比如：

ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 operator@192.168.10.1

彻底解决办法是升级设备版本，或者调整设备算法配置支持更现代的算法。这种问题在老设备上比较常见，需要结合实际情况权衡。

4.3 等保合规下的安全加固姿势

Stelnet 配置完成只是第一步，如果面对的是严格的等保测评，还需要做几项安全加固。第一是限制登录源地址，避免任何人从任意地址都能尝试 SSH 登录。可以通过 ACL 实现：

acl number 2001 rule 5 permit source 192.168.10.0 0.0.0.255 rule 10 deny source any quit stelnet server acl 2001

配完 ACL 后，只有 192.168.10.0/24 网段的地址才能访问 SSH 服务。这里必须提醒一个“把自己锁在门外”的经典教训：如果管理机 IP 不在放通范围内，SSH 连接会被设备拒绝，而你又没有其他方式登录设备，那就只能跑机房接 console 线了。

第二是配置密码策略和账号安全。华为 VRP 支持密码老化时间和最小长度等策略，建议一并配置：

password expire 90 password min-length 8

第三是保留足够的审计证据。SSH 登录日志、操作日志尽量都打开，统一发送到日志服务器。日志是事后追溯的最重要依据，display ssh session只能看到当前会话，历史登录记录需要依赖日志系统。

5. 常见问题与排查技巧实录

5.1 常见故障速查表

把日常运维中高频出现的 Stelnet 连接问题整理成一张表，收藏起来，遇到问题直接对照排查：

5.2 一条命令定位问题

排查 Stelnet 相关问题时，我最常用的一条命令是display ssh server status。它能把 SSH 服务的几乎所有关键状态一次性列出来，包括服务是否启用、监听端口、算法列表、最大会话数等。

执行后如果服务状态显示为 enabled，再看端口和算法；如果服务状态显示 disabled，那问题基本就锁定在服务启用环节。配合下面的命令组合，基本能解决 80% 的连接问题：

display ssh server status display ssh user-list display user-interface vty 0 4 display aaa configuration display rsa local-key-pair public

5.3 关于客户端工具的选择建议

客户端工具的选择也会影响排查效率。Windows 自带的 OpenSSH 胜在无需额外安装，适合临时用；Xshell、MobaXterm 这类工具更适合日常批量运维，因为它们支持多标签会话、保存密码、记录操作日志，甚至在断线重连方面都比原生 OpenSSH 体验更好。

我个人的习惯是：临时变更用命令行直接连，日常巡检和批量操作放在图形化工具里。无论用哪种工具，都建议把操作日志功能打开。出了变更事故时，操作记录比记忆可靠得多。

5.4 排查实录：一次真实的算法不匹配问题

最后分享一个真实案例。某次帮客户调试一台老款交换机，客户端是新的 Windows 11 系统，连接时报错：

Unable to negotiate with 192.168.10.1 port 22: no matching key exchange method found.

报错很典型，就是算法列表没有交集。设备版本较老，只支持 diffie-hellman-group14-sha1 这类旧算法，而新版 OpenSSH 默认禁用了这些算法。当时为了快速恢复管理，用-oKexAlgorithms=+diffie-hellman-group14-sha1参数临时连接成功。后来建议客户升级设备版本，用现代算法替代旧算法，才彻底解决这个问题。

这个案例说明，Stelnet 配置文档可能没问题，但实际环境里设备和客户端的新旧差异，也会导致很多奇怪的连接问题。遇到算法相关报错时，不要急着重配设备，先确认两端的算法能力列表是否匹配，往往能更快定位问题。

5.5 一个值得保留的习惯：首次连接核对指纹

最后再分享一个我自己的习惯。每次首次连接一台新设备，看到主机密钥指纹提示时，我不会直接输 yes，而是习惯性地在设备上执行一次display rsa local-key-pair public，核对一下指纹。尤其是接手机房无人值守设备时，这一步能有效防止中间人攻击。虽然多花十秒钟，但安全感完全不同。这个习惯坚持久了，基本不会再遇到设备身份被“掉包”的问题。