1 安全类故障处理

1.1  SSH故障处理

1.1.1  SSH客户端登录设备失败

1. 故障描述

设备作为SSH服务器，用户使用SSH客户端登录设备失败。

2. 常见原因  

本类故障的常见原因主要包括：

·     SSH客户端与设备之间路由不通，无法建立TCP连接。

·     设备未开启SSH服务器功能。

·     设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

·     客户端指定的服务端口号与服务器端不一致。

·     设备上的SSH版本与客户端不兼容。

·     设备上未生成本地密钥对。

·     服务器主机密钥与设备上缓存的密钥不匹配。

·     用户线的认证方式或接入协议配置不正确。

·     设备上的本地用户视图下未配置SSH服务。

·     SSH用户的服务类型或认证方式配置不正确。

·     设备上SSH2协议使用的算法与客户端不匹配。

·     设备上VTY用户线资源不足。

·     设备上SSH登录用户数达到上限。

3. 故障分析

本类故障的诊断流程如图1-1所示。

图1-1 SSH登录失败故障诊断流程图

 

4. 处理步骤

(1)     ‍检查客户端能否Ping通设备。

使用ping命令检查网络连接情况。

¡     如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡     如果可以Ping通，请执行步骤(2)。

(2)     检查SSH服务器功能是否开启。

当设备上出现如下日志时，表示SSH服务器功能未开启。

SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

可以在设备上执行display ssh server status命令，检查Stelnet服务器功能、SFTP服务器功能、NETCONF over SSH服务器功能和SCP服务器功能是否按需开启。

<Sysname> display ssh server status

 Stelnet server: Disable

 SSH version : 2.0

 SSH authentication-timeout : 60 second(s)

 SSH server key generating interval : 0 hour(s)

 SSH authentication retries : 3 time(s)

 SFTP server: Disable

 SFTP Server Idle-Timeout: 10 minute(s)

 NETCONF server: Disable

 SCP server: Disable

¡     如果未开启，请在设备上执行如下命令，开启相关的SSH服务器功能。

<Sysname> system-view

[Sysname] ssh server enable

[Sysname] sftp server enable

[Sysname] scp server enable

[Sysname] netconf ssh server enable

¡     如果已开启，请执行步骤(3)。

(3)     检查是否设置了对客户端的访问控制。

首先检查设备上是否通过ssh server acl命令设置了对客户端的访问控制。

¡     如果已设置，请检查客户端的IP地址是否在ACL的permit规则中。

¡     当设备上出现如下日志时，表示客户端的IP地址不在ACL的permit规则中。

SSHS/5/SSH_ACL_DENY: The SSH Connection 181.1.1.10 request was denied according to ACL rules.

SSHS/5/SSH_ACL_DENY: The SSH Connection 181.1.1.11 request was denied according to ACL rules.

-     如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

-     如果在，请执行步骤(4)。

¡     如果未设置，请执行步骤(4)。

(4)     检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号，客户端仍然使用缺省端口号登录时，会出现登录失败。

以我司设备作为客户端为例，会出现如下错误提示信息：Failed to connect to host 10.1.1.1 port 100.

¡     如果客户端登录时指定的端口号与服务器端不一致，请在服务器端设备上执行display current-configuration | include ssh命令查看服务器端配置的端口号，将客户端登录时指定的端口修改为与服务器端一致。

¡     如果客户端登录时指定的端口号与服务器端一致，请执行步骤(5)。

(5)     检查服务器的SSH版本与客户端版本是否兼容。

当设备上出现如下日志时，表示设备的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在设备上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡     如果SSH version显示为1.99，则表示设备可以兼容SSH1版本的客户端，请执行步骤(6)。

¡     如果SSH version显示为2.0，请在设备上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(6)     检查服务器上是否生成了本地密钥对。

设备作为SSH服务器时，必须配置本地非对称密钥对。虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡     如果DSA、ECDSA和RSA三种密钥对都不存在，请在系统视图下执行public-key local create命令依次进行配置。

¡     如果已配置，请执行步骤(7)。

(7)     检查服务器主机密钥与客户端上缓存的服务器主机密钥对是否一致。

如果客户端首次登录服务器设备时选择保存了服务器端主机密钥，当服务器设备更新本地密钥对后，将会导致客户端认证服务端失败。

以我司设备作客户端为例，当客户端登录时，出现如下提示信息，则表示服务器主机密钥与客户端上本地缓存的密钥不一致。

The server's host key does not match the local cached key. Either the server administrator has changed the host key, or you connected to another server pretending to be this server. Please remove the local cached key, before logging in!

¡     如果不一致，请执行delete ssh client server-public-key命令，删除客户端保存的旧的服务端主机密钥。

¡     如果一致，请执行步骤(8)。

