Login
- Table of Contents
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 02-SSH Troubleshooting Guide | 262.37 KB |
Troubleshooting security management
SSH issues
Failure to log in to the device from the SSH client
Symptom
The SSH client fails to log in to the device as the SSH server.
Common causes
The following are the common causes of this type of issue:
· The SSH client cannot reach the device.
· The device is not enabled with the SSH server function.
· An SSH login control ACL is specified on the device, but the ACL does not permit the IP address of the SSH client.
· The service port specified by the client does not match the server port.
· The SSH version on the device is not compatible with the client.
· No local key pairs are generated on the device.
· The public key on the server is inconsistent with that cached on the device.
· The authentication method or access protocol for a user line is incorrectly configured.
· No SSH service is configured in local user view on the device.
· The service type or authentication method for the SSH user is incorrectly configured.
· The algorithms for SSH2 the device are not compatible that on the client.
· The device does not have enough VTY user line resources.
· The number of SSH login users on the device reaches the upper limit.
Troubleshooting flow
Figure 1 shows the troubleshooting flowchart.
Figure 1 Flowchart for troubleshooting SSH login failure
Solution
1. Verify that the client can ping the device.
Execute the ping command to check network connectivity.
¡ If the ping fails, see the ping troubleshooting procedure for Layer 3—IP services troubleshooting to ensure that that the SSL VPN client can ping the SSL VPN gateway.
¡ If the ping succeeds, proceed to step 2.
2. Verify that the SSH server function is enabled.
If the following log message occurs, the SSH server function is disabled:
SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.
Execute the display ssh server status command to identify whether the Stelnet server function, SFTP server function, NETCONF over SSH server function, and SCP server function are enabled as needed.
<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
¡ If the SSH server function is disabled, execute the following commands to enable related SSH server functions:
<Sysname> system-view
[Sysname] ssh server enable
[Sysname] sftp server enable
[Sysname] scp server enable
[Sysname] netconf ssh server enable
¡ If the SSH server function is enabled, proceed to step 3.
3. Identify whether an SSH login control ACL is configured.
Identify whether an SSH login control ACL is specified by the ssh server acl command.
¡ If an SSH login control ACL is configured, identify whether the specified ACL permits the IP address of the client.
If the following log message occurs, the specified ACL denies the IP address of the client:
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.
- If the specified ACL denies the IP address of the client, edit the SSH login control ACL for the ACL to permit the IP address of the client. If no SSH clients require login control, remove SSH login control settings.
- If the specified ACL already permits the IP address of the client, proceed to 4.
¡ If no SSH login control ACL is configured, proceed to step 4.
4. Identify whether the SSH service port on the client matches that on the server.
If the SSH service port on the server changes, but the client still uses the default SSH service port, the SSH login will fail.
Take an H3C device as the client as an example. The following error message will occur: Failed to connect to host 10.1.1.1 port 100.
¡ If the SSH service port on the client does not match that on the server, execute the display current-configuration | include ssh command to view the SSH service port on the server, and then change the SSH service port on the client to that on the server.
¡ If the SSH service port on the client matches that on the server, proceed to step 5.
5. Identify whether the SSH version on the server is compatible with that on the client.
If the following log message occurs, the SSH version on the device is not compatible with that on the client:
SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.
If an SSH1 client logs in to the device, you can execute the display ssh server status command on the device to identify the SSH version from the SSH version field.
¡ If the SSH version field displays 1.99, the device is compatible the SSH1 client. Then, proceed to step 6.
¡ If the SSH version field displays 2.0, execute the ssh server compatible-ssh1x enable command on the device to enable the device to support SSH1 clients.
6. Identify whether the server generates a local key pair.
When the device acts as the SSH server, you must configure a local asymmetric key pair. A client uses only one of DSA, ECDSA, or RSA public key algorithms to authenticate the server, but different clients support different algorithms. To ensure successful client login, generate DSA, ECDSA, and RSA key pairs on the server as a best practice.
Execute the display public-key local public command on the device to view local public key information on the device.
¡ If no DSA, ECDSA, or RSA key pair exists, execute the public-key local create command to configure these key pairs in sequence.
¡ If these key pairs are configured, proceed to step 7.
7. Identify whether the public key on the server is consistent with that cached on the client.
If the client chooses to save the server's public key upon the first login, updating the server's local key pair will cause the client to fail to authenticate the server.
This example uses an H3C device as the client. If the following message occurs upon client login, the public key on the server is inconsistent with that cached on the client:
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!
¡ If the inconsistency occurs, execute the delete ssh client server-public-key command to delete the old server public key saved on the client.
¡ If the inconsistency does not exist, proceed to step 8.
If the client is an Stelnet or NETCONF over SSH client, execute the display this command in VTY user line view to identify whether the authentication method is scheme and SSH is specified as an access protocol.
[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
#
¡ If the authentication method or access protocol is configured incorrectly, change the authentication method to scheme and specify SSH as one of the access protocols.
¡ If the configuration is correct, proceed to step 9.
9. Identify whether the SSH service is authorized to local users. This steps applies to only local authentication.
Execute the display this command in local user view to identify whether the SSH service is authorized to the local user.
[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
#
¡ If the SSH service is not authorized, execute the service-type command in local user view to specify the SSH service.
¡ If the SSH service is authorized, proceed to step 10.
If remote authentication is configured, locate issues as described in the AAA troubleshooting guide.
SSH supports Stelnet, SFTP, NETCONF, and SCP service types.
First, identify whether the SSH user is created correctly based on the authentication method on the server.
¡ If the server uses the publickey authentication method, you must create an SSH user and a local user on the device. The two users must have the same username, so that the SSH user can be assigned the correct working directory and user role.
¡ If the server uses the password authentication method, you must perform one of the following tasks:
- For local authentication, configure a local user on the device.
- For remote authentication, configure an SSH user on a remote authentication server, for example, a RADIUS server. You do not need to create an SSH user. However, if such an SSH user has been created, make sure you have specified the correct service type and authentication method.
¡ If the server uses the keyboard-interactive, password-publickey, or any authentication method, you must create an SSH user on the device and perform one of the following tasks:
- For local authentication, configure a local user on the device.
- For remote authentication, configure an SSH user on a remote authentication server, for example, a RADIUS server.
Then, perform the following operations based on the result of the previous step:
¡ If no SSH user is created and required, proceed to step 11. If no SSH user is created but an SSH user is required, execute the ssh user command to create an SSH user.
¡ If an SSH user has been created, check the service type and authentication method for the SSH user.
To avoid login failure, the service type of the SSH user must match the client type, which can be Stelnet, SFTP, SCP, or NETCONF over SSH. Identify whether the service type for the SSH user is correct .
Take the SCP client as an example. The service type does not match the client type, if the following log message occurs on the device:
SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.
Then, perform the following operations:
- Execute the ssh user command in system view on the device to edit the service type for the SSH user.
- Execute the display ssh user-information command on the device to view the authentication method used by the SSH server. Identify whether the SSH user on the device is configured correctly based on the authentication method.
11. Identify whether algorithms for SSH2 on the device match the client.
Execute the display ssh2 algorithm command to view algorithms used by SSH2 to identify whether these algorithms include those supported by the client. For example, if the device is configured to not use CBC-related encryption algorithms, but the SSH client supports only CBC-related algorithms, the client will be unable to log in to the server.
Algorithms for SSH2 on the device does not match the client, if the following log message occurs on the device:
SSHS/6/SSHS_ALGORITHM_MISMATCH: SSH client 192.168.30.117 failed to log in because of encryption algorithm mismatch.
¡ If the algorithms on the client do not match those on the device, perform one of the following operations as needed:
- Execute the ssh2 algorithm cipher, ssh2 algorithm key-exchange, ssh2 algorithm mac, or ssh2 algorithm public-key command on the device to add algorithms supported by the client.
- Add algorithms supported by the server on the client.
¡ If the algorithms on the client match those on the device, proceed to step 12.
12. Identify whether the number of VTY users on the device reaches the upper limit.
Both SSH and Telnet users log in using VTY user lines, but VTY user lines are limited resources. If all VTY user lines are occupied, clients using Stelnet and NETCONF over SSH cannot log in. Clients using SFTP and SCP do not occupy user lines and can still log in.
The number of VTY users on the device reaches the upper limit if the following log message occurs:
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.
Execute the display line command to identify whether VTY user lines are sufficient.
¡ If VTY user line resources are insufficient, change the authentication method for idle VTY lines with non-scheme authentication to scheme. If all VTY lines already use scheme authentication and are active, execute free ssh to forcibly release some established SSH connections, or execute free line vty to forcibly release VTY lines. This allows new SSH users to come online.
¡ If VTY user line resources are sufficient, proceed to step 13.
13. Identify whether the number of online SSH users reaches the upper limit.
Execute the display ssh server session command to view session information on the server and the maximum number of SSH connections set by the aaa session-limit ssh command.
The number of online SSH users reaches the upper limit if the following log message occurs on the device:
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).
SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The current number of SSH sessions is 10. The maximum number allowed is 10.
¡ If the number of SSH sessions has reached the upper limit, execute aaa session-limit ssh to increase the upper limit. If the configured maximum number of user connections has reached the upper limit, execute free ssh to forcibly release some established SSH connections, or disconnect idle SSH clients from the client side. This will allow new SSH users to come online.
¡ If the upper limit is not reached, proceed to step 14.
14. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration files, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
Module: HH3C-SSH-MIB
hh3cSSHVersionNegotiationFailure (1.3.6.1.4.1.25506.2.22.1.3.0.2)
Log messages
· 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
Failure to log in to the device as the SSH server through password authentication
Symptom
When the device acts the SSH server, a user fails to log in to the device through password authentication.
Common causes
The following are the common causes of this type of issue:
· The SSH client cannot reach the device.
· The login password of the SSH client is incorrect.
· The device is not enabled with the SSH server function.
· The SSH user is not configured on the SSH server.
· An SSH login control ACL is specified on the device, but the ACL does not permit the IP address of the SSH client.
· The number of SSH login users on the device reaches the upper limit.
· The SSH version on the device is not compatible with the client.
· The service type or authentication method for SSH users is configured incorrectly.
· No local key pairs are generated on the device.
· The SCP or SFTP working directory is incorrect.
Troubleshooting flow
Figure 2 shows the troubleshooting flowchart.
Solution
1. Verify that the client can ping the device.
Execute the ping command to check network connectivity.
¡ If the ping fails, see the ping troubleshooting procedure for Layer 3—IP services troubleshooting to ensure that that the SSL VPN client can ping the SSL VPN gateway.
¡ If the ping succeeds, proceed to step 2.
2. Verify that the login password is correct.
¡ If the server uses local authentication, identify whether the login password of the user is consistent with that set for the local device management user on the device.
- If the inconsistency occurs, enter the correct login password again. If the login password is forgotten, enter the view of the local device management user and execute the password command to specify a new password to ensure that the login password of the user and the specified password are the same. The name of the local device management user is that of the current login user.
- If the inconsistency does not exist, proceed to step 2.
¡ If the server uses remote authentication, make sure the password of the current login user is consistent with that on the authentication server.
- If the inconsistency occurs, enter the correct login password again. If the password is forgotten, set a new password on the device for the login user. Make sure the set password is consistent with that on the authentication server.
- If the inconsistency does not exist, proceed to step 2.
3. Verify that the SSH server function is enabled.
If the following log message occurs, the SSH server function is disabled:
SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.
Execute the display ssh server status command to identify whether the Stelnet server function, SFTP server function, NETCONF over SSH server function, and SCP server function are enabled as needed.
<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
¡ If the SSH server function is disabled, execute the following commands to enable related SSH server functions:
<Sysname> system-view
[Sysname] ssh server enable
[Sysname] sftp server enable
[Sysname] scp server enable
[Sysname] netconf ssh server enable
¡ If the SSH server function is enabled, proceed to step 4.
4. Identify whether the SSH service port on the client matches that on the server.
If the SSH service port on the server changes, but the client still uses the default SSH service port, the SSH login will fail.
Take an H3C device as the client as an example. The following error message will occur: Failed to connect to host 10.1.1.1 port 22.
¡ If the SSH service port on the client does not match that on the server, execute the display current-configuration | include ssh command to view the SSH service port on the server, and then change the SSH service port on the client to that on the server.
¡ If the SSH service port on the client matches that on the server, proceed to step 5.
5. Identify whether an SSH login control ACL is configured.
Identify whether an SSH login control ACL is specified by the ssh server acl command.
¡ If an SSH login control ACL is specified, identify whether the client is permitted by the ACL. First, execute the ssh server acl-deny-log enable command to enable logging for SSH login attempts that are denied by the SSH login control ACL.
¡ If the following log message occurs, the specified ACL denies the IP address of the client:
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.
- If the specified ACL denies the IP address of the client, edit the SSH login control ACL for the ACL to permit the IP address of the client. If no SSH clients require login control, remove SSH login control settings.
- If the specified ACL already permits the IP address of the client, proceed to 5.
¡ If no SSH login control ACL is specified, proceed to step 5.
6. Identify whether the SSH version on the server is compatible with the client version.
If the following log message occurs, the SSH version on the device is not compatible with that on the client:
SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.
If an SSH1 client logs in to the device, you can execute the display ssh server status command on the device to identify the SSH version from the SSH version field.
¡ If the SSH version field displays 1.99, the device is compatible the SSH1 client. Then, proceed to step 8.
¡ If the SSH version field displays 2.0, execute the ssh server compatible-ssh1x enable command on the device to enable the device to support SSH1 clients.
7. Identify whether the authentication method and the access protocol for a VTY user line are configured incorrectly.
If the client is an Stelnet or NETCONF over SSH client, execute the display this command in VTY user line view to identify whether the authentication method is scheme and SSH is specified as an access protocol.
[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
#
¡ If the authentication method or access protocol is configured incorrectly, execute authentication-mode scheme to change the authentication method to scheme and execute protocol inbound ssh to specify SSH as one of the access protocols.
¡ If the configuration is correct, proceed to step 12.
8. Identify whether the number of VTY users on the device reaches the upper limit.
Both SSH and Telnet users log in using VTY user lines, but VTY user lines are limited resources. If all VTY user lines are occupied, clients using Stelnet and NETCONF over SSH cannot log in. Clients using SFTP and SCP do not occupy user lines and can still log in.
The number of VTY users on the device reaches the upper limit if the following log message occurs:
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.
Execute the display line command to identify whether VTY user lines are sufficient.
¡ If VTY user line resources are insufficient, change the authentication method for idle VTY lines with non-scheme authentication to scheme. If all VTY lines already use scheme authentication and are active, execute free ssh to forcibly release some established SSH connections, or execute free line vty to forcibly release VTY lines. This allows new SSH users to come online.
¡ If VTY user line resources are sufficient, proceed to step 13.
9. Identify whether the number of online SSH users reaches the upper limit.
Execute the display ssh server session command to view session information on the server and the maximum number of SSH connections set by the aaa session-limit ssh command.
The number of online SSH users reaches the upper limit if the following log message occurs on the device:
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).
¡ If the number of SSH sessions has reached the upper limit, execute aaa session-limit ssh to increase the upper limit. If the configured maximum number of user connections has reached the upper limit, execute free ssh to forcibly release some established SSH connections, or disconnect idle SSH clients from the client side. This will allow new SSH users to come online.
¡ If the upper limit is not reached, proceed to step 10.
10. Identify whether the server generates a local key pair.
To prevent fake server spoofing, the client first identifies whether the public key sent from the server matches the one stored locally when the client authenticates the server. After the client verifies the public key consistency, the client uses this public key to verify the server's digital signature. If the client has not saved the server's public key or the saved server’s public key is incorrect, server authentication will fail, preventing the client from logging in to the server. Therefore, before the client logs in to the server, create a key pair on the server and save the correct server’s public key on the client.
A client uses only one of DSA, ECDSA, or RSA public key algorithms to authenticate the server, but different clients support different algorithms. To ensure successful client login, generate DSA, ECDSA, and RSA key pairs on the server as a best practice.
Execute the display public-key local public command no the device to view local public key information on the device.
¡ If no DSA, ECDSA, or RSA key pair exists, execute the public-key local create command to configure these key pairs in sequence. Make sure the public key generated on the server is saved to the client.
¡ If these key pairs are configured, proceed to step 10.
11. Identify whether an SSH user is configured and the correct service type and authentication method are specified for the SSH user.
SSH supports Stelnet, SFTP, NETCONF, and SCP service types.
Identify whether the SSH user is created correctly based on the authentication method on the server.
If the server uses the password authentication method, you must perform one of the following tasks:
¡ For local authentication, configure a local user on the device.
¡ For remote authentication, configure an SSH user on a remote authentication server, for example, a RADIUS server.
For remote authentication, you do not need to create an SSH user. However, if such an SSH user has been created, make sure you have specified the correct service type and authentication method.
Perform the following operations based on the result of the previous step:
¡ If no SSH user is created and required, proceed to step 12. If no SSH user is created but an SSH user is required, execute the ssh user command to create an SSH user.
¡ If an SSH user has been created, check the service type and authentication method for the SSH user.
- Execute the display ssh user-information command on the device to view the service type and authentication for the SSH user from the Service-type and Authentication-type fields, respectively. The service type of the SSH user must match the client type, which can be Stelnet, SFTP, SCP, or NETCONF over SSH, and the authentication method must be password.
- Execute the ssh user command in system view on the device to edit the service type and authentication method for the SSH user as required.
12. Identify whether the SCP or SFTP working directory is correct.
When the service type for an SSH user is SCP or SFTP, specify an authorized directory for the SSH user. If the specified authorized directory does not exist, the SCP or SFTP client will fail to connect to the SCP or SFTP server through that SSH user. For a password authentication user, identify whether the AAA-authorized working directory exists.
¡ If the working directory does not exist, execute the authorization-attribute work-directory directory-name command in local user view to edit the authorized working directory.
¡ If the working directory exists, proceed to step 13.
13. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration files, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
Module: HH3C-SSH-MIB
hh3cSSHVersionNegotiationFailure (1.3.6.1.4.1.25506.2.22.1.3.0.2)
Log messages
· 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
Failure to log in to the device as the SSH server through publickey authentication
Symptom
When the device acts the SSH server, a user fails to log in to the device through publickey authentication.
Common causes
The following are the common causes of this type of issue:
· The SSH client cannot reach the device.
· The user's public key on the server is configured incorrectly.
· The device is not enabled with the SSH server function.
· The SSH user is not configured on the SSH server.
· An SSH login control ACL is specified on the device, but the ACL does not permit the IP address of the SSH client.
· The number of SSH login users on the device reaches the upper limit.
· The SSH version on the device is not compatible with the client.
· The service type or authentication method for SSH users is configured incorrectly.
· No local key pairs are generated on the device.
· The SCP or SFTP working directory is incorrect.
Troubleshooting flow
Figure 3图2 shows the troubleshooting flowchart.
Solution
1. Verify that the client can ping the device.
Execute the ping command to check network connectivity.
¡ If the ping fails, see the ping troubleshooting procedure for Layer 3—IP services troubleshooting to ensure that that the SSL VPN client can ping the SSL VPN gateway.
¡ If the ping succeeds, proceed to step 2.
The SSH client might support multiple public key algorithms, each corresponding to a different asymmetric key pair. User authentication will succeed only when the type of public key saved on the server matches the type of private key used by the user during login. For example, if the server specifies the DSA public key for a user and the user also has a matching private key. However, user authentication will fail if the user attempts to log in using an RSA private key. Execute the display public-key peer command on the device to view client public key information saved on the device. Identify whether the client public key is consistent with the type of private key used by the login user.
¡ If the inconsistency occurs, execute the public-key local create command for the device to generate the corresponding type of private key pair.
¡ If the consistency exists, proceed to step 3.
3. Verify that the SSH server function is enabled.
If the following log message occurs, the SSH server function is disabled:
SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.
Execute the display ssh server status command to identify whether the Stelnet server function, SFTP server function, NETCONF over SSH server function, and SCP server function are enabled as needed.
<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
¡ If the SSH server function is disabled, execute the following commands to enable related SSH server functions:
<Sysname> system-view
[Sysname] ssh server enable
[Sysname] sftp server enable
[Sysname] scp server enable
[Sysname] netconf ssh server enable
¡ If the SSH server function is enabled, proceed to step 4.
4. Identify whether the SSH service port on the client matches that on the server.
If the SSH service port on the server changes, but the client still uses the default SSH service port, the SSH login will fail.
Take an H3C device as the client as an example. The following error message will occur: Failed to connect to host 10.1.1.1 port 100.
¡ If the SSH service port on the client does not match that on the server, execute the display current-configuration | include ssh command to view the SSH service port on the server, and then change the SSH service port on the client to that on the server.
¡ If the SSH service port on the client matches that on the server, proceed to step 5.
5. Identify whether an SSH login control ACL is configured.
Identify whether an SSH login control ACL is specified by the ssh server acl command.
¡ If an SSH login control ACL is specified, identify whether the client is permitted by the ACL. First, execute the ssh server acl-deny-log enable command to enable logging for SSH login attempts that are denied by the SSH login control ACL.
If the following log message occurs, the specified ACL denies the IP address of the client:
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.
- If the specified ACL denies the IP address of the client, edit the SSH login control ACL for the ACL to permit the IP address of the client. If no SSH clients require login control, remove SSH login control settings.
- If the specified ACL already permits the IP address of the client, proceed to 6.
¡ If no SSH login control ACL is configured, proceed to step 6.
6. Identify whether the SSH version on the server is compatible with the client version.
If the following log message occurs, the SSH version on the device is not compatible with that on the client:
SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.
If an SSH1 client logs in to the device, you can execute the display ssh server status command on the device to identify the SSH version from the SSH version field.
¡ If the SSH version field displays 1.99, the device is compatible the SSH1 client. Then, proceed to step 7.
¡ If the SSH version field displays 2.0, execute the ssh server compatible-ssh1x enable command on the device to enable the device to support SSH1 clients.
If the client is an Stelnet or NETCONF over SSH client, execute the display this command in VTY user line view to identify whether the authentication method is scheme and SSH is specified as an access protocol.
[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
#
¡ If the authentication method or access protocol is configured incorrectly, execute authentication-mode scheme to change the authentication method to scheme and execute protocol inbound ssh to specify SSH as one of the access protocols.
¡ If the configuration is correct, proceed to step 8.
8. Identify whether the number of VTY users on the device reaches the upper limit.
Both SSH and Telnet users log in using VTY user lines, but VTY user lines are limited resources. If all VTY user lines are occupied, clients using Stelnet and NETCONF over SSH cannot log in. Clients using SFTP and SCP do not occupy user lines and can still log in.
The number of VTY users on the device reaches the upper limit if the following log message occurs:
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.
Execute the display line command to identify whether VTY user lines are sufficient.
¡ If VTY user line resources are insufficient, change the authentication method for idle VTY lines with non-scheme authentication to scheme. If all VTY lines already use scheme authentication and are active, execute free ssh to forcibly release some established SSH connections, or execute free line vty to forcibly release VTY lines. This allows new SSH users to come online.
¡ If VTY user line resources are sufficient, proceed to step 9.
9. Identify whether the number of online SSH users reaches the upper limit.
Execute the display ssh server session command to view session information on the server and the maximum number of SSH connections set by the aaa session-limit ssh command.
The number of online SSH users reaches the upper limit if the following log message occurs on the device:
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).
¡ If the number of SSH sessions has reached the upper limit, execute aaa session-limit ssh to increase the upper limit. If the configured maximum number of user connections has reached the upper limit, execute free ssh to forcibly release some established SSH connections, or disconnect idle SSH clients from the client side. This will allow new SSH users to come online.
¡ If the upper limit is not reached, proceed to step 10.
10. Identify whether the server generates a local key pair.
To prevent fake server spoofing, the client first identifies whether the public key sent from the server matches the one stored locally when the client authenticates the server. After the client verifies the public key consistency, he client uses this public key to verify the server's digital signature. If the client has not saved the server's public key or the saved server’s public key is incorrect, server authentication will fail, preventing the client from logging in to the server. Therefore, before the client logs in to the server, create a key pair on the server and save the correct server’s public key on the client.
A client uses only one of DSA, ECDSA, or RSA public key algorithms to authenticate the server, but different clients support different algorithms. To ensure successful client login, generate DSA, ECDSA, and RSA key pairs on the server as a best practice.
Execute the display public-key local public command o he device to view local public key information on the device.
¡ If no DSA, ECDSA, or RSA key pair exists, execute the public-key local create command to configure these key pairs in sequence.
¡ If these key pairs are configured, proceed to step 11.
SSH supports Stelnet, SFTP, NETCONF, and SCP service types.
Identify whether the SSH user is created correctly based on the authentication method on the server.
If the server uses the publickey authentication method, you must create an SSH user and a local user on the device. The two users must have the same username, so that the SSH user can be assigned the correct working directory and user role.
Perform the following operations based on the result of the previous step:
¡ If no SSH user is configured, execute the ssh user command to create an SSH user.
¡ If an SSH user has been created, check the service type and authentication method for the SSH user.
- Execute the display ssh user-information command on the device to view the service type and authentication for the SSH user from the Service-type and Authentication-type fields, respectively. The service type of the SSH user must match the client type, which can be Stelnet, SFTP, SCP, or NETCONF over SSH, and the authentication method must be publickey.
- Execute the ssh user command in system view on the device to edit the service type and authentication method for the SSH user as required.
12. Identify whether the SCP or SFTP working directory is correct.
When the service type for an SSH user is SCP or SFTP, specify an authorized directory for the SSH user. If the specified authorized directory does not exist, the SCP or SFTP client will fail to connect to the SCP or SFTP server through that SSH user. For a publickey authentication user, identify whether the AAA-authorized working directory exists.
¡ If the working directory does not exist, execute the authorization-attribute work-directory directory-name command in local user view to edit the authorized working directory.
¡ If the working directory exists, proceed to step 13.
13. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration files, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
Module: HH3C-SSH-MIB
hh3cSSHVersionNegotiationFailure (1.3.6.1.4.1.25506.2.22.1.3.0.2)
Log messages
· 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
Failure to log in to the SSH server through password authentication when the device acts as the SSH client
Symptom
A password authentication user fails to log in to the SSH server when the device acts as the SSH client.
Common causes
The following are the common causes of this type of issue:
· The SSH client cannot reach the server, causing TCP connection setup failure.
· The login password of the SSH client is incorrect.
· No local key pairs are generated on the server.
· The public key on the SSH server is inconsistent with that cached on the SSH client.
· The SSH version of the client is not compatible with the server.
Troubleshooting flow
Figure 4 shows the troubleshooting flowchart.
Figure 4 Flowchart for troubleshooting failure to log in to the SSH server through password authentication when the device acts as the SSH client
Solution
1. Verify that the client can ping the server.
Execute the ping command to check network connectivity.
¡ If the ping fails, see the ping troubleshooting procedure for Layer 3—IP services troubleshooting to ensure that that the SSL VPN client can ping the SSL VPN gateway.
¡ If the ping succeeds, proceed to step 2.
2. Verify that the login password is correct.
¡ If the server uses local authentication, identify whether the login password of the user is consistent with that set for the local device management user on the device.
- If the inconsistency occurs, enter the correct login password again. If the login password is forgotten, enter the view of the local device management user on the server and execute the password command to specify a new password to ensure that the login password of the user and the specified password are the same. The name of the local device management user is that of the current login user. This example uses an H3C device as the SSH server.
- If the inconsistency does not exist, proceed to step 3.
¡ If the server uses remote authentication, make sure the password of the current login user is consistent with that on the authentication server.
- If the inconsistency occurs, enter the correct login password again. If the password is forgotten, set a new password on the device for the login user. Make sure the set password is consistent with that on the authentication server.
- If the inconsistency does not exist, proceed to step 3.
3. Identify whether the server generates a local key pair.
To prevent fake server spoofing, the client first identifies whether the public key sent from the server matches the one stored locally when the client authenticates the server. After the client verifies the public key consistency, he client uses this public key to verify the server's digital signature. If the client has not saved the server's public key or the saved server’s public key is incorrect, server authentication will fail, preventing the client from logging in to the server. Therefore, before the client logs in to the server, create a key pair on the server and save the correct server’s public key on the client.
A client uses only one of DSA, ECDSA, or RSA public key algorithms to authenticate the server, but different clients support different algorithms. To ensure successful client login, generate DSA, ECDSA, and RSA key pairs on the server as a best practice.
This example uses an H3C device as an SSH server. Execute the display public-key local public command on the server to view local public key information on the server.
¡ If no DSA, ECDSA, or RSA key pair exists, execute the public-key local create command to configure these key pairs in sequence. Make sure the public key generated on the server is saved to the client.
¡ If these key pairs are configured, proceed to step 4.
4. Identify whether the SSH version of the server is compatible with the client version.
Verify that the SSH version of the server is compatible with the client version.
This example uses an H3C device as an SSH server. If an SSH1 client logs in to the server, you can execute the display ssh server status command on the server to identify the SSH version from the SSH version field.
¡ If the SSH version field displays 1.99, the server is compatible the SSH1 client. Then, proceed to step 7.
¡ If the SSH version field displays 2.0, execute the ssh server compatible-ssh1x enable command on the server to enable the server to support the SSH1 client.
5. Identify whether the public key on the server is consistent with that cached on the client..
If the client chooses to save the server's public key upon the first login, updating the server's local key pair will cause the client to fail to authenticate the server.
¡ If the inconsistency occurs, execute the delete ssh client server-public-key command on the client to delete the old server public key.
¡ If the inconsistency does not exist, proceed to step 6.
6. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration files, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
N/A
Log messages
N/A
Failure to log in to the SSH server through publickey authentication when the device acts as the SSH client
Symptom
When the device acts an SSH client, a user fails to log in to the SSH server through publickey authentication.
Common causes
The following are the common causes of this type of issue:
· The SSH client cannot reach the server, causing TCP connection setup failure.
· No local key pairs are generated on the server.
· The user's public key on the server is configured incorrectly.
· The server’s public key is not compatible with that cached on the SSH client.
· The SSH version on the client is not compatible with the server.
Troubleshooting flow
Figure 5 shows the troubleshooting flowchart.
Figure 5 Flowchart for troubleshooting failure to log in to the SSH server through publickey authentication when the device acts as an SSH client
Solution
1. Verify that the client can ping the server.
Execute the ping command to check network connectivity.
¡ If the ping fails, see the ping troubleshooting procedure for Layer 3—IP services troubleshooting to ensure that that the SSL VPN client can ping the SSL VPN gateway.
¡ If the ping succeeds, proceed to step 2.
The SSH client might support multiple public key algorithms, each corresponding to a different asymmetric key pair. User authentication will succeed only when the type of public key saved on the server matches the type of private key used by the user during login. For example, if the server specifies the DSA public key for a user and the user also has a matching private key. However, user authentication will fail if the user attempts to log in using an RSA private key.
This example uses an H3C device as an SSH server. Execute the display public-key peer command on the device (client) to view client public key information saved on the device. Identify whether the client public key is consistent with the type of private key used by the login user.
¡ If the inconsistency occurs, execute the public-key local create command on the server to generate the corresponding type of private key pair.
¡ If the consistency exists, proceed to step 3.
3. Identify whether the server generates a local key pair.
To prevent fake server spoofing, the client first identifies whether the public key sent from the server matches the one stored locally when the client authenticates the server. After the client verifies the public key consistency, the client uses this public key to verify the server's digital signature. If the client has not saved the server's public key or the saved server’s public key is incorrect, server authentication will fail, preventing the client from logging in to the server. Therefore, before the client logs in to the server, create a key pair on the server and save the correct server’s public key on the client.
A client uses only one of DSA, ECDSA, or RSA public key algorithms to authenticate the server, but different clients support different algorithms. To ensure successful client login, generate DSA, ECDSA, and RSA key pairs on the server as a best practice.
This example uses an H3C device as an SSH server. Execute the display public-key local public command on the server to view local public key information on the server.
¡ If no DSA, ECDSA, or RSA key pair exists, execute the public-key local create command to configure these key pairs in sequence.
¡ If these key pairs are configured, proceed to step 4.
4. Identify whether the SSH version of the server is compatible with the client version.
Verify that the SSH version of the server is compatible with the client version.
This example uses an H3C device as an SSH server. If an SSH1 client logs in to the server, you can execute the display ssh server status command on the server to identify the SSH version from the SSH version field.
¡ If the SSH version field displays 1.99, the server is compatible the SSH1 client. Then, proceed to step 5.
¡ If the SSH version field displays 2.0, execute the ssh server compatible-ssh1x enable command on the server to enable the server to support the SSH1 client.
5. Identify whether the public key on the server is consistent with that cached on the client.
If the client chooses to save the server's public key upon the first login, updating the server's local key pair will cause the client to fail to authenticate the server.
¡ If the inconsistency occurs, execute the delete ssh client server-public-key command on the client to delete the old server public key saved on the client.
¡ If the inconsistency does not exist, proceed to step 6.
6. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration files, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
N/A
Log messages
N/A
