OpenSSH authentication method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an OpenSSH authentication method and device, electronic equipment and a storage medium, and the method comprises the steps: initiating a first authentication request to a server based on a first communication channel, so as to enable the server to carry out the first authentication of a client; if the first authentication is passed, sending a second authentication request to the server based on a second communication channel, so that the server performs second authentication on the client; the second authentication request carries identity information to be authenticated and comprises a user name to be logged in and a device identifier of the uKey; the registered identity information corresponds to a key pair, the server stores a public key in the key pair, and the uKey stores a private key in the key pair; if the second authentication is passed, establishing connection with the server; if the second authentication passes, the private key stored in the uKey and the public key stored in the server are key pairs corresponding to the registered identity information. The server can be prevented from being illegally operated, and the system security of the server is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an OpenSSH authentication method, device, electronic device, and storage medium. Background Art

[0002] OpenSSH is a free and open source implementation of the SSH (Secure Shell) protocol. The SSH protocol family can be used for remote control or to transfer files between computers. In Linux-related systems, OpenSSH consists of two parts: the server and the client. The server is used to start and monitor network services, and the client is used to establish a connection with the server and maintain communication.

[0003] OpenSSH usually uses the following two authentication methods: password-based authentication or key-based authentication. Password-based authentication requires entering a password (i.e., a password) each time a connection is established. This is not only cumbersome to operate, but also easy to crack, and has low security. Key-based authentication requires generating a pair of keys in advance. The private key is used as an authentication credential and saved on the client. The public key is copied to the server that you want to log in remotely and used to verify the private key. As a result, you do not need to enter a password each time a connection is established, and security is also higher.

[0004] However, even if a key-based authentication method is used, it is impossible to verify whether the operator has the operating authority for the person operating the client, and it is impossible to ensure whether the server is illegally operated, making it difficult to ensure the system security of the server.

[0005] Application Contents

[0006] In view of the above problems, an embodiment of the present application provides an OpenSSH authentication method that overcomes the above problems or at least partially solves the above problems, which can prevent the server from being illegally operated and improve the system security of the server.

[0007] Correspondingly, the embodiment of the present application also provides an OpenSSH authentication device, an electronic device, and a storage medium to ensure the implementation and application of the above method.

[0008] In a first aspect, an embodiment of the present application discloses an OpenSSH authentication method, which is applied to a client, wherein the client is plugged with a uKey, and the method comprises:

[0009] Initiating a first authentication request to the server based on the first communication channel, so that the server performs a first authentication on the client;

[0010] If the first authentication is passed, a second authentication request is sent to the server based on the second communication channel, so that the server performs a second authentication on the client; the second authentication request carries the identity information to be authenticated, and the identity information includes the user name to be logged in and the device identifier of the uKey; the registered identity information corresponds to a key pair, the public key in the key pair is stored in the server, and the private key in the key pair is stored in the uKey;

[0011] If the second authentication passes, a connection is established with the server; the passing of the second authentication indicates that the private key stored in the uKey and the public key stored in the server are a key pair corresponding to the registered identity information.

[0012] In a second aspect, an embodiment of the present application discloses an OpenSSH authentication method, which is applied to a server, and the method includes:

[0013] In response to a first authentication request initiated by the client based on the first communication channel, performing a first authentication on the client;

[0014] In the case where the first authentication is passed, in response to a second authentication request initiated by the client based on the second communication channel, a second authentication is performed on the client; the second authentication request carries identity information to be authenticated, and the identity information includes the user name to be logged in and the device identifier of the uKey inserted by the client; the registered identity information corresponds to a key pair, the public key in the key pair is stored in the server, and the private key in the key pair is stored in the uKey;

[0015] If the second authentication passes, a connection is established with the client; the passing of the second authentication indicates that the private key stored in the uKey matches the public key corresponding to the registered identity information stored in the server.

[0016] In a third aspect, an embodiment of the present application discloses an OpenSSH authentication device, which is applied to a client, wherein the client is plugged with a uKey, and the device comprises:

[0017] A first authentication module of the client, configured to initiate a first authentication request to the server based on the first communication channel, so that the server performs a first authentication on the client;

[0018] The second authentication module of the client is used for sending a second authentication request to the server based on the second communication channel if the first authentication is passed, so that the server performs a second authentication on the client; the second authentication request carries the identity information to be authenticated, and the identity information includes the user name to be logged in and the device identification of the uKey; the registered identity information corresponds to a key pair, the public key of the key pair is stored in the server, and the private key of the key pair is stored in the uKey;

[0019] The client connection establishment module is used to establish a connection with the server if the second authentication is passed; the passing of the second authentication indicates that the private key stored in the uKey and the public key stored in the server are a key pair corresponding to the registered identity information.

[0020] In a fourth aspect, an embodiment of the present application discloses an OpenSSH authentication device, which is applied to a server, and the device includes:

[0021] A first authentication module on the server side, configured to perform a first authentication on the client in response to a first authentication request initiated by the client based on the first communication channel;

[0022] The second authentication module of the server is used to perform a second authentication on the client in response to a second authentication request initiated by the client based on the second communication channel when the first authentication passes; the second authentication request carries identity information to be authenticated, and the identity information includes a user name to be logged in and a device identifier of the uKey inserted by the client; the registered identity information corresponds to a key pair, the public key in the key pair is stored in the server, and the private key in the key pair is stored in the uKey;

[0023] The server connection establishment module is used to establish a connection with the client if the second authentication is passed; the second authentication is passed indicating that the private key stored in the uKey matches the public key corresponding to the registered identity information stored by the server.

[0024] In a fifth aspect, an embodiment of the present application discloses an electronic device, comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute the steps of the OpenSSH authentication method as described in any of the above.

[0025] In a sixth aspect, an embodiment of the present application discloses a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the OpenSSH authentication method described in any one of the embodiments of the present application can be implemented.

[0026] The OpenSSH authentication method, device, electronic device, and storage medium provided by the embodiments of the present application have the following advantages:

[0027] This application maintains the original authentication (first authentication) process of OpenSSH, adds a new authentication communication channel, and adds the identity authentication (second authentication) process of this application, so that OpenSSH authentication has a higher security authentication level than the original OpenSSH. This application performs the second authentication by inserting uKey on the client. The uKey has been registered on the server. The client can pass the second authentication only after inserting the uKey, and then establish a connection with the server and log in to access the server. This application registers uKey on the server to bind uKey to the server, thereby limiting the operator of uKey to only access the registered and bound server, avoiding unauthorized access to the server system by unauthorized personnel, and thus improving the system security of the server. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 This is a flowchart of the steps of an OpenSSH authentication method embodiment of the present application;

