机房在三楼核心交换机在弱电井的最里头改一条 VLAN 就得跑一趟——这种日子里把华三交换机的 SSH 远程登陆配好省下的不只是腿脚。SSHSecure Shell在交换机上的角色很直白把原本明文传输的 Telnet 会话塞进加密隧道让账号密码和每一条配置命令都不再在链路上裸奔。这篇内容就围绕华三H3C交换机的 SSH 配置展开从 Comware V5 与 V7 的命令差异到服务端如何一步步落地、客户端怎么连、连不上时怎么排查再到上线之后的加固与日志留痕都会给出可以直接抄的完整命令以及我在真实设备上踩过的坑。不管你是刚接手一台二手 S5130 的新人还是手里攒着一堆老 V5 设备的运维老手都能从里面挑到能用的部分。1. Telnet 换 SSH 这件事在华三交换机上到底改变了什么很多现场的华三交换机出厂状态其实是很开放的VTY 线路允许所有协议接入认证方式配了 scheme 或干脆是 password只要知道管理地址随便一台电脑打开终端工具敲几条命令就能进。用的人觉得很方便问题在于 Telnet 的整个会话是明文的——用户名、密码、你敲的每一条local-user配置全都原样躺在数据包里。在同一广播域里挂一台抓包机几分钟就能把这些东西完整还原出来。SSH 做的事就是把这层窗户纸糊上。它在 TCP 之上先做一次密钥协商双方算出一组对称密钥用于后续通信同时用主机密钥完成服务端身份校验。传过去的密码是加密的命令回显是加密的连数据完整性都有校验中间人篡改会被发现。对于管理面来说这意味着即使有人在链路上监听他能拿到的也只有一堆加密流量和连接元数据。但有一点必须说清楚SSH 只保护会话管道不负责谁能进这个门。它不会自动帮你做源地址限制不会自动帮你设置密码复杂度也不会自动回收离职人员的账号。交换机本身支持ssh server acl、password-control、用户角色这些机制但都得你主动配上去。我见过不少设备只做了ssh server enable就以为万事大吉结果管理网段里随便一台机器都能尝试爆破这就有点自欺欺人了。对比项TelnetSSH传输加密无全部明文全程加密含密码与回显数据完整性无校验有 MAC 校验防篡改服务端身份验证无主机密钥RSA/ECDSA 等客户端兼容性几乎所有终端工具都支持新客户端对老设备算法支持需要手动放开设备侧开销极低建连时有一次密钥协商之后开销很小默认端口2322设备侧的性能开销这一点可以放心。SSH 建连时会做密钥交换和一次 RSA 运算登录完成之后的加解密量对交换机 CPU 来说基本可以忽略管理面流量本来就只有几十 KB 级别。真正需要注意的是密钥生成那一步老设备上生成 2048 位 RSA 密钥可能要卡十几秒甚至更久屏幕看着像死机别急着断电。2. 动手之前先搞清楚是 V5 还是 V7命令体系差得挺远华三交换机的 SSH 配置最坑的地方不在 SSH 本身而在 Comware 版本。同样是创建一个能登录的本地用户V5 和 V7 的命令长得完全不一样抄错了就会一直认证失败报错信息还特别含糊。所以进设备第一件事永远是先敲display version。H3C display version H3C Comware Software, Version 7.1.070, Release 6521P02 ...看到Version 7.1.xxx就是 V7 体系看到Version 5.20 Release xxxx就是 V5 体系。两者在 SSH 这块的核心差异集中在下面几处。2.1 权限模型V5 的 level 与 V7 的 user-roleV5 沿用老式的分级权限用户有个level 0~3的属性3 是最高等同管理员。V7 换成了 RBAC 角色模型常见的是network-admin读写和network-operator只读另外还有level-0到level-15这类兼容角色。这个差异直接体现在命令上# Comware V5 [H3C-luser-netadmin] level 3 # Comware V7 [SW-Core-luser-manage-netadmin] authorization-attribute user-role network-admin在 V7 上我曾经漏配user-role用户能认证成功、能登进去但进去之后只有只读权限system-view敲下去直接报错。当时第一反应是密码或 service-type 有问题翻来覆去找了半天最后display local-user一看角色是默认的network-operator。这个坑很典型。2.2 本地用户的创建方式V7 多了一个 classV7 里创建本地用户时官方推荐带上class关键字[SW-Core] local-user netadmin class managemanage类是给管理类用户用的SSH、Telnet、Web、SNMPv3 这些network类是给接入认证类用户用的比如 802.1X、Portal、MAC 认证。SSH 登录走的是管理类如果建用户时不小心建成了network类表现就是密码怎么敲都认证不过去日志里也看不出什么明显线索V5 没有这个概念local-user xxx直接进配置视图就行。2.3 VTY 线路数量与 inbound 协议V5 交换机的 VTY 一般是user-interface vty 0 4也就是 5 条并发会话V7 常见是line vty 0 63。数量本身不影响 SSH 能不能用但并发会话被打满时就会出现密码输对了也登不进去、连接立刻被断的现象排查时容易误判。protocol inbound这条命令两代都有作用是限定这条 VTY 线路接受哪种协议接入。配置 SSH 的时候通常写成protocol inbound ssh。这里有个操作顺序上的小陷阱这条命令一敲下去已经在线的 Telnet 会话会立刻断掉。如果你当时正是通过 Telnet 在配设备恭喜你会当场失联只能抱着笔记本去插 Console 线。稳妥的做法是先确认 Console 口能进、或者干脆用 Console 配这一条。配置项Comware V5 写法Comware V7 写法创建本地用户local-user netadminlocal-user netadmin class manage权限属性level 3authorization-attribute user-role network-adminVTY 范围user-interface vty 0 4line vty 0 63密码存储password cipher xxx/password simple xxxpassword hash/password simple xxx主机密钥public-key local create rsa/dsapublic-key local create rsa/ecdsaSSH1 兼容ssh server compatible-ssh1x enable无此命令3. Comware V7 交换机 SSH 服务端配置的完整落地过程下面这套流程我在 S5130、S5560、S6520 这些常见型号上都跑通过顺序是刻意排的照着走基本不会出岔子。假设设备管理地址规划为10.10.10.1/24管理网段是10.10.10.0/24SSH 账号用netadmin。3.1 先生成主机密钥再开启 SSH 服务主机密钥是 SSH 服务端的身份证客户端第一次连接时看到的那个指纹就是它。V7 上这台设备必须有自己的密钥对否则服务开不起来或者连接协商直接失败。顺序上建议先生成密钥再ssh server enable因为在部分版本上如果先开服务、后生成密钥服务是起来了但连接会报密钥相关的错误反而让人误以为是别的问题。H3C system-view [H3C] sysname SW-Core [SW-Core] public-key local create rsa The range of public key modulus is (512 ~ 2048). If the key modulus is greater than 512, it will take a few minutes. Press CTRLC to abort. Input the modulus length [default 1024]: 2048 Generating Keys... .................... Create the key pair successfully.这一步有几个经验点值得单独拎出来。第一模长直接给 2048。默认 1024 在老版本客户端上兼容性更好但强度偏低现在没必要为这点兼容性让步——真要兼容极老的客户端问题也不在模长上而在密钥交换算法上后面第 5 节会讲怎么处理。第二生成过程会卡住尤其是 2048 位。屏幕没有任何输出滚动是正常现象耐心等十几秒到一分钟。我见过有人以为设备死了直接拔电结果 flash 里的配置写了一半重启后进不去系统得走 BootWare 恢复非常麻烦。第三如果这台设备之前生成过密钥再敲一次会提示已存在。要重新生成得先public-key local destroy rsa但注意换密钥之后所有客户端第一次连接都会提示主机指纹变了需要人工确认。生产设备上不要随便干这件事除非你有明确的轮换策略。密钥就绪之后开启 SSH 服务[SW-Core] ssh server enable顺手可以确认一下状态[SW-Core] display ssh server status SSH server: Enable SSH version: 2.0 SSH authentication-timeout: 60 second(s) SSH server key generating interval: 0 hour(s) SSH authentication retries: 3 time(s) SSH server keepalive interval: 0 second(s) SSH server rekey interval: 0 second(s) SSH server port: 22 SSH server IPv4 ACL: Not configured SSH server IPv6 ACL: Not configured这里SSH version: 2.0说明只支持 SSH2这是 V7 的正常状态。authentication retries是认证失败重试次数默认 3 次可以让爆破成本高一点一般不用改。SSH server ACL: Not configured这行先记住第 7 节会回来把它填上。3.2 本地用户、service-type 与用户角色三样缺一不可这是最容易出问题的一步。一个能通过 SSH 登录的本地用户必须同时满足三个条件密码存在、service-type里包含ssh、用户角色有足够的权限。缺任何一个表现都是认证失败或权限不足。[SW-Core] local-user netadmin class manage [SW-Core-luser-manage-netadmin] password hash Password: Confirm : [SW-Core-luser-manage-netadmin] service-type ssh [SW-Core-luser-manage-netadmin] authorization-attribute user-role network-admin [SW-Core-luser-manage-netadmin] quit密码这里用password hash而不是password simple。前者输入后配置文件里看到的是一串$h$6$开头的哈希值后者在display current-configuration里是明文可见的。有人会说配置文件本来就有权限控制怕什么但配置文件经常会被导出备份、发给厂家做技术支持、贴到工单系统里明文密码泄露的面比想象中大得多。能哈希就哈希这是习惯问题。service-type ssh这一行也值得强调。V7 里这个属性是可以配多个的service-type ssh telnet terminal如果你是从老配置继承过来的用户很可能只配了telnet那 SSH 认证就会被拒。display local-user能直接看到[SW-Core] display local-user Total 1 local users matched. Username: netadmin State: Active Service type: SSH User role list: network-admin ...看到Service type: SSH和User role list: network-admin这两行对上了用户这块才算配完。3.3 VTY 线路把入口从 Telnet 收窄到 SSHVTY 是设备的远程登录入口集合SSH 和 Telnet 都从这里进。要只留 SSH就在 VTY 视图下改认证方式和接入协议。[SW-Core] line vty 0 63 [SW-Core-line-vty0-63] authentication-mode scheme [SW-Core-line-vty0-63] protocol inbound ssh [SW-Core-line-vty0-63] idle-timeout 10 0 [SW-Core-line-vty0-63] quitauthentication-mode scheme表示走 AAA 认证也就是用刚才建的本地用户来验证。如果这里是none任何人连上就能进如果是password用的是 VTY 自己的密码跟本地用户无关两套东西容易混。统一用scheme最省心。idle-timeout 10 0是空闲 10 分钟自动断开。这个值不宜太长运维人员用笔记本连上设备、接了个电话就忘了退出会话一直挂着占用 VTY 资源也不宜太短配置到一半去翻文档回来发现断了前面的命令白敲。10 到 15 分钟是比较舒服的区间。注意protocol inbound ssh敲下回车的那一刻当前所有建立在 Telnet 上的会话会立即断开。如果你正在用 Telnet 配这条命令请先确认 Console 口可用或者改用protocol inbound all先过渡等 SSH 验证通过后再收紧。3.4 管理地址怎么给三层接口与管理口的选择SSH 要能连上设备得有一个可达的 IP。华三交换机上有两种常见做法。一种是给管理 VLAN 配三层接口这是生产环境最常用的[SW-Core] vlan 100 [SW-Core-vlan100] description MGMT [SW-Core-vlan100] quit [SW-Core] interface Vlan-interface 100 [SW-Core-Vlan-interface100] ip address 10.10.10.1 255.255.255.0 [SW-Core-Vlan-interface100] quit然后把上行口划进 VLAN 100interface GigabitEthernet1/0/24下配port link-type access和port access vlan 100。管理 VLAN 单独划出来不要和业务 VLAN 混用这样后续用 ACL 限制 SSH 源地址时会清爽很多。另一种是用设备自带的带外管理口M-GigabitEthernet0/0/0很多型号出厂默认就是192.168.0.1/24插根网线到管理网就能进不占用业务端口也不受业务 VLAN 变动影响[SW-Core] interface M-GigabitEthernet0/0/0 [SW-Core-M-GigabitEthernet0/0/0] ip address 10.10.99.1 255.255.255.0 [SW-Core-M-GigabitEthernet0/0/0] quit我的习惯是两者都配带外管理口接独立的带外网日常运维走带外带内管理 VLAN 作为备份路径。这样即使业务网出了环路或者 STP 抖动带外这条线还能把设备救回来。配完地址先在本机验证[SW-Core] display ip interface brief [SW-Core] ping -c 4 10.10.10.100从管理网的一台 PC 上 ping 通设备地址再往下做 SSH 连接测试才有意义。顺序反了的话连不上时你分不清是网络问题还是 SSH 配置问题。3.5 一份可以直接照抄的 V7 完整配置清单把前面的片段串起来从 Console 进去到 SSH 可用整套命令如下H3C system-view [H3C] sysname SW-Core # 1. 主机密钥 [SW-Core] public-key local create rsa # 提示输入模长时填 2048等待生成完成 # 2. 开启 SSH 服务 [SW-Core] ssh server enable # 3. 管理地址按实际规划替换 [SW-Core] vlan 100 [SW-Core-vlan100] description MGMT [SW-Core-vlan100] quit [SW-Core] interface Vlan-interface 100 [SW-Core-Vlan-interface100] ip address 10.10.10.1 255.255.255.0 [SW-Core-Vlan-interface100] quit # 4. 本地用户 [SW-Core] local-user netadmin class manage [SW-Core-luser-manage-netadmin] password hash [SW-Core-luser-manage-netadmin] service-type ssh [SW-Core-luser-manage-netadmin] authorization-attribute user-role network-admin [SW-Core-luser-manage-netadmin] quit # 5. VTY 线路 [SW-Core] line vty 0 63 [SW-Core-line-vty0-63] authentication-mode scheme [SW-Core-line-vty0-63] protocol inbound ssh [SW-Core-line-vty0-63] idle-timeout 10 0 [SW-Core-line-vty0-63] quit # 6. 保存 [SW-Core] save force保存这一步别偷懒用save然后一路回车用save force直接落盘不交互配置多的时候能省不少时间。另外改完管理面配置后一定要先保留一个已登录的会话不要退出用它做验证确认新开的 SSH 连接能进去之后再关。4. Comware V5 老设备上的适配写法手上还有一批 S5120、S5500 这类跑 V5 的设备配 SSH 的思路一样但细节得改。最典型的差异是权限属性和 VTY 范围。H3C system-view [H3C] public-key local create rsa [H3C] public-key local create dsa [H3C] ssh server enable [H3C] local-user netadmin [H3C-luser-netadmin] password cipher H3c2024#Ops [H3C-luser-netadmin] service-type ssh [H3C-luser-netadmin] level 3 [H3C-luser-netadmin] quit [H3C] user-interface vty 0 4 [H3C-ui-vty0-4] authentication-mode scheme [H3C-ui-vty0-4] protocol inbound ssh [H3C-ui-vty0-4] user privilege level 3 [H3C-ui-vty0-4] quitV5 上我建议多生成一个 DSA 密钥。有些非常老的客户端工具在协商时只认 DSA 或 RSA 其中一种多备一份能少很多莫名其妙的协商失败。V5 支持ssh server compatible-ssh1x enable来兼容 SSH1 客户端但除非万不得已不要开SSH1 本身就有已知的设计缺陷开了等于把门重新推开一半。还有一个 V5 特有的命令值得知道[H3C] ssh server authentication-type default password-publickey这条命令决定服务端默认允许的认证方式组合。默认值在不同版本上不完全一致如果遇到密码明明没错但一直认证失败的情况可以查一下这个配置。V5 的display ssh server status输出里能看到当前值。V5 和 V7 混用的环境里我一般会准备两份配置模板分别存放改设备的时候先display version确认版本再从对应模板里拷命令。凭记忆混着敲是自找麻烦两边命令长得像但关键字不同敲错了设备不一定报错可能只是静默不生效排查起来非常费时间。5. 客户端这一侧的连接姿势命令行、图形工具与批量脚本服务端配完只是做了一半很多时候连不上其实是客户端的问题尤其是在用最新版操作系统的环境下。5.1 OpenSSH 客户端与老设备算法协商Linux、macOS 以及 Windows 10 以后自带的 OpenSSH 客户端直接一条命令就能连ssh netadmin10.10.10.1首次连接会弹出一段主机指纹确认信息形如The authenticity of host 10.10.10.1 (10.10.10.1) cant be established. RSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxx. Are you sure you want to continue connecting (yes/no/[fingerprint])?输入yes之后指纹会被写进~/.ssh/known_hosts后续不再提示。如果设备重装过、密钥重新生成过客户端会拒绝连接并提示REMOTE HOST IDENTIFICATION HAS CHANGED这时候要么删掉 known_hosts 里对应的那一行要么用ssh-keygen -R 10.10.10.1清掉。真正常见的报错是这个Unable to negotiate with 10.10.10.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1原因很直接新版本 OpenSSH 出于安全考虑默认关掉了一批老旧算法diffie-hellman-group1-sha1、ssh-rsa签名、aes128-cbc等而老华三设备只提供这些。解决办法是在客户端显式放开ssh -oKexAlgorithmsdiffie-hellman-group14-sha1 \ -oHostKeyAlgorithmsssh-rsa \ -oPubkeyAcceptedAlgorithmsssh-rsa \ -oCiphersaes128-cbc \ netadmin10.10.10.1这里有个版本差异要留意OpenSSH 8.5 之后PubkeyAcceptedKeyTypes改名为PubkeyAcceptedAlgorithms用旧名字会提示未知选项。如果你的客户端版本比较新就用上面这个写法老版本客户端则反过来。每次都敲这么一长串显然不现实写进~/.ssh/config最省事Host sw-core HostName 10.10.10.1 User netadmin KexAlgorithms diffie-hellman-group14-sha1 HostKeyAlgorithms ssh-rsa PubkeyAcceptedAlgorithms ssh-rsa Ciphers aes128-cbc ServerAliveInterval 60 ServerAliveCountMax 3之后只需要ssh sw-core四个字符就能连上。ServerAliveInterval那两行是防呆用的某些中间设备会静默回收长时间空闲的连接加上心跳能避免配到一半突然掉线。5.2 图形化终端工具怎么选Windows 上做网络运维图形化工具还是主流。几类常见选择PuTTY体积小纯绿色支持保存会话。缺点是对多标签、批量操作支持弱界面也比较朴素。MobaXterm / Xshell / SecureCRT多标签、会话管理、日志自动记录、脚本录制适合同时管几十台设备的人。SecureCRT 的日志自动按日期分文件、按会话名命名这个功能做审计留痕时非常有用。VSCode Remote-SSH严格说不是为网络设备设计的连交换机只能进交互式 shell没法用它做文件同步用来看看设备状态可以日常配置不如专用终端工具顺手。选图形工具时我会特别关注三个点一是能不能保存会话并批量打开一次点开三十台设备的标签页巡检效率完全不一样二是日志能不能自动落盘出故障回溯时聊天记录和截图都不如一份带时间戳的终端日志可靠三是支不支持发送脚本文件把一串命令存成文本一次性喂进去比在窗口里贴命令稳定得多。用图形工具贴命令时有个容易忽略的坑部分工具会自动把换行转成回车、或者在每行末尾多补一个字符导致交换机收到半条命令。表现是% Unrecognized command found at ^ position.这种报错看着像命令拼错了其实是工具在捣鬼。遇到莫名其妙的语法错误先检查终端设置里的换行模式CR / LF / CRLF 三种都试一下。5.3 批量登录与自动巡检设备超过二十台的时候一台台点开看就是在浪费生命。用 Python 的 paramiko 写个巡检脚本二十分钟能搞定的事压缩到两分钟。import paramiko import time DEVICES [ {host: 10.10.10.1, user: netadmin, passwd: H3c2024#Ops}, {host: 10.10.10.2, user: netadmin, passwd: H3c2024#Ops}, ] CMDS [ screen-length disable, display version, display device, display cpu-usage, display memory, ] for dev in DEVICES: try: cli paramiko.SSHClient() cli.set_missing_host_key_policy(paramiko.AutoAddPolicy()) cli.connect( dev[host], usernamedev[user], passworddev[passwd], look_for_keysFalse, allow_agentFalse, timeout10, ) shell cli.invoke_shell() time.sleep(1) shell.recv(65535) for cmd in CMDS: shell.send(cmd \n) time.sleep(1.5) print(f {dev[host]} : {cmd} ) print(shell.recv(65535).decode(utf-8, errorsignore)) cli.close() except Exception as e: print(f{dev[host]} connect failed: {e})这段脚本有两个关键细节都是踩过坑才补上的。第一screen-length disable必须放在命令列表最前面。华三设备默认分屏显示输出超过一屏会停在---- More ----等按键脚本在这里就卡死了recv一直等不到新数据最后超时退出。关掉分屏这一句能解决百分之八十的脚本卡顿。第二time.sleep的间隔要按设备性能调。核心交换机命令回显快1 秒够接入层老设备执行display device可能要好几秒间隔太短会导致后一条命令的输出混进前一条结果里解析时对不上。宁可慢一点也不要拿到错的数据。还有一点paramiko 连老设备时可能遇到和 OpenSSH 一样的老算法问题。较新版本的 paramiko 默认也不启用ssh-rsa签名可以在connect里加参数绕开cli.connect( dev[host], usernamedev[user], passworddev[passwd], disabled_algorithms{pubkeys: [rsa-sha2-512, rsa-sha2-256]}, look_for_keysFalse, allow_agentFalse, )这个参数在不同 paramiko 版本上行为略有差异如果加完反而连不上把这段去掉再试。6. 连不上时的排查链路按这个顺序走不会乱SSH 连不上是个特别笼统的说法底下至少有七八种完全不同的原因。我的习惯是从外往里、从下往上逐层收口每验证一步就缩小一次范围不要一上来就怀疑账号密码。第一步确认 IP 可达。在管理网 PC 上ping 10.10.10.1。不通的话压根还没到 SSH 这一层去查接口状态display ip interface brief、VLAN 划分、上行链路、中间是否有防火墙策略。这一步不通就别往下折腾了。第二步确认 22 端口在监听。display ssh server status看 SSH server 是不是 Enabledisplay tcp status里找*:22那条记录状态是不是Listening。如果服务没开端口不会监听客户端表现通常是Connection refused。第三步确认没有被 ACL 拦。如果之前配过ssh server acl源地址不在白名单里会被直接丢弃客户端表现是连接超时而不是拒绝。超时和拒绝的区别很关键拒绝说明包到了设备但服务没接超时说明包可能根本没到、或者被静默丢弃。查display acl 2000看规则或者临时undo ssh server acl验证一下是不是 ACL 的锅。第四步看认证环节。如果能看到密码提示、输入之后报Permission denied说明网络和服务都正常问题在用户配置。逐个核对用户名大小写是否一致display local-user里Service type有没有 SSHUser role list是不是有写权限的角色用户State是不是 Active被锁定的用户会显示 Locked密码是否已过期开了 password-control aging 的话第五步看会话是不是被占满。密码输对了但连上就断或者干脆连握手都完成不了用display users看当前 VTY 占用情况。如果 0 到 4 全被占着新连接进不来。这种情况下清掉闲置会话free user-interface vty x或者扩容 VTY 数量都能解决。第六步开 debug 看细节。前面都排干净了还连不上就得让设备自己说话了SW-Core terminal monitor SW-Core terminal debugging SW-Core debugging ssh server all然后在客户端重试一次连接屏幕上会打出握手和认证的详细过程。排查完记得undo debugging all关掉debug 输出对设备 CPU 有压力忘了关可能把设备拖慢。客户端现象大概率原因优先验证命令Connection refusedSSH 服务未开启或端口被改display ssh server statusConnection timed out路由不通、ACL 拦截、接口 downping/display acl 2000No matching key exchange method客户端禁用了设备支持的老算法客户端加-oKexAlgorithms参数Permission denied密码错、service-type 缺 ssh、角色只读display local-user登录后立刻断开VTY 占满、idle-timeout 过短display users登录后无写权限user-role 是 network-operatordisplay local-user一直卡在密码提示无响应认证服务器不可达或 AAA 配置异常display domain default还有一条兜底路径必须提前准备好Console 口。远程登录配歪了、或者密码忘了Console 是唯一的救命通道。有些设备的 Console 设了密码如果这个密码也丢了那就得走 BootWare 恢复出厂代价很大。如果确实要让 Console 免密登录物理安全可控的前提下在对应线路下配[SW-Core] line aux 0 [SW-Core-line-aux0] authentication-mode none [SW-Core-line-aux0] quit不同型号上这条线路的名字可能是aux 0也可能是console 0敲line ?看一眼就清楚了。要注意的是Console 免密意味着任何能物理接触设备的人都能改配置机柜上锁这件事就不是可选项了。7. 上线之后才真正开始把 SSH 端口管起来、把痕迹留下来SSH 服务通了只是起点。一台对全网开放的 22 端口设备和一台只允许管理网段访问的设备安全水位完全不是一个量级。7.1 用 ACL 把 22 端口锁进管理网段思路很朴素只允许管理网段访问设备的 SSH 端口其他一律拒绝。用基本 ACL 就够了。[SW-Core] acl basic 2000 [SW-Core-acl-ipv4-basic-2000] rule 0 permit source 10.10.10.0 0.0.0.255 [SW-Core-acl-ipv4-basic-2000] rule 5 deny source any [SW-Core-acl-ipv4-basic-2000] quit [SW-Core] ssh server acl 2000规则顺序很重要。华三的 ACL 是自上而下匹配命中即停所以放行规则必须写在拒绝规则前面。我见过有人把deny any写在第一条结果自己也被挡在外面只能去插 Console。另外要清楚ACL 匹配的是源 IP防不住伪装源地址的情况它更像是一道范围限制而不是绝对防线。真要更严配合端口隔离、管理网独立物理网络、堡垒机跳转层层叠加才有意义。改完 ACL 之后立刻从管理网段和非管理网段各测一次确认前者能连、后者超时这样才算真的生效。7.2 密码策略与登录失败锁定[SW-Core] password-control enable [SW-Core] password-control length 10 [SW-Core] password-control composition type-number 3 type-length 1 [SW-Core] password-control aging 90 [SW-Core] password-control history 5 [SW-Core] password-control login-attempt 3 exceed lock-time 5这几条的含义分别是开启密码控制最小长度 10 位至少包含 3 种字符类型且每类至少 1 个90 天强制更换不能复用最近 5 次用过的密码连续 3 次登录失败锁定账号 5 分钟。最后一条要谨慎使用。lock-time 5是锁定 5 分钟如果哪天自动化巡检脚本密码配错了连续重试几次就会把管理账号锁掉而脚本可能还在不停重试把锁定时间不断刷新账号就一直处于锁死状态。开这个功能之前务必确保所有自动化脚本用的是正确的凭据并且脚本里做了失败即停的逻辑。开了password-control aging之后密码到期时用户登录会被要求立即修改。如果这批设备是通过脚本批量登录的脚本必须能处理这个交互否则会卡在改密提示上。这个坑不少人都踩过。7.3 进阶选项公钥认证与端口调整密码认证再强也怕泄露公钥认证可以彻底摆脱密码在链路上传输这个问题。V7 上的配置大致是这样[SW-Core] public-key peer netadmin-pub [SW-Core-pkey-public-netadmin-pub] public-key-code begin # 粘贴客户端 ~/.ssh/id_rsa.pub 的内容 [SW-Core-pkey-public-netadmin-pub] public-key-code end [SW-Core-pkey-public-netadmin-pub] quit [SW-Core] ssh user netadmin authentication-type publickey assign publickey netadmin-pub这样客户端持有私钥就能免密登录。要注意的是配了公钥认证之后如果还想保留密码作为备选把认证类型写成password-publickey或者同时保留本地用户密码。只留公钥认证又不小心弄丢私钥就只能拿 Console 去救了。至于改默认端口网上有不少文章推荐把 22 改成别的数字。我的看法是收益有限它挡得住无差别扫描挡不住针对性扫描而且会让所有终端工具的会话配置、ACL 规则、脚本都要跟着改增加维护成本。相比之下把源地址限制做扎实更有价值。7.4 让配置变更和登录行为都留痕设备上的操作不留痕出了问题只能靠回忆。两个动作值得做。第一是配置自动归档。V7 支持把每次保存的配置自动存一份历史版本[SW-Core] mkdir flash:/archive [SW-Core] archive configuration location flash:/archive [SW-Core] archive configuration max 20 [SW-Core] archive configuration interval 1440这样每天会自动归档一次配置出问题时能对比昨天和今天差在哪。改配置改出故障时这个功能救过我两次。第二是把日志推到日志服务器[SW-Core] info-center enable [SW-Core] info-center loghost 10.10.10.100 [SW-Core] info-center source default channel loghost log level informational登录成功、失败、配置变更这些事件都会带时间戳推过去。前提是设备时间得准所以顺手把 NTP 配上[SW-Core] clock protocol ntp [SW-Core] ntp-service enable [SW-Core] ntp-service unicast-server 10.10.10.100没有准确时间戳的日志基本没有排查价值。设备重启后时间回到 1970 年日志序列全乱事后想按时间线还原一次故障根本对不上。配置备份习惯也提一句。除了设备本地归档我还会定期把startup.cfg导到外部存储SW-Core tftp 10.10.10.100 put flash:/startup.cfg SW-Core-20240601.cfg文件名带上设备名和日期恢复的时候不用猜。设备被误操作清空配置、或者整机替换时一分钟就能回滚。8. 这些年配 SSH 踩过的几个具体的坑最后分享几个印象比较深的场景都是文档里不会写、但实际会遇到的。一个是配完立刻失联。当时在给一台接入交换机配 SSH正通过 Telnet 连着敲完protocol inbound ssh回车会话直接断了之后再怎么连都连不上。后来才反应过来那条命令把 Telnet 拒了而 SSH 的本地用户还没建完。教训是任何会改变管理面可达性的配置都要留一条已经建立的会话做后路或者干脆用 Console 配。一个是密码输对了就是进不去。排查了半个小时display local-user里Service type是空的因为从模板复制配置时漏掉了service-type ssh那一行。用户在 V7 里没配 service-type默认不含 ssh认证阶段就被拒。这种问题的麻烦之处在于客户端只报Permission denied和密码错误的表现一模一样光看客户端根本分不出来。还有一个是V5 设备上照着 V7 文档配。用了authorization-attribute user-role network-admin设备直接报错不认这条命令改成level 3才对。反过来也一样在老设备上养成的level 3习惯带到 V7 上命令能敲进去但效果不对。同一批设备里版本混杂的时候配之前先display version这个动作花五秒钟能省半小时。最后一个是密钥生成时拔了电源。一台运行中的接入交换机上执行public-key local create rsa生成 2048 位密钥屏幕卡住不动现场同事以为死机直接断电重启结果 flash 内容损坏系统起不来最后走了 BootWare 恢复流程。密钥生成过程是真的会卡耐心等别碰电源。至于练习环境如果手上没有真机华三官方的 HCL 模拟器足够跑通本文所有配置。模拟器上可以随便折腾密钥生成、ACL 拦截、VTY 占满这些场景把整个排查链路走一遍比在真机上出故障现学要划算得多。