(8)     查看VTY用户线下配置的认证方式及允许接入的协议是否正确。

当客户端为Stelnet客户端和NETCONF over SSH客户端时，需要在VTY用户线视图下，执行display this命令查看配置的认证方式是否为scheme、允许接入的协议是否包含SSH。

[Sysname] line vty 0 63

[Sysname-line-vty0-63] display this

#

line vty 0 63

 authentication-mode scheme

 user-role network-admin

 idle-timeout 0 0

#

¡     如果认证方式或者接入协议配置不正确，请将认证方式修改为scheme、将允许接入的协议修改为包含SSH。

¡     如果均配置正确，请执行步骤(9)。

(9)     检查本地用户是否授权了SSH服务。（仅针对本地认证）

在本地用户视图下，执行display this命令查看用户可以使用的服务类型是否包含SSH。

[Sysname] local-user test

[Sysname-luser-manage-test] display this

#

local-user test class manage

 service-type ssh

 authorization-attribute user-role network-admin

 authorization-attribute user-role network-operator

#

¡     如果不包含，请在本地用户视图下通过service-type命令修改配置。

¡     如果包含，请执行步骤(10)。

如果为远程认证方式，请参见“AAA故障处理”进行定位。

(10)     检查是否配置了SSH用户并指定正确的服务类型和认证方式。

SSH支持Stelnet、SFTP、NETCONF和SCP四种用户服务类型。

首先，根据服务器采用的认证类型，根据如下规则，查看设备上是否创建正确的SSH用户。

¡     如果服务器采用了publickey认证，则必须在设备上创建相应的SSH用户，以及同名的本地用户（用于下发授权属性：工作目录、用户角色）。

¡     如果服务器采用了password认证，则必须在设备上创建相应的本地用户（适用于本地认证），或在远程服务器（如RADIUS服务器，适用于远程认证）上创建相应的SSH用户。这种情况下，并不需要通过本配置创建相应的SSH用户，如果创建了SSH用户，则必须保证指定了正确的服务类型以及认证方式。

¡     如果服务器采用了keyboard-interactive、password-publickey或any认证，则必须在设备上创建相应的SSH用户，以及在设备上创建同名的本地用户（适用于本地认证）或者在远程认证服务器上创建同名的SSH用户（如RADIUS服务器，适用于远程认证）。

接着，根据检查的结果，进行如下操作：

¡     如果未创建且无需创建，请执行步骤(11)；如果未创建但有需求创建，请通过ssh user命令进行配置。

¡     如果已创建，检查SSH用户的服务类型和认证方式。

-     SSH用户指定的服务类型必须与客户端类型（Stelnet客户端、SFTP客户端、SCP客户端和NETCONF over SSH客户端）相匹配，否则将会因为服务类型不匹配而登录失败。SSH用户服务类型是否正确，通过如下方式来检查：

-     以SCP客户端为例，如果设备上出现如下日志，表示服务类型不匹配。SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

-     请在设备系统视图下执行ssh user命令，修改SSH用户的服务类型。

-     请在设备上执行display ssh user-information命令，查看SSH服务器采用的认证方式，根据具体的认证方式检查设备上SSH用户的配置是否正确。

(11)     检查设备上SSH2协议使用的算法列表是否与客户端匹配。

通过display ssh2 algorithm命令查看当前SSH2协议使用的算法列表，检查客户端支持的算法是否包含在算法列表中。比如，设备上配置了不使用CBC相关的加密算法，但SSH客户端仅支持CBC相关加密算法，将导致该客户端无法登录服务器。

当设备上出现如下日志信息时，表示设备上SSH2协议使用的算法列表是否与客户端不匹配。

SSHS/6/SSHS_ALGORITHM_MISMATCH: SSH client 192.168.30.117 failed to log in because of encryption algorithm mismatch.

¡     如果客户端使用的算法与设备上的算法不匹配，可通过如下两种方式进行修改：

-     设备可以通过执行ssh2 algorithm cipher、ssh2 algorithm key-exchange、ssh2 algorithm mac或ssh2 algorithm public-key命令修改相关算法列表，增加客户端支持的算法。

-     在客户端添加服务端支持的相关算法。

¡     如果客户端使用的算法与设备上的算法能够匹配，请执行步骤(12)。

(12)     检查设备上VTY用户数是否达到允许用户数的上限。

SSH用户与Telnet用户登录均使用VTY用户线，但是VTY用户线是有限资源。若VTY类型用户线都已被占用，则后续使用Stelnet及NETCONF over SSH服务的客户端将无法登录，使用SFTP及SCP服务的客户端不占用用户线资源，不受影响，仍可登录。

当设备上出现如下日志时，表示设备上VTY用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_USER_LIMIT: SSH client 192.168.30.117 failed to log in, because the number of users reached the upper limit.