[0029] Figure 2 This is a schematic diagram of a process of establishing a connection between a client and a server through OpenSSH in this application;

[0030] Figure 3 It is a flowchart of the steps of another OpenSSH authentication method embodiment of the present application;

[0031] Figure 4 It is a structural block diagram of an OpenSSH authentication device embodiment of the present application;

[0032] Figure 5 It is a structural block diagram of another OpenSSH authentication device embodiment of the present application;

[0033] Figure 6 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0035] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally a class, and the number of objects is not limited. For example, the first object can be one or more. In addition, the term "and / or" in the specification and claims is used to describe the association relationship of associated objects, indicating that three kinds of relationships can exist, for example, A and / or B can be represented: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the front and back associated objects are a kind of "or" relationship. In the embodiment of the present application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0036] Figure 1 A flowchart of an OpenSSH authentication method embodiment of the present application is shown. The method is applied to a client, and the client is plugged with uKey. The method may include the following steps:

[0037] Step 101: Initiate a first authentication request to a server based on a first communication channel, so that the server performs a first authentication on the client;

[0038] Step 102: If the first authentication is passed, a second authentication request is sent to the server based on the second communication channel, so that the server performs a second authentication on the client; the second authentication request carries the identity information to be authenticated, and the identity information includes the user name to be logged in and the device identifier of the uKey; the registered identity information corresponds to a key pair, the public key in the key pair is stored in the server, and the private key in the key pair is stored in the uKey;

[0039] Step 103: If the second authentication is passed, a connection is established with the server; the passing of the second authentication indicates that the private key stored in the uKey and the public key stored in the server are a key pair corresponding to the registered identity information.

[0040] In specific implementation, the implementation of OpenSSH includes a client and a server. The client uses the SSH (Secure Shell) service to log in to other computers remotely in an encrypted manner. SSH is usually run as a command line tool on the client computer. The server uses the SSHD (Secure Shell Daemon) service. SSHD is the server-side implementation of the SSH protocol, which runs on the target server (the server for remote login) and listens for connection requests from the client.

[0041] SSH is a client tool that runs on the computer that initiates the connection and is used to initiate the connection; SSHD is a server-side daemon that runs on the target server that receives the connection and is used to receive and manage the connection.

[0042] The implementation process of OpenSSH is as follows:

[0043] Step 1: The client initiates a connection request: The user runs the SSH client on the local computer and enters the "sshuser@hostname" command to request a connection. Among them, user is the user name on the target server, and hostname is the host name or IP address of the target server.

[0044] Step 2: The server receives the connection request: SSHD on the target server listens to the connection request and starts processing the authentication.

[0045] Step 3, Authentication process: SSHD verifies the credentials (such as password, key, etc.) provided by the client and decides whether to allow the connection.

[0046] Step 4: Establish a session: Once the authentication is successful, SSHD will create a session for the client, through which the client can execute remote commands or management tasks.

[0047] The above step 3 is a common authentication method of OpenSSH in the related art, which is authenticated by a password or a key. This authentication is the first authentication in this application. On the basis of the first authentication, this application adds a second authentication to verify whether the operator has the operation authority, prevent the target server from being illegally operated by unrelated personnel, and further improve the security of the target server.

[0048] In an embodiment of the present application, after the above steps 1 to 3 are executed, the client sends a second authentication request to the server, so that the server performs a second authentication on the client, and the connection is established only after the second authentication passes; the second authentication request carries the identity information to be authenticated, so that the server authenticates the client.

[0049] In an embodiment of the present application, the first authentication can be performed through a first communication channel, and the second authentication can be performed through a second communication channel. The second communication channel and the first communication channel can be different communication channels. Since the first authentication is the original authentication process of OpenSSH, and the first communication channel is the communication channel used by the original authentication process of OpenSSH, this application adds a second authentication after the first authentication is passed, so a second communication channel different from the first communication channel is used. The second communication channel is a newly added communication channel, which can be a newly opened communication space.

[0050] The embodiment of the present application adds a new communication channel (called the second communication channel) in the protocol communication part of the OpenSSH source code, for example, the channel protocol number is 106, and the second communication channel can be used exclusively for uKey to perform the second authentication interaction. The present application adds operations for implementing the interaction based on the second communication channel in the source code of the client and the server, so that both the client and the server support the second communication channel.

[0051] This application adds a new authentication communication channel, and can add the identity authentication (second authentication) process of this application on the basis of maintaining the original authentication (first authentication) process of OpenSSH. In addition, this application adds the second authentication on the basis of the first authentication, and has a higher security authentication level than the original OpenSSH.

[0052] uKey, also known as USB Key, is a small storage device that is directly connected to the computer via USB (Universal Serial Bus), has password verification function, and is reliable and high-speed. It is mainly used as a hardware carrier for secure storage of digital certificates and private keys, and can perform encryption operations in hardware.

[0053] After the user initiates a connection to the server through the client, the second authentication added in this application is used to verify the identity information to be logged in. The client is inserted with uKey. If the identity information to be logged in has been registered on the server using the uKey, that is, the identity information to be logged in is the registered identity information, then the registered identity information corresponds to a key pair, the public key in the key pair is stored on the server, and the private key in the key pair is stored in the uKey. If it is verified that the private key stored in the uKey matches the public key stored in the server, it is determined that the identity information to be logged in is the registered identity information, and the second authentication is passed. After the second authentication is passed, the client and the server can establish a connection (session).

[0054] In the embodiment of the present application, the uKey may be a domestically produced uKey that supports national encryption algorithms, such as sm1, sm2, etc. The key pair corresponding to the registered identity information may be generated by uKey calling the national encryption algorithm.

[0055] Before the user initiates a connection to the server through the client, he needs to register with the server using his uKey to register (bind) his identity information to the uKey on the server. Thus, the user inserts the uKey into the client, initiates a connection to the server where the uKey has been registered through the client, and can establish a connection with the server after passing the first authentication and the second authentication.

[0056] The process of registering the identity information of uKey on the server side can be as follows: insert uKey on the server side and call the preset registration instruction. The parameters of the registration instruction include the user information to be registered and the specified path, and the user information to be registered includes the user name to be registered and the device identification of the uKey. The registration instruction will call the preset national encryption algorithm to generate a key pair corresponding to the user information to be registered, save the public key in the key pair to the specified path in the server side, and save the private key in the key pair in the uKey.

