在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 refusedWindows上可能是由于目标计算机积极拒绝无法连接。协商与认证关算法协商能不能谈拢、用户名密码对不对、这个用户有没有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 Huawei123 local-user admin privilege level 15 local-user admin service-type ssh quit三行缺一不可我们逐行看它们各自解决什么问题。local-user admin password irreversible-cipher Huawei123负责设密码。这里的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到1515是最高。实验环境里直接给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 quitauthentication-mode aaa把用户界面的认证方式指向AAA这样设备才会去查刚才建的本地用户。如果这里写的还是默认的password模式那就是另一套独立的登录密码体系跟你建的AAA用户完全不相干你在AAA里怎么改密码都没用。protocol inbound ssh限定了这个用户界面允许接入的协议是SSH。这行的默认值在很多版本上其实是all也就是SSH和Telnet都收但由于VTY资源是共享的如果已经有一个Telnet会话占着或者早期配置里把inbound限死成了telnetSSH连接就会在协议协商阶段被拒。显式写死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 userssh 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 Huawei123 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 stelnet2.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 -oKexAlgorithmsdiffie-hellman-group14-sha1 -oHostKeyAlgorithmsssh-rsa -oPubkeyAcceptedKeyTypesssh-rsa admin192.168.1.1参数里的表示在默认算法列表基础上追加不是覆盖这样既保证兼容eNSP又不会把客户端的安全性整体降级。根据设备实际报的offer可能需要追加的项还不止一个常见的还有ssh -oKexAlgorithmsdiffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 \ -oHostKeyAlgorithmsssh-rsa \ -oCiphersaes128-cbc,3des-cbc \ -oMACshmac-sha1 \ admin192.168.1.1每次手敲这一长串肯定受不了。更好的做法是把它写进客户端的SSH配置文件。Windows上的路径是C:\Users\你的用户名\.ssh\configLinux和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 常见报错速查表下面这张表是我这些年攒下来的左边是客户端原文报错中间是根因右边是处置动作。遇到失败先在这张表里对一遍多数情况能直接锁定方向。客户端报错信息最可能的根因处置动作Connection timed out/ 连接超时链路不通接口down或IP不对ping测试display ip interface brief检查接口Connection refused/ 目标积极拒绝22端口未监听STelnet未使能stelnet server enabledisplay tcp status看22端口no matching host key type found. Their offer: ssh-rsa客户端禁用ssh-rsa主机密钥客户端加HostKeyAlgorithmsssh-rsano matching key exchange method foundKEX算法不匹配客户端加KexAlgorithmsdiffie-hellman-group14-sha1no matching cipher found加密算法不匹配客户端加Ciphersaes128-cbcno matching MAC found完整性算法不匹配客户端加MACshmac-sha1Permission denied (password)密码错、用户未建、服务类型不对核对display local-user与密码能登录但无法system-view用户级别不足提高privilege level登录后立即断开VTY线路数占满或ACL限制扩大VTY范围检查ssh server acl服务使能报错或端口不监听RSA密钥未生成rsa local-key-pair create后重试设备图标一直不变绿eNSP运行环境问题检查虚拟化功能冲突、资源占用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 -oHostKeyAlgorithmsssh-rsa -oKexAlgorithmsdiffie-hellman-group14-sha1 admin192.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.2ssh 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 Ops12345 local-user ops privilege level 1 local-user ops service-type ssh local-user admin password irreversible-cipher Admin12345 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 05.3 不同VRP版本的SSH命令差异对照eNSP里换一个设备型号、换一个镜像版本SSH相关命令就可能不一样。下面这些差异我实际遇到过列出来方便对照功能点老版本如V200R003较新版本如V200R005及以后生成RSA密钥rsa local-key-pair create直接选位数可能需要带labelrsa local-key-pair create label host使能SSH服务stelnet server enable部分平台为ssh server enable设置密码local-user x password cipher xxxlocal-user x password irreversible-cipher xxx用户SSH服务类型local-user x service-type ssh相同但可能出现service-type ssh terminal密码复杂度基本无要求强制要求大小写字母加数字长度至少8位算法调优一般不支持服务端调优支持ssh server key-exchange等命令放开老算法如果你的设备上敲某条命令提示不认识第一时间敲?看补全或者display version确认VRP版本。不同版本之间并没有一个统一写法硬抄网上的配置容易在版本差异上翻车。关于算法调优较新版本的VRP允许在服务端侧放开某些老算法比如通过ssh server key-exchange指定可用的密钥交换算法。设备侧放开之后客户端就不用加那一长串参数了。但这条命令的支持范围和参数取值各版本差异很大实际操作时要靠?一步步确认。有个小技巧分享如果你在eNSP里同时做多个实验把服务端的那一整套SSH配置写成一个文本文件放在桌面用的时候直接复制粘贴到命令行比每次手敲快得多。粘贴时注意eNSP的命令行窗口有粘贴速率限制粘太快可能丢字符一条一条粘或者放慢节奏更稳。粘完之后用display current-configuration | include ssh核对一遍确认每一条都进去了这一步能挡掉不少我明明配了的乌龙。