通过display line命令查看VTY用户线资源是否充足。

¡     如果VTY用户线资源不足，可将空闲且非scheme认证方式的VTY类型用户线认证方式修改为scheme认证方式；若所有VTY类型用户线都已是scheme认证方式且均处于active状态，可执行free ssh命令强制释放已建立的部分SSH连接或者执行free line vty命令强制释放VTY用户线，使得新的SSH用户能够上线。

¡     如果VTY用户线资源充足，请执行步骤(13)。

(13)     检查登录服务器的SSH用户数是否达到允许用户数的上限。

通过display ssh server session命令查看服务器的会话信息，以及查看通过aaa session-limit ssh命令配置的SSH最大用户连接数。

当设备上出现如下日志时，表示登录服务器的SSH用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The number of SSH sessions is 10, and exceeded the limit (10).

¡     如果SSH会话数已达到上限，可通过执行aaa session-limit ssh命令调大上限；如果配置的最大用户连接数已为可配置的最大值，可执行free ssh命令强制释放已建立的部分SSH连接或者在客户端下线空闲的SSH客户端，使得新的SSH用户能够上线。

¡     如果未达上限，请执行步骤(14)。

(14)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名：HH3C-SSH-MIB

·     hh3cSSHVersionNegotiationFailure (1.3.6.1.4.1.25506.2.22.1.3.0.2)

相关日志

·     SSHS/5/SSH_ACL_DENY

·     SSHS/6/SSHS_ALGORITHM_MISMATCH

·     SSHS/6/SSHS_REACH_SESSION_LIMIT

·     SSHS/6/SSHS_REACH_USER_LIMIT

·     SSHS/6/SSHS_SRV_UNAVAILABLE

·     SSHS/6/SSHS_VERSION_MISMATCH

1.1.2  设备作为SSH服务器，用户使用password认证方式登录失败

1. 故障描述

设备作为SSH服务器，用户使用密码认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

·     SSH客户端与设备之间路由不通，无法建立TCP连接。

·     SSH客户端登录密码不正确。

·     设备未开启SSH服务器功能。

·     SSH服务器上不存在该SSH登录用户。

·     设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

·     设备上SSH登录用户数达到上限。

·     设备上的SSH版本与客户端不兼容。

·     SSH用户的服务类型或认证方式配置不正确。

·     设备上未生成本地密钥对。

·     SCP/SFTP工作目录不正确。

3. 故障分析

本类故障的诊断流程如图1-2所示。

图1-2 SSH客户端使用password认证方式登录服务器失败（设备作为服务器）故障诊断流程图

 

4. 处理步骤

(1)     ‍检查客户端能否Ping通设备。

使用ping命令查看网络连接情况。

¡     如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡     如果可以Ping通，请执行步骤(2)。

(2)     检查登录密码是否正确。

a.     ‍如果服务器采用本地认证，请确认当前用户登录的密码是否与设备上设备管理类本地用户视图下配置的密码一致：

-     如果不一致，请重新输入正确的密码。若忘记密码，可以进入设备管理类本地用户视图（用户名为当前登录的用户）下，执行password命令重新配置新的密码，确保登录密码与配置的密码一致。

-     如果一致，请执行步骤1.1.1  4. (2)。

b.     如果服务器采用远程认证，请确认当前用户登录的密码是否与认证服务器上配置的一致：

-     如果不一致，请重新输入正确的密码。若忘记密码，可以在服务器上为登录用户重新设置密码，确保登录密码与认证服务器上配置的一致。

-     如果一致，请执行步骤1.1.1  4. (2)。

(3)     检查SSH服务器功能是否开启。

当设备上出现如下日志时，表示SSH服务器功能未开启。

SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

可以在设备上执行display ssh server status命令，检查Stelnet服务器功能、SFTP服务器功能、NETCONF over SSH服务器功能和SCP服务器功能是否按需开启。

<Sysname> display ssh server status

 Stelnet server: Disable

 SSH version : 2.0

 SSH authentication-timeout : 60 second(s)

 SSH server key generating interval : 0 hour(s)

 SSH authentication retries : 3 time(s)

 SFTP server: Disable

 SFTP Server Idle-Timeout: 10 minute(s)

 NETCONF server: Disable

 SCP server: Disable

¡     如果未开启，请在设备上执行如下命令，开启相关的SSH服务器功能。

<Sysname> system-view

[Sysname] ssh server enable

[Sysname] sftp server enable

[Sysname] scp server enable

[Sysname] netconf ssh server enable

¡     如果已开启，请执行步骤(4)。

(4)     检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号，客户端仍然使用缺省端口号登录时，会出现登录失败。

以我司设备作为客户端为例，会出现如下错误提示信息：Failed to connect to host 10.1.1.1 port 22.