[0057] It should be noted that the client in this application refers to the terminal device running SSH, and the terminal device running SSH is sometimes referred to as the client in this application. The server in this application refers to the SSHD running on the target server, and the target server running SSHD is sometimes referred to as the server in this application.

[0058] In the embodiment of the present application, the server is used to register uKey and generate a key pair corresponding to the server and the registered user information bound to the uKey. The public key in the key pair is stored in the server, and the private key is stored in uKey. The client performs the second authentication by inserting uKey, and can log in to the server system after passing the second authentication.

[0059] For example, user A holds uKey, and user A inserts uKey to server A for registration. User A inserts uKey into client A, and initiates a connection to server A through client A. After both the first authentication and the second authentication are passed, the connection can be successfully established. However, user B initiates a connection to server A through client A without uKey, and fails to pass the second authentication after passing the first authentication, and thus cannot successfully establish a connection.

[0060] In a specific implementation, the holder of the uKey (such as user A) can be a knowledgeable person, and a knowledgeable person refers to a person who has the authority to manage / access the specified operating system. In this way, it can be ensured that the operator of the client is a knowledgeable person, and the system with high-level security can be prevented from being accessed by irrelevant personnel, thereby improving system security.

[0061] Furthermore, the present application can support binding one uKey to one username, and the registered user information can be uniquely identified by "uKey identifier + username". If you need to use the root user to remotely log in to the target server, the username is "root"; if you need to use the test user to remotely log in to the target server, the username is "test". For example, uKey1 and uKey2 are two different uKeys. uKey1 is used to register on the server A, and the registered username is "root". After the registration is completed, the registered user information can be expressed as "uKeyl's identifier + root", and the public key in the key pair corresponding to "uKeyl's identifier + root" (such as recorded as public key 1) is saved on the server A, and the private key in the key pair corresponding to "uKeyl's identifier + root" (such as recorded as private key 1) is saved in uKeyl. Insert uKeyl into the client, and verify that public key 1 and private key 1 match in the second authentication process, that is, public key 1 and private key 1 can form a key pair, then the root user can be used to remotely log in to the server A. You can only log in to the server A remotely using uKeyl, and you can only log in using the root user.

[0062] For another example, if uKey2 is used to register on server B, and the registered user name is root, then after the registration is completed, the registered user information can be expressed as "uKey2's ID + root", and the public key in the key pair corresponding to "uKey2's ID + root" (such as recorded as public key 2) is saved on server B, and the private key in the key pair corresponding to "uKey2's ID + root" (such as recorded as private key 2) is saved in uKey2. Insert uKey2 into the client, and verify in the second authentication process that public key 2 and private key 2 match, that is, public key 2 and private key 2 can form a key pair, then the root user can be used to remotely log in to server B. You can only remotely log in to server B using uKey2, and you can only log in using the root user.

[0063] In the above example, inserting uKey1 into the client allows the root user to remotely log in to server A, but not to server B. Inserting uKey2 into the client allows the root user to remotely log in to server B, but not to server A. Thus, the authority of the client operator can be controlled through uKey and the second authentication.

[0064] Furthermore, the present application can set a server to only allow one username to be registered once. For example, if uKey1 has registered username "root" on server A, when uKey2 registers username "root" on server A, the registration will not be completed; or after uKey2 registers username "root" on server A, the username "root" registered by uKey1 will become invalid. In this way, it can be avoided that multiple users use different uKeys to log in to the same server with the same username at the same time, and the system security of the server can be further guaranteed.

[0065] The present application does not impose any restrictions on the operating systems of the devices where the client and the server are located. The OpenSSH authentication method of the present application can be applied to the Linux operating system or the Windows operating system.

[0066] In an optional embodiment of the present application, after sending the second authentication request to the server in step 102, the method may further include:

[0067] Step S11, receiving the public key returned by the server in response to the second authentication request; after receiving the second authentication request, if the server detects that the identity information carried in the second authentication request has been registered on the server, the server returns the public key corresponding to the identity information;

[0068] Step S12: Open the uKey based on the public key returned by the server. If the opening is successful, send a verification request to the server.

[0069] Step S13, receiving a random string returned by the server in response to the verification request;

[0070] Step S14: Use the private key in the uKey to digitally sign the random string to obtain signature data, and send the signature data to the server, so that the server verifies the signature data using its stored public key; if the signature data is verified, it means that the second authentication is passed.

[0071] The second authentication of this application can realize two-way authentication between the client and the server.

[0072] When the client wants to remotely log in to the server, it first needs to pass the first authentication. After passing the first authentication, the client sends a second authentication request to the server based on the newly added 106 channel. The second authentication request carries the identity information to be authenticated, such as "uKey1's identifier + root".

[0073] After receiving the second authentication request, the server queries the system whether there is any registered identity information that matches the identity information to be authenticated. If it is found that the registered identity information "uKey1's identifier + root" exists in the system, the server returns the public key (such as public key 1) corresponding to "uKey1's identifier + root" to the client.

[0074] After the client receives the public key returned by the server, it performs an open operation on the uKey inserted by the client based on the public key. If the opening is successful, it means that the public key matches the private key in the uKey (can form a key pair), and the public key is verified. The client sends a verification request to the server, indicating that the public key has been verified, to request the server to verify the client; if the client fails to open the uKey using the public key returned by the server, it means that the public key returned by the server does not match the private key in the uKey, and the public key fails to be verified, and the authentication process is exited. In this way, two-way authentication between the client and the server can be achieved, preventing the client from logging into an insecure server system.

[0075] After receiving the verification request sent by the client, the server returns a randomly generated random string to the client. The client uses the private key in uKey to digitally sign the random string to obtain signature data, and sends the signature data to the server so that the server can verify the signature data using its stored public key (such as public key 1). If the public key stored by the server matches the private key stored in uKey, the signature data can pass the signature verification, otherwise the signature verification will fail.

[0076] If the server successfully verifies the signature data using the public key corresponding to "uKey1's identifier + root" (such as public key 1), it means that the private key stored in the uKey inserted by the client matches the public key stored in the server, and the server successfully authenticates the client, and then the second authentication succeeds. This implements two-way authentication between the client and the server, which can prevent the client from logging into an unsafe server system, and prevent unauthorized users from operating the server system, thereby improving the security of the server and the client.

[0077] It should be noted that, during the second authentication process, the client and the server interact based on the second communication channel, such as the above steps S11 to S14 are all performed based on the second communication channel.

[0078] In an optional embodiment of the present application, the method may further include:

[0079] Step S21, calling a preset application to execute a target instruction, wherein the target instruction carries an instruction type and instruction parameters;

[0080] Step S22: In response to the target instruction, the preset application parses the target instruction, determines the instruction type of the target instruction, and records the instruction parameters;

[0081] Step S23, the preset application determines the target function corresponding to the target instruction according to the instruction type, converts the recorded instruction parameters into formal parameters of the target function, and calls the target function; the target function is a predefined function for operating the uKey.

[0082] The preset application may be a pre-developed application for operating uKey. The present application implements the steps of operating uKey by calling the preset application to execute corresponding instructions. Thus, a single operation or a combined operation on uKey can be completed by using the preset application through one instruction (target instruction).

[0083] For example, a preset application operation uKey can be called through an instruction (such as called the first instruction), thereby realizing the operation of opening uKey. For another example, a preset application operation uKey can be called through an instruction (such as called the second instruction), thereby realizing the operation of verifying the PIN code of uKey. For another example, a preset application operation uKey can be called through an instruction (such as called the third instruction), thereby realizing the operation of verifying the public key returned by the server. For another example, a preset application operation uKey can be called through an instruction (such as called the fourth instruction), thereby realizing the operation of modifying the PIN code of uKey. For another example, a preset application operation uKey can be called through an instruction (such as called the fifth instruction), thereby realizing the operation of registering uKey; and so on.

[0084] Among them, one instruction can implement a combination of operations. For example, opening uKey can be a combination of operations, including PIN code verification and public key verification. For another example, registering uKey can be a combination of operations, including PIN code verification and calling the preset national encryption algorithm to generate a key pair.

[0085] In the embodiment of the present application, the target instruction may include at least any one of the following instructions: a first instruction, a second instruction, a third instruction, a fourth instruction, and a fifth instruction. Exemplarily, the target instruction is in the following form:

[0086] nfs-ukey-project-x xxxxxx

[0087] Among them, "-x" is the instruction type, indicating the function implemented by the instruction; "xxxxxx" is the instruction parameter, which can be a parameter entered by the user, or a parameter passed in by the process calling the instruction, etc. For example, a second instruction can be as follows:

[0088] nfs-ukey-project-pin 111111

[0089] Among them, "-pin" is the command type, indicating that the implemented function is PIN code verification; "111111" is the command parameter, specifically the PIN code to be verified entered by the user.

[0090] A PIN (Personal Identification Number) code is a password used to verify personal identity, usually consisting of numbers. Each ukey can be set with a default PIN code stored in the ukey when it leaves the factory, and the user can modify the PIN code. PIN code verification is required every time the ukey needs to be opened to read the data in the ukey. If the PIN code input interface is displayed, after the user enters the PIN code, the PIN code entered by the user is compared with the PIN code stored in the ukey. The second instruction is used to verify whether the PIN code "111111" entered by the user is consistent with the PIN code stored in the ukey. If the two are consistent, the PIN code verification passes, otherwise the PIN code verification fails.

[0091] The preset application of the present application executes the target instruction by calling the target function, which is a predefined function for operating the uKey, such as a function provided by a uKey manufacturer. Specifically, when the client calls the preset application to execute the target instruction, the preset application parses the target instruction, determines the instruction type of the target instruction (such as "-pin"), and records the instruction parameters (such as "111111").

[0092] This application pre-sets the correspondence between instruction types and target functions in the preset application. For example, for 16 target functions, 16 corresponding instruction types are set. Each instruction type corresponds to a target function and the parameters required by the target function. Each target function is a functional function of ukey. After the preset application is parsed into the instruction type, the corresponding target function can be determined according to the instruction type, and the recorded instruction parameters are converted into the formal parameters of the target function, and then the target function is called.

[0093] For example, the preset application parses the instruction type as "-pin". According to the correspondence between the preset instruction type and the target function, it can be determined that the target function corresponding to the instruction type is ukey_verify_pin, and the parameter of the target function is the PIN code to be verified. Then the recorded instruction parameter "111111" is used as the formal parameter of the target function, and the target function is called, such as calling the target function ukey_verify_pin(111111). The target function reads the PIN code stored in ukey and compares it with the parameter "111111". If the two are consistent, the result of PIN code verification passing is returned, otherwise the result of PIN code verification failing is returned.

[0094] In an embodiment of the present application, when it is necessary to operate ukey to implement a specific function, a preset application can be called to execute a target instruction to implement it, which can reduce the user's operating cost.

[0095] In an optional embodiment of the present application, the opening operation on the uKey based on the public key returned by the server in step S12 may include:

[0096] Step S121: calling a preset application to execute a first instruction, wherein the instruction parameter carried by the first instruction includes the public key returned by the server; the first instruction is used to open the uKey;

[0097] Step S122: In response to the first instruction, the preset application calls a second instruction, where the instruction parameter carried by the second instruction includes a PIN code input by the user; the second instruction is used to verify the PIN code input by the user;

[0098] Step S123, executing the second instruction to compare the PIN code input by the user with the PIN code stored in the uKey; if the two are determined to be consistent, the PIN code verification is passed, otherwise the PIN code verification fails;

[0099] Step 124: If the PIN code verification is successful, a third instruction is called, wherein the instruction parameter carried by the third instruction includes the public key returned by the server; the third instruction is used to verify the public key returned by the server;

[0100] Step 125, executing the third instruction to match the public key returned by the server with the private key stored in the uKey; if it is determined that the two match, the public key verification passes, otherwise the public key verification fails;

[0101] Step 126: If the PIN code verification is passed and the public key verification is passed, the uKey is successfully opened, otherwise the uKey opening fails.

[0102] Taking the case where the present application calls a preset application to execute the first instruction as an example, the execution process may be as follows:

[0103] A1: Call the preset application to execute the first instruction to try to open uKey using the public key returned by the server.

[0104] The first instruction is used to open the uKey. The instruction parameters carried by the first instruction include the public key returned by the server. The instruction type carried by the first instruction is such as "-open".

[0105] A2: Parse the first instruction, obtain the instruction type, and record the instruction parameters.

[0106] For example, the first instruction is as follows:

[0107] nfs-ukey-project-open public key 1

[0108] In the embodiment of the present application, opening uKey is a combined operation, including PIN code verification and public key verification operations. Only when both PIN code verification and public key verification are passed, can uKey be successfully opened. Among them, PIN code verification is used to verify the identity of the operator holding uKey, and public key verification is used to verify the identity of the server.

[0109] A3: Call the second instruction to perform PIN code verification.

