No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Troubleshooting Guide

CloudEngine 16800, 12800, 12800E, 8800, 7800, 6800, and 5800 Series Switches

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Troubleshooting Procedure

Troubleshooting Procedure

If password authentication is configured for SSH users, generate a local RSA, DSA, or ECC key on the SSH server. If RSA, DSA, or ECC authentication is configured for SSH users, generate a local RSA, DSA, or ECC key pair on both the SSH server and client, and configure the server's public key on the client and the client's public key on the server.

Perform the following operations after logging in to the device through the console port.
  1. Check whether the network connection is normal.

    Before a user logs in to the device using SSH, reachable routes must exist between the user client and device. Ping the IP address of the SSH server from the client to check whether the network connection between the client and server is normal. Make sure that the fault is not caused by an SSH connection setup failure.

  2. Check whether the user public key configured on the server is correct.

    The user public key is a hexadecimal string generated by SSH client software, and is displayed on the client. Check whether the user public key saved on the server is the same as that on the client. If the public keys are different, the server needs to obtain the correct user public key again. The following example uses the user name client001 and RSA public key pubkey. The configuration is as follows:
    <SSH Server> system-view
    [~SSH Server] rsa peer-public-key pubkey
    [*SSH Server-rsa-public-key] public-key-code begin
    [*SSH Server-rsa-public-key-rsa-key-code] 30820107 02820100 7FAEE115 9EEFE3E8 65F976AA 5CE3EDEE
    [*SSH Server-rsa-public-key-rsa-key-code] 681830C0 F787B88C F5C7619D 13169F6D B6D43090 FCBADE17                                                                 
    [*SSH Server-rsa-public-key-rsa-key-code] 9EBFCFFD D7645C35 EC32764B 28EAABFD 31C740AF 552FE37A                                                                 
    [*SSH Server-rsa-public-key-rsa-key-code] 0772DFBB F0D32DDB 8F6505D0 8989E69F 5FA95E7D 132B84BD                                                                 
    [*SSH Server-rsa-public-key-rsa-key-code] E89D8342 F10198DD 9F2980AF A06A311C A7359FA0 D5CBC186                                                                 
    [*SSH Server-rsa-public-key-rsa-key-code] 9DF21AC4 7621F630 3112753D 9AD37F5A CCE0341A 39D774A6                                                                 
    [*SSH Server-rsa-public-key-rsa-key-code] 4344A2B6 DE48CDED 8107F91E B582C3EB B10A418B 92397306                                                                 
    [*SSH Server-rsa-public-key-rsa-key-code] E16F68D2 A693361A A63C3138 A5E787F7 238D2016 96603CA3                                                                 
    [*SSH Server-rsa-public-key-rsa-key-code] 69B36F3D 1FDF370F A90AA914 20CBDA22 E9470606 7C38310D                                                                 
    [*SSH Server-rsa-public-key-rsa-key-code] EEA8D501 405D49DA 4B079726 7DB89C71 8BBF872F 7484E7FA                                                                 
    [*SSH Server-rsa-public-key-rsa-key-code] 7E212465 6276B6EE 9406D306 74BE7781 DD5CFE43 CEB30C7F                                                                 
    [*SSH Server-rsa-public-key-rsa-key-code] 020125                                
    [*SSH Server-rsa-public-key-rsa-key-code] public-key-code end                                      
    [*SSH Server-rsa-public-key] peer-public-key end
    [*SSH Server] ssh user client001 assign rsa-key pubkey
    [*SSH Server] commit
  3. Check whether the user public key configured on the server matches users' private key.

    The SSH client may support multiple public key algorithms, each of which corresponds to a different pair of public key and private key. The user authentication succeeds only when the user public key type saved on the server is consistent with the private key type used during user login. For example, a DSA public key is configured on the server for a user, and the user has a matching private key. However, if the private key type used by the user during login is RSA, the user will fail to pass authentication.

  4. Check whether there is a configuration that conflicts with the public key authentication.

    Run the display current-configuration configuration ssh command in any view to check whether a conflicting configuration exists. (V200R001C00 is used as an example.)
    <SSH Server> display current-configuration configuration ssh
    #                                                                               
    ssh server compatible-ssh1x enable                                              
    stelnet server enable                                                           
    ssh user client001                                                                 
                                             
    ssh user client001 assign rsa-key abc1                                             
    ssh user client001 service-type stelnet                                            
                                                  
    #                                                                               
    ssh client first-time enable                                                    
    #                                                                               
    return                                                                          
    The preceding command output shows that the user client001 uses RSA public key authentication. ssh authorization-type default aaa indicates that AAA authentication is configured for setting up a connection with the SSH server. In this case, only password authentication can be configured for SSH users. If public key authentication is configured, the user client001 fails to log in to the SSH server.
    You can change the authentication type for setting up a connection with the SSH server to root to rectify the login failure fault. The configuration method is as follows:
    <SSH Server> system
    [~SSH Server] ssh authorization-type default root
    [*SSH Server] commit
  5. Check whether the user exists on the server.

    Run the display ssh user-information command in any view to check local user configuration.
    <SSH Server> display ssh user-information
    
    --------------------------------------------------------------------------------
                 : client002                                               
    Authentication type   : rsa                                                     
    User public key name  : rsakey001                                               
    User public key type  : RSA                                                     
    Sftp directory        :                                                         
             : stelnet 
    --------------------------------------------------------------------------------
    Total 1, 1 printed 
    The User Name field displays the SSH user name. View this field to check whether the current user is displayed in the command output. If the current user is not displayed in the command output, perform the following operations to configure the user:
    1. Run the system-view command to enter the system view.
    2. Run the ssh user user-name command to create the user name.
    3. Run the ssh user user-name authentication-type { rsa | password-rsa | all | dsa | password-dsa | ecc | password-ecc } command to configure the authentication mode for SSH users.
    4. Run the ssh user user-name service-type { stelnet | all } command to configure the service type for SSH users. By default, no service type is configured for SSH users.
    5. Run the commit command to commit the configuration.
  6. Check whether the following configurations are correct.

    Run the display ssh server status command in any view to check the SSH server status. (V200R001C00 is used as an example.)
    <SSH Server> display ssh server status
                                     : 2.0
             : 60          
    SSH authentication retries (Times)           : 3          
    SSH server key generating interval (Hours)   : 0      
                   : Disable         
    SSH server keepalive                        : Disable       
    SFTP server                                 : Enable      
                                  : Disable     
    SNETCONF server                             : Enable         
    SNETCONF server port(830)                   : Disable   
    SCP server                                  : Enable
    SSH server DES                              : Disable
                                 : 22 
    SSH server source address                   : 0.0.0.0 
                                        : --
                                      : --
                                       : --
                                     : --
    • View the STelnet server field to check whether the SSH server function is enabled. By default, the SSH server function is disabled. If this field displays Disable, the SSH server function is disabled and the user cannot log in to the server through the client. Run the stelnet server enable command in the system view to enable the SSH server function.

    • View the SSH version 1.x compatibility field to check whether the SSH server is configured to be compatible with earlier SSH versions. By default, SSH server is incompatible with earlier SSH versions.

      There are two incompatible SSH versions: 1.x and 2.0. By default, the SSH version of the SSH server is 2.0. If the SSH version of the SSH server is later than that of the client, run the ssh server compatible-ssh1x enable command in the system view to configure the SSH server to be compatible with earlier SSH versions, to rectify the login failure fault caused by incompatible SSH versions.

      Compared with SSH 1.x, SSH 2.0 is expanded in structure to support more authentication modes and key exchange modes, and has higher security (avoiding security risks of SSH 1.X). Therefore, SSH 2.0 is recommended.

    • View the SSH authentication timeout field to check the timeout period for SSH authentication. The default timeout period is 60 seconds. If the timeout period is too short, users will fail to log in to the SSH server. Run the ssh server timeout seconds command in the system view to change the timeout period for SSH authentication.

    • View the SSH server port field to check whether the port number of the SSH server is 22. The default port number is 22.

      The SSH client can log in to the SSH server with no port number specified only when the port number of the SSH server is 22. If the SSH server uses another port, the port number must be specified when SSH clients log in to the SSH server. If the SSH server's port number specified on the SSH client and server are different, run the undo ssh server port command in the system view to change the SSH server's port number to 22.

    • View the ACL name and ACL number fields or the ACL6 name and ACL6 number fields to check whether an ACL is configured. If these fields display --, no ACL is configured. If an ACL name or number is displayed, an ACL is configured and it may control access rights of SSH clients. Perform the following operations:
      1. Run the display acl { acl-number | name acl-name } or display acl ipv6 { acl6-number | name acl6-name } command to view detailed ACL information. If the current client is in deny state on the ACL, go to step b; otherwise, skip step b.

      2. Cancel the ACL configuration on the SSH server.

        <SSH Server> system-view
        [~SSH Server] undo ssh server acl
        [*SSH Server] commit
  7. Check whether the public key of the SSH server exists on the client.

    To avoid logging in to a bogus SSH server, the client uses the digital signature to verify the SSH server's identity during login. If the public key of the SSH server is not saved on the client or the saved public key is incorrect, the server identity verification fails. As a result, the user fails to log in to the server through the client. Therefore, before a user logs in to the server on the client, create a key pair on the server, and save the correct public key of the SSH server on the client. To ensure successful login to the SSH server, configure and generate a local key pair first. A possible cause of the login failure is that the key pair does not exist. The methods of checking whether a key pair is generated on the device are as follows:
    • View RSA public key information.

      <SSH Server> display rsa local-key-pair public
      Info: Local key pair is not generated.  
      
    • View DSA public key information.

      <SSH Server> display dsa local-key-pair public
      Info: The DSA host keys are not found.   
      
    • View ECC public key information.

      <SSH Server> display ecc local-key-pair public
      Info: Local key pair is not generated.  
      

    The preceding command outputs show that no public key is configured on the server. Run the rsa local-key-pair create, dsa local-key-pair create, or ecc local-key-pair command in the system view to generate an RSA, a DSA, or an ECC key pair. The generated key pair is saved in the device and will not be lost after the device restarts.

  8. Check whether the server locks the IP address of the client.

    If a user enters incorrect passwords six times consecutively within 5 minutes when the client attempts to set up an SSH connection with the SSH server, the IP address of the client will be locked for 5 minutes, and the locked IP address cannot pass authentication. You can run the display ssh server ip-block list command in any view to check clients' IP addresses that are locked due to authentication failures. If the IP address of a client is locked, solve the problem using the following methods:
    • Wait for 5 minutes until the device automatically unlocks the IP address.

    • Run the activate ssh server ip-block ip-address [ vpn-instance vpn-name ] command in the user view to configure the device not to block the locked IP address.

    • Run the ssh server ip-block disable command in the system view to disable the SSH server from locking clients' IP addresses. All clients' IP addresses that are locked due to authentication failures then will be unlocked. By default, the function of locking clients' IP addresses is enabled.

  9. Check whether the VTY user interface configuration is correct.

    Before logging in to the device using SSH, configure the VTY user interface to support SSH.
    1. It is required that AAA authentication be used in the VTY user interface to allow users to log in to the device using SSH. The method of checking the current configuration is as follows:
      <SSH Server> display current-configuration | section include authentication-mode
      #  
      user-interface vty 0 4      
           
       user privilege level 3     
       set authentication password cipher $1a$JGX=Zt1Fk2$QOcPN{].z1:[|8D`c3>![.J,<@Uh:ATH^%6>C=*B$  //The ciphertext format provided here is for example only. The format may vary depending on the system software version. 
       idle-timeout 120 0   
      #  
      The preceding command output shows that the current authentication mode of the VTY user interface is password authentication, and needs to be changed to AAA authentication. The configuration method is as follows:
      <SSH Server> system-view
      [~SSH Server] user-interface vty 0 4
      [~SSH Server-ui-vty0-4] authentication-mode aaa
      [*SSH Server-ui-vty0-4] commit
    2. It is required that the VTY user interface support SSH and Telnet or support only SSH to allow users to log in to the device using SSH. By default, the VTY user interface supports Telnet in V100R003C00, and supports SSH and Telnet in V100R003C10 and later versions. The method of checking the current configuration is as follows:
      <SSH Server> display current-configuration | section include protocol inbound
      #    
      user-interface vty 0 4   
       authentication-mode aaa   
       user privilege level 3  
       idle-timeout 120 0      
           
      #
      The preceding command output shows that the protocol supported by the VTY user interface is set to Telnet, and needs to be changed to all protocols or SSH. The configuration method is as follows:
      <SSH Server> system-view
      [~SSH Server] user-interface vty 0 4
      [~SSH Server-ui-vty0-4] protocol inbound all
      [*SSH Server-ui-vty0-4] commit
  10. Check whether the configured SFTP authorization directory is correct.

    If the service type of SSH users is SFTP, you need to configure an authorization directory for the user. If the configured directory does not exist, the user will fail to log in to the SSH server using the SFTP client. By default, the SFTP authorization directory for SSH users is flash:. Confirm the correct authorization directory, and run the ssh user admin sftp-directory command in the system view to configure the correct authorization directory for SSH users.

Translation
Download
Updated: 2020-01-07

Document ID: EDOC1000060766

Views: 615781

Downloads: 2965

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next