¡     如果客户端登录时指定的端口号与服务器端不一致，请在服务器端设备上执行display current-configuration | include ssh命令查看服务器端配置的端口号，将客户端登录时指定的端口修改为与服务器端一致。

¡     如果客户端登录时指定的端口号与服务器端一致，请执行步骤(5)。

(5)     检查是否设置了对客户端的访问控制。

首先检查设备上是否通过ssh server acl命令设置了对客户端的访问控制。

¡     如果已设置，请检查客户端的配置是否在ACL的permit规则中，请先在设备上通过ssh server acl-deny-log enable命令开启匹配ACL deny规则后打印日志信息功能。

¡     当设备上出现如下日志时，表示客户端的IP地址不在ACL的permit规则中。

SSHS/5/SSH_ACL_DENY: The SSH Connection 181.1.1.10 request was denied according to ACL rules.

SSHS/5/SSH_ACL_DENY: The SSH Connection 181.1.1.11 request was denied according to ACL rules.

-     如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

-     如果在，请执行步骤1.1.1  4. (5)。

¡     如果未设置，请执行步骤1.1.1  4. (5)。

(6)     检查服务器的SSH版本与客户端版本是否兼容。

当设备上出现如下日志时，表示设备的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在设备上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡     如果SSH version显示为1.99，则表示设备可以兼容SSH1版本的客户端，请执行步骤1.1.1  4. (8)。

¡     如果SSH version显示为2.0，请在设备上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(7)     查看VTY用户线下配置的认证方式及允许接入的协议是否正确。

当客户端为Stelnet客户端或NETCONF over SSH客户端时，需要在VTY用户线视图下，执行display this命令查看配置的认证方式是否为scheme、允许接入的协议是否包含SSH。

[Sysname] line vty 0 63

[Sysname-line-vty0-63] display this

#

line vty 0 63

 authentication-mode scheme

 user-role network-admin

 idle-timeout 0 0

#

¡     如果认证方式或者接入协议配置不正确，请通过authentication-mode scheme命令将认证方式修改为scheme、通过protocol inbound ssh命令将允许接入的协议修改为包含SSH。

¡     如果均配置正确，请执行步骤1.1.1  4. (12)。

(8)     检查设备上VTY用户数是否达到允许用户数的上限。

SSH用户与Telnet用户登录均使用VTY用户线，但是VTY用户线是有限资源。若VTY类型用户线都已被占用，则后续使用Stelnet及NETCONF over SSH服务的客户端将无法登录，使用SFTP及SCP服务的客户端不占用用户线资源，不受影响，仍可登录。

当设备上出现如下日志时，表示设备上VTY用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_USER_LIMIT: SSH client 192.168.30.117 failed to log in, because the number of users reached the upper limit.

通过display line命令查看VTY用户线资源是否充足。

¡     如果VTY用户线资源不足，可将空闲且非scheme认证方式的VTY类型用户线认证方式修改为scheme认证方式；若所有VTY类型用户线都已是scheme认证方式且均处于active状态，可执行free ssh命令强制释放已建立的部分SSH连接或者执行free line vty命令强制释放VTY用户线，使得新的SSH用户能够上线。

¡     如果VTY用户线资源充足，请执行步骤(13)。

(9)     检查登录服务器的SSH用户数是否达到允许用户数的上限。

通过display ssh server session命令查看服务器的会话信息，以及查看通过aaa session-limit ssh命令配置的SSH最大用户连接数。

当设备上出现如下日志时，表示登录服务器的SSH用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The number of SSH sessions is 10, and exceeded the limit (10).

¡     如果SSH会话数已达到上限，可通过执行aaa session-limit ssh命令调大上限；如果配置的最大用户连接数已为可配置的最大值，可执行free ssh命令强制释放已建立的部分SSH连接或者在客户端下线空闲的SSH客户端，使得新的SSH用户能够上线。

¡     如果未达上限，请执行步骤(10)。

(10)     检查服务器上是否生成了本地密钥对。

为了防止“伪服务器欺骗”，客户端验证服务器身份时，首先判断服务器发送的公钥与本地保存的服务器公钥是否一致，确认服务器公钥正确后，再使用该公钥对服务器发送的数字签名进行验证。如果客户端没有保存服务器的公钥或保存的服务器公钥不正确，则服务器身份验证将会失败，从而导致客户端无法登录服务器。因此，客户端登录服务器之前，需要先在服务器端创建密钥对，并将正确的服务器公钥保存在客户端。

虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡     如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置，并确保将服务器上生成的公钥保存到客户端。

¡     如果已配置，请执行步骤1.1.1  4. (10)。

(11)     检查是否配置了SSH用户并指定正确的服务类型和认证方式。

SSH支持Stelnet、SFTP、NETCONF和SCP四种用户服务类型。