[0110] After the preset application parses the command type "-open", it is parsed that the command type is a combined operation. The second command is called first to perform PIN code verification. If the PIN code verification passes, the third command is called to perform public key verification. If the public key verification passes, uKey can be successfully opened. If the PIN code verification fails or the public key verification fails, opening uKey fails.

[0111] The instruction parameter carried by the second instruction includes a PIN code input by the user; the second instruction is used to verify the PIN code input by the user. Specifically, before calling the second instruction, a PIN code input interface can be displayed for the user to input the PIN code, and then the second instruction is called using the PIN code input by the user as the instruction parameter of the second instruction.

[0112] For example, the second instruction is as follows:

[0113] nfs-ukey-project-pin 111111

[0114] The preset application calls the corresponding target function according to the parsed instruction type "-pin", and uses the recorded instruction parameters (such as "111111") as the formal parameters of the target function. The target function compares the received parameters (such as "111111") with the PIN code saved in the uKey; if the two are determined to be consistent, the result of PIN code verification passing is returned, otherwise the result of PIN code verification failing is returned.

[0115] A4: If the PIN code verification is successful, the third instruction is called to perform public key verification.

[0116] After receiving the result of the PIN code verification, the preset application calls the third instruction, which is used for public key verification. The instruction parameter of the third instruction is the public key returned by the server. Exemplarily, the third instruction is as follows:

[0117] nfs-ukey-project-verify_pubkey public key 1

[0118] The preset application calls the corresponding target function according to the parsed instruction type "-verify_pubkey", and uses the recorded instruction parameters (such as "public key 1") as the formal parameters of the target function. The target function matches the received parameters (such as "public key 1") with the private key saved in uKey; if the two are determined to match, the result of public key verification passing is returned, otherwise the result of public key verification failing is returned.

[0119] A5: If the public key verification is successful, uKey is successfully opened.

[0120] If the public key verification is successful, the target function used to open uKey can be called to open uKey.

[0121] Furthermore, after successfully opening the uKey, the device handle of the opened uKey may be recorded so that the device handle may be used to further open the container of the uKey, or the device handle may be used to close the uKey later.

[0122] Furthermore, after the target instruction is executed, the preset application may be exited and related resources occupied by the preset application may be released.

[0123] In an optional embodiment of the present application, the method may further include:

[0124] Step S31, calling a preset application to execute a fourth instruction, wherein the instruction parameters carried by the fourth instruction include an old PIN code and a new PIN code;

[0125] Step S32: In response to the fourth instruction, the preset application changes the old PIN code stored in the uKey to the new PIN code after verifying the old PIN code.

[0126] The fourth instruction is used to modify the PIN code of uKey. For example, the default PIN code of uKey after leaving the factory is "111111". The user can modify the PIN code of uKey by calling a preset application to execute the fourth instruction. Exemplarily, the fourth instruction is as follows:

[0127] nfs-ukey-project-modify_pin old PIN new PIN

[0128] The old PIN code is what the user inputs when he wants to modify the PIN code of uKey through the preset application. The preset application calls the corresponding target function according to the parsed instruction type "-modify_pin" and uses the recorded instruction parameters (such as "old PIN code new PIN code") as the formal parameters of the target function. If the target function determines that the old PIN code is correct, it will modify the old PIN code saved in uKey to the new PIN code and return the result of successful modification.

[0129] Reference Figure 2 , shows a schematic diagram of the process of establishing a connection between a client and a server through OpenSSH in the present application, such as Figure 2 As shown, the following steps are included:

[0130] B1: The client initiates a connection to the server.

[0131] The client has inserted uKey (such as uKey1). The client initiates a first authentication request to the server based on the first communication channel, so that the server performs a first authentication on the client; if the first authentication passes, a second authentication request is sent to the server based on the second communication channel; the second authentication request carries the identity information to be authenticated (such as "uKey1's identifier + root").

[0132] B2: The server returns the public key.

[0133] After receiving the second authentication request, the server first checks whether the public key of the corresponding identity information (such as "uKey1's identifier + root") is saved in the system. If it exists, the public key is returned.

[0134] B3: The client attempts to open uKey using the public key returned by the server.

[0135] After the client receives the public key returned by the server, it performs an open operation on the uKey inserted by the client based on the public key returned by the server. If the opening is successful, it means that the public key matches the private key in the uKey, then the public key passes the verification, and the client sends a verification request to the server.

[0136] B4: uKey is opened successfully, and the client sends a verification request to the server.

[0137] B5: The server returns a random string.

[0138] After receiving the verification request sent by the client, the server returns a randomly generated random string to the client, such as returning a 32-bit random string to the client.

[0139] B6: The client uses the private key in uKey to digitally sign the random string.

[0140] The client uses the private key in uKey (such as private key 1) to digitally sign the random string to obtain signature data, and sends the signature data to the server so that the server verifies the signature data using the public key it stores (such as public key 1).

[0141] B7: The server uses the stored public key to verify the signature data.

[0142] The server uses the stored public key (such as public key 1) to verify the signature of the received signature data. If the verification is successful, the server sends a successful authentication message. The uKey login authentication process is completed and the client can remain connected for a long time.

[0143] B8: The signature verification is successful, and the client establishes and maintains a connection with the server.

[0144] B9: The client quits the connection.

[0145] The client can actively exit the connection when it does not need to maintain communication with the server, or directly exit the connection when a certain process of uKey login authentication fails.

[0146] Reference Figure 3 , shows a flowchart of the steps of another OpenSSH authentication method embodiment of the present application, applied to the server, the method may include:

[0147] Step 301: In response to a first authentication request initiated by a client based on a first communication channel, perform a first authentication on the client;

[0148] Step 302: If the first authentication is passed, in response to a second authentication request initiated by the client based on the second communication channel, a second authentication is performed on the client; the second authentication request carries identity information to be authenticated, and the identity information includes the user name to be logged in and the device identifier of the uKey inserted by the client; the registered identity information corresponds to a key pair, the public key in the key pair is stored in the server, and the private key in the key pair is stored in the uKey;

[0149] Step 303: If the second authentication is passed, a connection is established with the client; the passing of the second authentication indicates that the private key stored in the uKey matches the public key corresponding to the registered identity information stored in the server.

[0150] The implementation of OpenSSH includes a client and a server. The relevant operations of the server have been described in detail in the above embodiments, and the repeated parts will not be repeated here, and can be referred to each other.

[0151] In an optional embodiment of the present application, the second authentication of the client in step 302 may include:

[0152] Step S41: if it is detected that the identity information carried in the second authentication request has been registered on the server, then a public key corresponding to the identity information is returned;

