这个问题的核心原因通常在于,通过Console口修改的local-user密码,并未与SSH应用程序的认证方式正确关联。这可能是由于SSH用户认证类型不匹配、全局密码策略干扰或堆叠配置未完全同步导致的。
下面是一套从高概率到低概率的排查流程,你可以逐步操作。
这是最可能的原因。你修改的是本地用户数据库(local-user)的密码,但SSH登录时,设备可能要求的是另一种认证方式(如公钥),从而忽略了你新设的密码。
排查步骤:
Console口登录设备,进入系统视图。
执行命令查看SSH用户的配置:display ssh user-info
观察输出信息中的 Authentication-type 字段。
解决方案:
如果显示为 publickey 或 any,说明问题就出在这里。
请执行以下命令,将认证方式强制修改为密码认证:
注意:请将 admin 替换为你实际的SSH登录用户名。
全局密码策略(如密码老化、首次登录修改密码、账户锁定等)常常是问题的根源。表面上修改成功了,但策略可能已使用户名或密码处于“待修改”或“过期”状态。
排查步骤:
在系统视图下,执行命令检查全局密码策略:display password-control
重点检查 password-control enable 是否为开启状态。
检查该用户的密码状态:display password-control user <你的用户名>。
解决方案:
方案A(简单直接):如果安全要求不高,可暂时关闭全局密码控制。
方案B(保留策略):如果需要保留全局密码策略,可在策略视图下为特定用户关闭首次登录改密限制。
在堆叠环境中,有时save force命令执行后,配置并未完全写入备用设备,或者SSH密钥在堆叠形成后出现不一致。
解决方案:
再次执行保存:为确保配置在主备设备上都生效,务必在Console口再次执行 save force。
检查并同步备机配置:可以通过命令 dir slot2#flash:/ (假设备机在slot 2)查看备机配置文件日期,或用 display current-configuration 确认关键的用户和SSH配置在主备机上完全一致。
重新生成密钥:在堆叠主设备的系统视图下,重新生成RSA密钥对。这能解决因密钥不匹配导致的SSH连接问题。
如果上述操作后问题依旧,可能需要检查更深层次的配置。
核查本地用户服务类型:确保你的SSH用户账号已开启SSH服务。
Service-type 是否包含 SSH。若没有,请在系统视图下执行:检查VTY接口配置:VTY(Virtual Type Terminal)线路配置决定了远程用户如何认证。
确认 VTY 0 4 接口下的配置为:
如果配置不符,请进入VTY视图进行修正:
检查客户端与服务端加密算法兼容性:如果客户端软件(如Xshell、SecureCRT)与交换机的SSH加密算法不匹配,也可能导致在密码正确的情况下被拒。可以在设备上执行 display ssh server status 查看支持的算法,并尝试更新客户端软件或调整客户端的加密算法设置。
账号锁定或闲置超时如果开启 password-control,账户可能因多次登录失败被锁定,或因闲置超时而失效。
检查:display aaa online-fail-record username <用户名>
解锁用户:若确认被锁定,可尝试 local-user <用户名> state active 或在AAA视图中清除失败记录 reset aaa online-fail-record username <用户名>。
检查闲置超时:display password-control,查看 Login idle time 值,若为非0,可设为0以临时禁用:password-control login idle-time 0。
ACL限制:极少数情况下,设备上配置的ACL(访问控制列表)可能会阻止来自特定IP的SSH连接-。可检查 display acl all 是否有应用到VTY线路的规则。
暂无评论
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
抄袭了我的内容
×
原文链接或出处
诽谤我
×
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论