首先，根据服务器采用的认证类型，查看设备上是否创建正确的SSH用户。

由于服务器采用了password认证，必须在设备上创建相应的本地用户（适用于本地认证），或在远程服务器（如RADIUS服务器，适用于远程认证）上创建相应的SSH用户。对于采用远程认证方式的情况，不需要通过本配置创建相应的SSH用户，如果创建了SSH用户，则必须保证指定了正确的服务类型以及认证方式。

接着，根据检查的结果，进行如下操作：

¡     如果未创建且无需创建，请执行步骤(12)；如果未创建且需要创建，请通过ssh user命令进行配置。

¡     如果已创建，检查SSH用户的服务类型和认证方式。

-     请在设备上执行display ssh user-information命令，分别通过“Service-type”和“Authentication-type”字段查看SSH用户的服务类型及认证方式。其中，服务类型必须与客户端类型（Stelnet客户端、SFTP客户端、SCP客户端或NETCONF over SSH客户端）相匹配，认证方式必须为password。

-     请在设备系统视图下执行ssh user命令，将SSH用户的服务类型和认证方式修改正确。

(12)     检查SCP/SFTP工作目录配置是否正确。

当SSH用户的服务方式为SCP/SFTP时，需要为用户设置授权目录。如果所配置的授权目录不存在，SCP/SFTP客户端通过该用户连接SCP/SFTP服务器就会失败。对于password认证方式的用户，请检查通过AAA授权的工作目录是否存在。

¡     如果不存在，请通过本地用户视图下的authorization-attribute work-directory directory-name命令修改授权的工作目录。

¡     如果存在，请执行步骤(13)。

(13)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名：HH3C-SSH-MIB

·     hh3cSSHVersionNegotiationFailure (1.3.6.1.4.1.25506.2.22.1.3.0.2)

相关日志

·     SSHS/5/SSH_ACL_DENY

·     SSHS/6/SSHS_ALGORITHM_MISMATCH

·     SSHS/6/SSHS_REACH_SESSION_LIMIT

·     SSHS/6/SSHS_REACH_USER_LIMIT

·     SSHS/6/SSHS_SRV_UNAVAILABLE

·     SSHS/6/SSHS_VERSION_MISMATCH

1.1.3  设备作为SSH服务器，用户使用publickey认证方式登录失败

1. 故障描述

设备作为SSH服务器，用户使用公钥认证登录失败。

2. 常见原因

本类故障的常见原因主要包括：

·     SSH客户端与设备之间路由不通，无法建立TCP连接。

·     服务器端配置的用户公钥不正确。

·     设备未开启SSH服务器功能。

·     SSH服务器上不存在该SSH登录用户。

·     设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

·     设备上SSH登录用户数达到上限。

·     设备上的SSH版本与客户端不兼容。

·     SSH用户的服务类型或认证方式配置不正确。

·     设备上未生成本地密钥对。

·     SCP/SFTP工作目录不正确。

3. 故障分析

本类故障的诊断流程如图1-2所示。

图1-3 SSH客户端使用publickey认证方式登录服务器失败（设备作为服务器）故障诊断流程图

 

4. 处理步骤

(1)     ‍检查客户端能否Ping通设备。

使用ping命令查看网络连接情况。

¡     如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡     如果可以Ping通，请执行步骤(2)。

(2)     检查服务器端配置的用户公钥和用户使用的私钥是否匹配。

SSH客户端可能支持多种公钥算法，每种公钥算法对应不同的非对称密钥对。只有服务器端保存的用户公钥类型与用户登录时使用的私钥类型一致时，用户认证才会成功。例如，服务器端为某用户指定了DSA类型的公钥，用户也持有与之相匹配的私钥，但是登录时用户使用的私钥类型为RSA，此时用户认证会失败。通过在设备上执行display public-key peer命令查看保存在设备上的客户端公钥信息，判断是否与正在登录用户使用的私钥类型一致：

¡     如果不一致，请执行public-key local create命令在设备上生成相应类型的密钥对。

¡     如果一致，请执行步骤(3)。

(3)     检查SSH服务器功能是否开启。

当设备上出现如下日志时，表示SSH服务器功能未开启。

SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

可以在设备上执行display ssh server status命令，检查Stelnet服务器功能、SFTP服务器功能、NETCONF over SSH服务器功能和SCP服务器功能是否按需开启。

<Sysname> display ssh server status

 Stelnet server: Disable

 SSH version : 2.0

 SSH authentication-timeout : 60 second(s)

 SSH server key generating interval : 0 hour(s)

 SSH authentication retries : 3 time(s)

 SFTP server: Disable

 SFTP Server Idle-Timeout: 10 minute(s)

 NETCONF server: Disable

 SCP server: Disable

¡     如果未开启，请在设备上执行如下命令，开启相关的SSH服务器功能。