[0153] Step S42, receiving a verification request sent by the client; the verification request is sent by the client when the opening operation on the uKey is successfully performed based on the public key returned by the server;

[0154] Step S43: In response to the verification request, sending a random string to the client;

[0155] Step S44, receiving the signature data sent by the client; the signature data is obtained by the client using the private key in the uKey to digitally sign the random string;

[0156] Step S45: Use the saved public key to verify the signature data. If the signature data is verified successfully, it is determined that the second authentication is successful.

[0157] In an optional embodiment of the present application, the server is plugged with uKey, and the method may further include:

[0158] Step S51, calling a preset application to execute a fifth instruction, wherein the instruction parameters carried by the fifth instruction include user information to be registered and a specified path, and the user information to be registered includes a user name to be registered and a device identifier of the uKey;

[0159] Step S52, in response to the fifth instruction, the preset application calls the preset national encryption algorithm to generate a key pair corresponding to the user information to be registered, saves the public key in the key pair to the specified path in the server, and saves the private key in the key pair in the uKey.

[0160] In a specific implementation, insert uKey into the server, and operate uKey through a preset application to realize the registration function. Specifically, the preset application can be called to execute the fifth instruction to realize the registration of uKey. Exemplarily, the fifth instruction can be as follows:

[0161] nfs-ukey-project-import_cert xxxxxx

[0162] The command type "-import_cert" indicates registering user information. The command parameter "xxxxxx" includes the user information to be registered and the specified path. The user information to be registered includes the user name to be registered and the device identifier of the uKey. For example, if uKey1 is inserted into the server, the user information to be registered is "uKey1 identifier + root".

[0163] The preset application calls the corresponding target function according to the parsed instruction type "-import_cert", and uses the recorded instruction parameters (such as "uKey1's identifier + root" and the specified path) as the formal parameters of the target function. The target function calls the preset national encryption algorithm to generate a key pair corresponding to the user information to be registered (such as "uKey1's identifier + root"), saves the public key in the key pair to the specified path in the server, and saves the private key in the key pair in the uKey (uKey1) inserted by the server.

[0164] Furthermore, the instruction parameter of the fifth instruction may also include a PIN code entered by the user. Before the preset application calls the target function to generate the key pair, it may display a PIN input interface for the user to enter the PIN code, and verify the PIN code entered by the user. If the PIN code verification passes, the target function is called to generate the key pair and the registration process is completed; if the PIN code verification fails, it means that the user illegally holds the uKey, and the registration fails.

[0165] In summary, this application maintains the original authentication (first authentication) process of OpenSSH, adds a new authentication communication channel, and adds the identity authentication (second authentication) process of this application, so that OpenSSH authentication has a higher security authentication level than the original OpenSSH. This application performs the second authentication by inserting uKey on the client. The uKey has been registered on the server. The client can pass the second authentication only after inserting the uKey, and then establish a connection with the server and log in to access the server. This application registers uKey on the server to bind uKey to the server, thereby limiting the operator of uKey to only access the registered and bound server, avoiding unauthorized access to the server system by unauthorized personnel, and thus improving the system security of the server.

[0166] In addition, this application does not require manual configuration of certificates. By calling the target instructions through the preset application, the registration process can be completed, the public key in the key pair corresponding to the registered user information can be saved to the specified path of the server, and the private key can be saved to uKey. The entire process only requires the operator to enter one instruction to complete, which can reduce the operator's operating costs.

[0167] Furthermore, this application adds source code for supporting domestically produced uKey in the source code of the client and server, so that this application can support domestically produced uKey. A new communication channel is added to openssh to support the authentication process of domestically produced uKey, and domestically produced uKey can use state-owned encryption algorithms such as sm1 and sm2 to generate encryption key pairs.

[0168] Finally, the second authentication security strength of this application is higher. The domestic uKey is inserted into the operator's machine, that is, the client, which can greatly ensure that the operator is a knowledgeable person, and the client and the server can only log in to the target server system after successful interactive authentication (two-way authentication), which can further ensure the system security of the target server and improve the system security of the client.

[0169] It should be noted that, for the method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present application are not limited by the described order of actions, because according to the embodiments of the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present application.

[0170] Reference Figure 4, shows a structural block diagram of an OpenSSH authentication device embodiment of the present application, the device is applied to a client, the client is plugged with uKey, and the device may include:

[0171] The client first authentication module 401 is used to initiate a first authentication request to the server based on the first communication channel, so that the server performs a first authentication on the client;

[0172] The client second authentication module 402 is used to send a second authentication request to the server based on the second communication channel if the first authentication is passed, so that the server performs a second authentication on the client; the second authentication request carries the identity information to be authenticated, and the identity information includes the user name to be logged in and the device identifier of the uKey; the registered identity information corresponds to a key pair, the server stores the public key of the key pair, and the uKey stores the private key of the key pair;

[0173] The client connection establishment module 403 is used to establish a connection with the server if the second authentication is passed; the passing of the second authentication indicates that the private key stored in the uKey and the public key stored in the server are a key pair corresponding to the registered identity information.

[0174] Optionally, the second authentication module of the client includes:

[0175] a public key receiving submodule, configured to receive the public key returned by the server in response to the second authentication request; after receiving the second authentication request, if the server detects that the identity information carried in the second authentication request has been registered on the server, the server returns the public key corresponding to the identity information;

[0176] A public key verification submodule, used to perform an opening operation on the uKey based on the public key returned by the server, and if the opening is successful, send a verification request to the server;

[0177] A character string receiving submodule, used to receive a random character string returned by the server in response to the verification request;

[0178] The digital signature submodule is used to digitally sign the random string using the private key in the uKey to obtain signature data, and send the signature data to the server so that the server can verify the signature data using the public key it stores; if the signature data is verified, it means that the second authentication is passed.

[0179] Optionally, the device further comprises:

[0180] The authentication exit module is used to exit the process of the second authentication request if the opening fails after performing an opening operation on the uKey based on the public key returned by the server.

[0181] Optionally, the public key verification submodule includes:

[0182] A first operation unit, configured to call a preset application to execute a first instruction, wherein the instruction parameter carried by the first instruction includes the public key returned by the server; the first instruction is used to open the uKey;

[0183] a second operating unit, configured to respond to the first instruction, the preset application calling a second instruction, the instruction parameter carried by the second instruction including a PIN code input by a user; and the second instruction is configured to verify the PIN code input by the user;

