SSH login succeeded, but the failure log is printed

Created: Nov 13, 2019 12:06:46Latest reply: Nov 13, 2019 12:19:53 86 2 1 1
  Rewarded Hi-coins: 0 (problem resolved)

Hi guys

Use the switch SSH to log in to the firewall, obviously, the login is successful, but the log prints the login failure log, as shown below, but if you use the PC's SecureCRT, there is no such problem.

Nov
9 2018 17:25:17+08:00 XXXXX %SSH/4/SSH_FAIL(s)[1]:Failed to login through
SSH. (IP=X.X.X.X, VpnInstanceName= , UserName=test, Times=1, FailedReason=User
public key authentication failed)

Thanks


  • x
  • convention:

Featured Answers
jason_hu
Admin Created Nov 13, 2019 12:11:55 Helpful(0) Helpful(0)

Hi friend
The switch does not come with authentication when doing SSH login (for example, password authentication, public)
Key authentication, etc.), based on security considerations, we will send a list of authentication methods to the switch.
Public
The key is the first one. The switch will choose the authentication method. The first authentication method is the public key, but the public is not configured on the firewall.
Key, so the login failed, printed a log of failed login (FailedReason=User public key authentication
Failed)
Then the switch side tries to select the second authentication method, such as password authentication. As a result, the authentication method is configured on the firewall, so the login is successful.

Logging success also has a log, but the log level is 6 (Informational), display
In log buffer, only logs of <=4 (Warning) level are recorded by default, so display
There is no successful login record in the log buffer, but the log of the login is successful in the LOG log of the firewall.
Datacom products have always been implemented this way, including firewalls, switches, and routers. This is not the case if the PC uses the SecureCRT tool to log in to the firewall, because SecureCRT will bring the authentication method when SSH is logged in.

Actually the display from the firewall
You can also see the log of successful login at that point in the trap buffer:
  • x
  • convention:

All Answers
jason_hu
jason_hu Admin Created Nov 13, 2019 12:11:55 Helpful(0) Helpful(0)

Hi friend
The switch does not come with authentication when doing SSH login (for example, password authentication, public)
Key authentication, etc.), based on security considerations, we will send a list of authentication methods to the switch.
Public
The key is the first one. The switch will choose the authentication method. The first authentication method is the public key, but the public is not configured on the firewall.
Key, so the login failed, printed a log of failed login (FailedReason=User public key authentication
Failed)
Then the switch side tries to select the second authentication method, such as password authentication. As a result, the authentication method is configured on the firewall, so the login is successful.

Logging success also has a log, but the log level is 6 (Informational), display
In log buffer, only logs of <=4 (Warning) level are recorded by default, so display
There is no successful login record in the log buffer, but the log of the login is successful in the LOG log of the firewall.
Datacom products have always been implemented this way, including firewalls, switches, and routers. This is not the case if the PC uses the SecureCRT tool to log in to the firewall, because SecureCRT will bring the authentication method when SSH is logged in.

Actually the display from the firewall
You can also see the log of successful login at that point in the trap buffer:
  • x
  • convention:

wissal
wissal MVE Created Nov 13, 2019 12:19:53 Helpful(0) Helpful(0)

Hello,

  1. Check whether the SSH service is enabled on the SSH server.


    Log in to the SSH server through the console port or using Telnet. Run the display ssh server status command to check the SSH server configuration.

    If the STelnet service is disabled, run the stelnet server enable command to enable the STelnet service on the SSH server.


  2. Check the protocol configuration in the VTY user interface view on the SSH server.


    Run the user-interface vty command on the SSH server to display the user interface view. Run the display this command to check whether protocol inbound on the VTY user interface is set to ssh or all(By default, the system supports all protocols). If no, run the protocol inbound { ssh | all } command to enable STelnet users to connect to the device.


  3. Check whether an SSH user is configured on the SSH server.


    Run the display ssh user-information command to view the configuration of the SSH user. If there is no configuration, run the ssh userssh user authentication-typessh user service-type commands in the system view to create an SSH user and configure the SSH user authentication mode and service type.


  4. Check whether the number of users who have logged in to the SSH server reaches the upper limit.


    Log in to the device through a console port. Run the display users command to check whether the current VTY channel is completely occupied. By default, a maximum number of five VTY channels are allowed. You can run the display user-interface maximum-vty command to check the maximum number of users allowed in the current VTY channel.

    If the number of current users has reached the upper limit, run the user-interface maximum-vty 21 command to increase the maximum number of users allowed in the VTY channel to 21.


  5. Check whether an ACL is configured on the user interface of the SSH server.


    Run the user-interface vty command on the SSH server to display the SSH user interface view. Run the display this command to check whether an ACL has been configured on the VTY user interface. If yes, record the ACL number.

    Run the display acl acl-number command on the SSH server to check whether the SSH client IP address is denied in the ACL. If yes, run the undo rule rule-id command in the ACL view to delete the deny rule, and then run the rule permit source source-ip-address soucer-wildcard command in the ACL view to permit the client IP address.


  6. Check the SSH version on the SSH client and server.


    Run the display ssh server status command on the SSH server to check the SSH version.

    If the version is SSHv1, run the ssh server compatible-ssh1x enable command to configure the version compatibility function on the server.


  7. Check whether the first authentication function is enabled on the SSH client.


    Run the display this command in the system view on the SSH client to check whether the first authentication function is enabled on the SSH client.

    If no, an STelnet user fails to log in to the SSH server for the first time because verifying the RSA public key on the SSH server fails. Run the ssh client first-time enable command to enable the first authentication function on the SSH client.

Thanks

  • x
  • convention:

Comment

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login