<Sysname> system-view

[Sysname] ssh server enable

[Sysname] sftp server enable

[Sysname] scp server enable

[Sysname] netconf ssh server enable

¡     如果已开启，请执行步骤(4)。

(4)     检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号，客户端仍然使用缺省端口号登录时，会出现登录失败。

以我司设备作为客户端为例，会出现如下错误提示信息：Failed to connect to host 10.1.1.1 port 100.

¡     如果客户端登录时指定的端口号与服务器端不一致，请在服务器端设备上执行display current-configuration | include ssh命令查看服务器端配置的端口号，将客户端登录时指定的端口修改为与服务器端一致。

¡     如果客户端登录时指定的端口号与服务器端一致，请执行步骤(5)。

(5)     检查是否设置了对客户端的访问控制。

首先检查设备上是否通过ssh server acl命令设置了对客户端的访问控制。

¡     如果已设置，请检查客户端配置是否在ACL的permit规则中，请先在设备上通过ssh server acl-deny-log enable命令开启匹配ACL deny规则后打印日志信息功能。

¡     当设备上出现如下日志时，表示客户端的IP地址不在ACL的permit规则中。

SSHS/5/SSH_ACL_DENY: The SSH Connection 181.1.1.10 request was denied according to ACL rules.

SSHS/5/SSH_ACL_DENY: The SSH Connection 181.1.1.11 request was denied according to ACL rules.

-     如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

-     如果在，请执行步骤(6)。

¡     如果未设置，请执行步骤(6)。

(6)     检查服务器的SSH版本与客户端版本是否兼容。

当设备上出现如下日志时，表示设备的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在设备上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡     如果SSH version显示为1.99，则表示设备可以兼容SSH1版本的客户端，请执行步骤(7)。

¡     如果SSH version显示为2.0，请在设备上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(7)     查看VTY用户线下配置的认证方式及允许接入的协议是否正确。

当客户端为Stelnet客户端和NETCONF over SSH客户端时，需要在VTY用户线视图下，执行display this命令查看配置的认证方式是否为scheme、允许接入的协议是否包含SSH。

[Sysname] line vty 0 63

[Sysname-line-vty0-63] display this

#

line vty 0 63

 authentication-mode scheme

 user-role network-admin

 idle-timeout 0 0

#

¡     如果认证方式或者接入协议配置不正确，请通过authentication-mode scheme命令将认证方式修改为scheme、通过protocol inbound ssh命令将允许接入的协议修改为包含SSH。

¡     如果均配置正确，请执行步骤(8)。

(8)     检查设备上VTY用户数是否达到允许用户数的上限。

SSH用户与Telnet用户登录均使用VTY用户线，但是VTY用户线是有限资源。若VTY类型用户线都已被占用，则后续使用Stelnet及NETCONF over SSH服务的客户端将无法登录，使用SFTP及SCP服务的客户端不占用用户线资源，不受影响，仍可登录。

当设备上出现如下日志时，表示设备上VTY用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_USER_LIMIT: SSH client 192.168.30.117 failed to log in, because the number of users reached the upper limit.

通过display line命令查看VTY用户线资源是否充足。

¡     如果VTY用户线资源不足，可将空闲且非scheme认证方式的VTY类型用户线认证方式修改为scheme认证方式；若所有VTY类型用户线都已是scheme认证方式且均处于active状态，可执行free ssh命令强制释放已建立的部分SSH连接或者执行free line vty命令强制释放VTY用户线，使得新的SSH用户能够上线。

¡     如果VTY用户线资源充足，请执行步骤(9)。

(9)     检查登录服务器的SSH用户数是否达到允许用户数的上限。

通过display ssh server session命令查看服务器的会话信息，以及查看通过aaa session-limit ssh命令配置的SSH最大用户连接数。

当设备上出现如下日志时，表示登录服务器的SSH用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The number of SSH sessions is 10, and exceeded the limit (10).

¡     如果SSH会话数已达到上限，可通过执行aaa session-limit ssh命令调大上限；如果配置的最大用户连接数已为可配置的最大值，可执行free ssh命令强制释放已建立的部分SSH连接或者在客户端下线空闲的SSH客户端，使得新的SSH用户能够上线。

¡     如果未达上限，请执行步骤(10)。

(10)     检查服务器上是否生成了本地密钥对。

为了防止“伪服务器欺骗”，客户端验证服务器身份时，首先判断服务器发送的公钥与本地保存的服务器公钥是否一致，确认服务器公钥正确后，再使用该公钥对服务器发送的数字签名进行验证。如果客户端没有保存服务器的公钥或保存的服务器公钥不正确，则服务器身份验证将会失败，从而导致客户端无法登录服务器。因此，客户端登录服务器之前，需要先在服务器端创建密钥对，并将正确的服务器公钥保存在客户端。

虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡     如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置。

¡     如果已配置，请执行步骤(11)。

(11)     检查是否配置了SSH用户并指定正确的服务类型和认证方式。

SSH支持Stelnet、SFTP、NETCONF和SCP四种用户服务类型。

首先，根据服务器采用的认证类型，查看设备上是否创建正确的SSH用户。

由于服务器采用了publickey认证，则必须在设备上创建相应的SSH用户，以及同名的本地用户（用于下发授权属性：工作目录、用户角色）。

接着，根据检查的结果，进行如下操作：

¡     如果未创建，请通过ssh user命令进行配置。

¡     如果已创建，检查SSH用户的服务类型和认证方式。

-     请在设备上执行display ssh user-information命令，分别通过“Service-type”和“Authentication-type”字段查看SSH用户的服务类型及认证方式。其中，服务类型必须与客户端类型（Stelnet客户端、SFTP客户端、SCP客户端或NETCONF over SSH客户端）相匹配，认证方式必须为publickey。

-     请在设备系统视图下执行ssh user命令，将SSH用户的服务类型和认证方式修改正确。

(12)     检查SCP/SFTP工作目录配置是否正确。

当SSH用户的服务方式为SCP/SFTP时，需要为该用户设置授权目录。如果所配置的授权目录不存在，SCP/SFTP客户端通过该用户连接SCP/SFTP服务器就会失败。对于publickey认证方式的用户，请检查通过AAA授权的工作目录是否存在。

¡     如果不存在，请通过本地用户视图下的authorization-attribute work-directory directory-name命令修改授权的工作目录。

¡     如果存在，请执行步骤(13)。

(13)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名：HH3C-SSH-MIB

·     hh3cSSHVersionNegotiationFailure (1.3.6.1.4.1.25506.2.22.1.3.0.2)

相关日志

·     SSHS/5/SSH_ACL_DENY

·     SSHS/6/SSHS_ALGORITHM_MISMATCH

·     SSHS/6/SSHS_REACH_SESSION_LIMIT

·     SSHS/6/SSHS_REACH_USER_LIMIT

·     SSHS/6/SSHS_SRV_UNAVAILABLE

·     SSHS/6/SSHS_VERSION_MISMATCH

1.1.4  设备作为SSH客户端，用户使用password认证方式登录失败

1. 故障描述

设备作为SSH客户端，用户使用password认证方式登录SSH服务器失败。

2. 常见原因

本类故障的常见原因主要包括：

·     SSH客户端与服务器端之间路由不通，无法建立TCP连接。

·     SSH客户端登录密码不正确。

·     服务器上未生成本地密钥对。

·     服务器主机密钥与SSH客户端上缓存的密钥不匹配。

·     客户端的SSH版本与服务器端不兼容。

3. 故障分析

本类故障的诊断流程如图1-4所示。

图1-4 设备作为客户端采用password认证方式登录SSH服务器失败故障诊断流程图

 

4. 处理步骤

(1)     ‍检查客户端能否Ping通服务器端。

使用ping命令查看网络连接情况。

¡     如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡     如果可以Ping通，请执行步骤(2)。

(2)     检查登录密码是否正确。

a.     ‍如果服务器采用本地认证，请确认当前用户登录的密码是否与设备上设备管理类本地用户视图下配置的密码一致：

-     如果不一致，请重新输入正确的密码。若忘记密码，可以在服务器上进入设备管理类本地用户视图（用户名为当前登录的用户）下，执行password命令重新配置新的密码，确保登录密码与配置的密码一致。（此处以我司设备作为SSH服务器为例）

-     如果一致，请执行步骤(3)。

b.     如果服务器采用远程认证，请确认当前用户登录的密码是否与认证服务器上配置的一致：

-     如果不一致，请重新输入正确的密码。若忘记密码，可以在服务器上为登录用户重新设置密码，确保登录密码与认证服务器上配置的一致。

-     如果一致，请执行步骤(3)。

(3)     检查服务器上是否生成了本地密钥对。

为了防止“伪服务器欺骗”，客户端验证服务器身份时，首先判断服务器发送的公钥与本地保存的服务器公钥是否一致，确认服务器公钥正确后，再使用该公钥对服务器发送的数字签名进行验证。如果客户端没有保存服务器的公钥或保存的服务器公钥不正确，则服务器身份验证将会失败，从而导致客户端无法登录服务器。因此，客户端登录服务器之前，需要先在服务器端创建密钥对，并将正确的服务器公钥保存在客户端。

虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

以我司设备作为SSH服务器为例，在服务器上执行display public-key local public命令查看当前服务器上的密钥对信息。

¡     如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置，并确保将服务器上生成的公钥保存到客户端。

¡     如果已配置，请执行步骤(4)。