[0184] a third operating unit, configured to execute the second instruction to compare the PIN code input by the user with the PIN code stored in the uKey; if the two are determined to be consistent, the PIN code verification is successful, otherwise the PIN code verification is unsuccessful;

[0185] A fourth operation unit, configured to call a third instruction if the PIN code verification is successful, wherein the instruction parameter carried by the third instruction includes the public key returned by the server; and the third instruction is configured to verify the public key returned by the server;

[0186] The fifth operation unit is used to execute the third instruction to match the public key returned by the server with the private key stored in the uKey; if the two are determined to match, the public key verification passes, otherwise the public key verification fails; if the PIN code verification passes and the public key verification passes, the uKey is successfully opened, otherwise the opening of the uKey fails.

[0187] Optionally, the device further comprises:

[0188] The PIN code modification module is used to call a preset application to execute a fourth instruction, and the instruction parameters carried by the fourth instruction include an old PIN code and a new PIN code; in response to the fourth instruction, the preset application modifies the old PIN code saved in the uKey to the new PIN code after verifying the old PIN code.

[0189] Optionally, the device further comprises:

[0190] An instruction calling module, used to call a preset application to execute a target instruction, wherein the target instruction carries an instruction type and instruction parameters;

[0191] an instruction parsing module, configured to, in response to the target instruction, parse the target instruction by the preset application, determine the instruction type of the target instruction, and record the instruction parameters;

[0192] A function calling module is used for the preset application to determine the target function corresponding to the target instruction according to the instruction type, and to convert the recorded instruction parameters into formal parameters of the target function, and call the target function; the target function is a predefined function used to operate the uKey.

[0193] Optionally, the key pair corresponding to the registered identity information is generated using a preset national encryption algorithm.

[0194] Reference Figure 5 , shows a structural block diagram of another OpenSSH authentication device embodiment of the present application, the device is applied to the server, and the device may include:

[0195] The server first authentication module 501 is used to perform a first authentication on the client in response to a first authentication request initiated by the client based on the first communication channel;

[0196] The server-side second authentication module 502 is used to perform a second authentication on the client in response to a second authentication request initiated by the client based on the second communication channel when the first authentication passes; the second authentication request carries identity information to be authenticated, and the identity information includes the user name to be logged in and the device identifier of the uKey inserted by the client; the registered identity information corresponds to a key pair, the server stores the public key in the key pair, and the uKey stores the private key in the key pair;

[0197] The server connection establishment module 503 is used to establish a connection with the client if the second authentication is passed; the second authentication is passed indicating that the private key stored in the uKey matches the public key corresponding to the registered identity information stored by the server.

[0198] Optionally, the second authentication module on the server side includes:

[0199] A public key returning submodule, configured to return a public key corresponding to the identity information if it is detected that the identity information carried in the second authentication request has been registered on the server;

[0200] A verification receiving submodule, used for receiving a verification request sent by the client; the verification request is sent when the client successfully performs an opening operation on the uKey based on the public key returned by the server;

[0201] A string returning submodule, used for sending a random string to the client in response to the verification request;

[0202] A signature receiving submodule, used to receive signature data sent by the client; the signature data is obtained by the client digitally signing the random string using the private key in the uKey;

[0203] The signature verification submodule is used to verify the signature data using the stored public key, and if the signature data is verified successfully, it is determined that the second authentication is successful.

[0204] Optionally, the server is plugged with uKey, and the device further comprises:

[0205] The uKey registration module is used to call a preset application to execute a fifth instruction, wherein the instruction parameters carried by the fifth instruction include the user information to be registered and a specified path, wherein the user information to be registered includes the user name to be registered and the device identifier of the uKey; in response to the fifth instruction, the preset application calls a preset national encryption algorithm to generate a key pair corresponding to the user information to be registered, saves the public key in the key pair to the specified path in the server, and saves the private key in the key pair in the uKey.

[0206] In summary, this application maintains the original authentication (first authentication) process of OpenSSH, adds a new authentication communication channel, and adds the identity authentication (second authentication) process of this application, so that OpenSSH authentication has a higher security authentication level than the original OpenSSH. This application performs the second authentication by inserting uKey on the client. The uKey has been registered on the server. The client can pass the second authentication only after inserting the uKey, and then establish a connection with the server and log in to access the server. This application registers uKey on the server to bind uKey to the server, thereby limiting the operator of uKey to only access the registered and bound server, avoiding unauthorized access to the server system by unauthorized personnel, and thus improving the system security of the server.

[0207] In addition, this application does not require manual configuration of certificates. The server can complete the registration process by calling the target command through the preset application, save the public key in the key pair corresponding to the registered user information to the specified path of the server, and save the private key to uKey. The entire process only requires the operator to enter one command to complete, which can reduce the operator's operating costs.

[0208] Furthermore, this application adds source code for supporting domestically produced uKey in the source code of the client and server, so that this application can support domestically produced uKey. A new communication channel is added to openssh to support the authentication process of domestically produced uKey, and domestically produced uKey can use state-owned algorithms such as sm1 and sm2 to generate encryption key pairs.

[0209] Finally, the second authentication security strength of this application is higher. The domestic uKey is inserted into the operator's machine, that is, the client, which can greatly ensure that the operator is a knowledgeable person, and the client and the server can only log in to the target server system after successful interactive authentication (two-way authentication), which can further ensure the system security of the target server and improve the system security of the client.

[0210] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0211] Reference Figure 6 , is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 6 As shown, the electronic device includes: a processor, a memory, a communication interface and a communication bus, and the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute the steps of the OpenSSH authentication method of the aforementioned embodiment.

[0212] An embodiment of the present application provides a non-transitory computer-readable storage medium. When instructions in the storage medium are executed by a program or processor of a terminal, the terminal is enabled to perform the steps of the OpenSSH authentication method of the aforementioned embodiment.

[0213] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0214] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, devices, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0215] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0216] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing terminal device to operate in a predictable manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0217] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0218] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0219] Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. An OpenSSH authentication method, characterized in that: Applied to a client, the client having a uKey inserted therein, the method comprising: Initiating a first authentication request to the server based on the first communication channel, so that the server performs a first authentication on the client; If the first authentication is passed, a second authentication request is sent to the server based on the second communication channel, so that the server performs a second authentication on the client; the second authentication request carries the identity information to be authenticated, and the identity information includes the user name to be logged in and the device identifier of the uKey; the registered identity information corresponds to a key pair, the public key in the key pair is stored in the server, and the private key in the key pair is stored in the uKey; If the second authentication passes, a connection is established with the server; the passing of the second authentication indicates that the private key stored in the uKey and the public key stored in the server are a key pair corresponding to the registered identity information.

2. The method according to claim 1, characterized in that After sending the second authentication request to the server, the method further includes: receiving the public key returned by the server in response to the second authentication request; after receiving the second authentication request, if the server detects that the identity information carried in the second authentication request has been registered on the server, returning the public key corresponding to the identity information; Perform an opening operation on the uKey based on the public key returned by the server, and if the opening is successful, send a verification request to the server; Receiving a random string returned by the server in response to the verification request; The random string is digitally signed using the private key in the uKey to obtain signature data, and the signature data is sent to the server so that the server verifies the signature data using the public key it stores; if the signature data is verified, it means that the second authentication is passed.

3. The method according to claim 2, characterized in that After performing the opening operation on the uKey based on the public key returned by the server, the method further includes: If the opening fails, the process of the second authentication request is exited.

4. The method according to claim 2, characterized in that: The performing an opening operation on the uKey based on the public key returned by the server includes: Calling a preset application to execute a first instruction, wherein the instruction parameter carried by the first instruction includes the public key returned by the server; the first instruction is used to open the uKey; In response to the first instruction, the preset application calls a second instruction, the instruction parameter carried by the second instruction includes a PIN code input by the user; the second instruction is used to verify the PIN code input by the user; Execute the second instruction to compare the PIN code input by the user with the PIN code stored in the uKey; if the two are determined to be consistent, the PIN code verification is passed, otherwise the PIN code verification fails; If the PIN code verification is successful, a third instruction is called, wherein the instruction parameter carried by the third instruction includes the public key returned by the server; the third instruction is used to verify the public key returned by the server; Execute the third instruction to match the public key returned by the server with the private key stored in the uKey; if the two are determined to match, the public key verification passes, otherwise the public key verification fails; If the PIN code verification passes and the public key verification passes, uKey is successfully opened, otherwise the opening of uKey fails.

5. The method according to claim 1, characterized in that The method further comprises: Calling a preset application to execute a fourth instruction, wherein instruction parameters carried by the fourth instruction include an old PIN code and a new PIN code; In response to the fourth instruction, the preset application changes the old PIN code stored in the uKey to the new PIN code after verifying the old PIN code.

6. The method according to claim 1, characterized in that The method further comprises: Calling a preset application to execute a target instruction, where the target instruction carries an instruction type and instruction parameters; In response to the target instruction, the preset application parses the target instruction, determines the instruction type of the target instruction, and records the instruction parameters; The preset application determines the target function corresponding to the target instruction according to the instruction type, converts the recorded instruction parameters into formal parameters of the target function, and calls the target function; the target function is a predefined function for operating the uKey.

7. The method according to claim 1, characterized in that The key pair corresponding to the registered identity information is generated using a preset national encryption algorithm.

8. An OpenSSH authentication method, characterized in that: Applied to the server, the method includes: In response to a first authentication request initiated by the client based on the first communication channel, performing a first authentication on the client; In the case where the first authentication is passed, in response to a second authentication request initiated by the client based on the second communication channel, a second authentication is performed on the client; the second authentication request carries identity information to be authenticated, and the identity information includes the user name to be logged in and the device identifier of the uKey inserted by the client; the registered identity information corresponds to a key pair, the public key in the key pair is stored in the server, and the private key in the key pair is stored in the uKey; If the second authentication passes, a connection is established with the client; the passing of the second authentication indicates that the private key stored in the uKey matches the public key corresponding to the registered identity information stored in the server.

9. The method according to claim 8, characterized in that The performing a second authentication on the client comprises: If it is detected that the identity information carried in the second authentication request has been registered on the server, returning the public key corresponding to the identity information; Receiving a verification request sent by the client; the verification request is sent when the client successfully performs an opening operation on the uKey based on the public key returned by the server; In response to the verification request, sending a random string to the client; Receive signature data sent by the client; the signature data is obtained by the client digitally signing the random string using the private key in the uKey; The signature data is verified using the stored public key, and if the signature data is verified successfully, it is determined that the second authentication is successful.

10. The method according to claim 8, characterized in that The server is plugged with uKey, and the method further includes: Calling a preset application to execute a fifth instruction, wherein instruction parameters carried by the fifth instruction include user information to be registered and a specified path, wherein the user information to be registered includes a user name to be registered and a device identifier of the uKey; In response to the fifth instruction, the preset application calls the preset national encryption algorithm to generate a key pair corresponding to the user information to be registered, saves the public key in the key pair to the specified path in the server, and saves the private key in the key pair in the uKey.

11. An OpenSSH authentication device, characterized in that: Applied to a client, the client is plugged with uKey, and the device comprises: A first authentication module of the client, configured to initiate a first authentication request to the server based on the first communication channel, so that the server performs a first authentication on the client; The second authentication module of the client is used for sending a second authentication request to the server based on the second communication channel if the first authentication is passed, so that the server performs a second authentication on the client; the second authentication request carries the identity information to be authenticated, and the identity information includes the user name to be logged in and the device identification of the uKey; the registered identity information corresponds to a key pair, the public key of the key pair is stored in the server, and the private key of the key pair is stored in the uKey; The client connection establishment module is used to establish a connection with the server if the second authentication is passed; the passing of the second authentication indicates that the private key stored in the uKey and the public key stored in the server are a key pair corresponding to the registered identity information.

12. An OpenSSH authentication device, characterized in that: Applied to the server, the device comprises: A first authentication module on the server side, configured to perform a first authentication on the client in response to a first authentication request initiated by the client based on the first communication channel; The second authentication module of the server is used to perform a second authentication on the client in response to a second authentication request initiated by the client based on the second communication channel when the first authentication passes; the second authentication request carries identity information to be authenticated, and the identity information includes a user name to be logged in and a device identifier of the uKey inserted by the client; the registered identity information corresponds to a key pair, the public key in the key pair is stored in the server, and the private key in the key pair is stored in the uKey; The server connection establishment module is used to establish a connection with the client if the second authentication is passed; the second authentication is passed indicating that the private key stored in the uKey matches the public key corresponding to the registered identity information stored by the server.

13. An electronic device, characterized in that: include: A processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute the steps of the OpenSSH authentication method as described in any one of claims 1 to 7 or 8 to 10.

14. A readable storage medium, characterized in that: The readable storage medium stores a program or instruction, and when the program or instruction is executed by the processor, the steps of the OpenSSH authentication method according to any one of claims 1 to 7 or 8 to 10 are implemented.

Images