(4)     检查服务器的SSH版本与客户端版本是否兼容。

以我司设备作为SSH服务器为例，当服务器上出现如下日志时，表示服务器的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在服务器上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡     如果SSH version显示为1.99，则表示服务器上可以兼容SSH1版本的客户端，请执行步骤(7)。

¡     如果SSH version显示为2.0，请在服务器上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(5)     检查服务器主机密钥与客户端上缓存的服务器主机密钥对是否一致。

如果客户端首次登录服务器设备时选择保存了服务器端主机密钥，当服务器设备更新本地密钥对后，将会导致客户端认证服务端失败。

以我司设备作为SSH服务器为例，当设备作为客户端登录时，若出现如下提示信息，则表示服务器主机密钥与客户端上本地缓存的密钥不一致。

The server's host key does not match the local cached key. Either the server administrator has changed the host key, or you connected to another server pretending to be this server. Please remove the local cached key, before logging in!

¡     如果不一致，请在客户端上执行delete ssh client server-public-key命令，删除客户端保存的旧的服务端主机密钥。

¡     如果一致，请执行步骤(6)。

(6)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

无

相关日志

无

1.1.5  设备作为SSH客户端，用户使用publickey认证方式登录失败

1. 故障描述

设备作为SSH客户端，用户使用publickey认证方式登录SSH服务器失败。

2. 常见原因

本类故障的常见原因主要包括：

·     SSH客户端与服务器端之间路由不通，无法建立TCP连接。

·     服务器上未生成本地密钥对。

·     服务器端配置的用户公钥不正确。

·     服务器主机密钥与SSH客户端上缓存的密钥不匹配。

·     客户端的SSH版本与服务器端不兼容。

3. 故障分析

本类故障的诊断流程如图1-5所示。

图1-5 设备作为客户端使用publickey认证方式登录SSH服务器失败故障诊断流程图

 

4. 处理步骤

(1)     ‍检查客户端能否Ping通服务器端。

使用ping命令查看网络连接情况。

¡     如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡     如果可以Ping通，请执行步骤(2)。

(2)     检查服务器端配置的用户公钥和用户使用的私钥是否匹配。

SSH客户端可能支持多种公钥算法，每种公钥算法对应不同的非对称密钥对。只有服务器端保存的用户公钥类型与用户登录时使用的私钥类型一致时，用户认证才会成功。例如，服务器端为某用户指定了DSA类型的公钥，用户也持有与之相匹配的私钥，但是登录时用户使用的私钥类型为RSA，此时用户认证会失败。

以我司设备作为SSH服务器为例，通过在服务器上执行display public-key peer命令查看保存在设备上的客户端公钥信息，判断是否与正在登录用户使用的私钥类型一致：

¡     如果不一致，请执行public-key local create命令在服务器上生成相应类型的密钥对。

¡     如果一致，请执行步骤(3)。

(3)     检查服务器上是否生成了本地密钥对。

为了防止“伪服务器欺骗”，客户端验证服务器身份时，首先判断服务器发送的公钥与本地保存的服务器公钥是否一致，确认服务器公钥正确后，再使用该公钥对服务器发送的数字签名进行验证。如果客户端没有保存服务器的公钥或保存的服务器公钥不正确，则服务器身份验证将会失败，从而导致客户端无法登录服务器。因此，客户端登录服务器之前，需要先在服务器端创建密钥对，并将正确的服务器公钥保存在客户端。

虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

以我司设备作为SSH服务器为例，在服务器上执行display public-key local public命令查看当前服务器上的密钥对信息。

¡     如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置。

¡     如果已配置，请执行步骤(4)。

(4)     检查服务器的SSH版本与客户端版本是否兼容。

当服务器上出现如下日志时，表示服务器的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

以我司设备作为SSH服务器为例，如果使用SSH1版本的客户端登录设备，可以在服务器上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡     如果SSH version显示为1.99，则表示服务器上可以兼容SSH1版本的客户端，请执行步骤(5)。

¡     如果SSH version显示为2.0，请在服务器上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(5)     检查服务器主机密钥与客户端上缓存的服务器主机密钥对是否一致。

如果客户端首次登录服务器设备时选择保存了服务器端主机密钥，当服务器设备更新本地密钥对后，将会导致客户端认证服务端失败。

以我司设备作为SSH服务器为例，当设备作为客户端登录时，若出现如下提示信息，则表示服务器主机密钥与客户端上本地缓存的密钥不一致。

The server's host key does not match the local cached key. Either the server administrator has changed the host key, or you connected to another server pretending to be this server. Please remove the local cached key, before logging in!

¡     如果不一致，请在客户端上执行delete ssh client server-public-key命令，删除客户端保存的旧的服务端主机密钥。

¡     如果一致，请执行步骤(6)。

(6)     如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

无

相关日志

无