CN115701022A

CN115701022A - Remote login method, device, system and storage medium

Info

Publication number: CN115701022A
Application number: CN202110801348.0A
Authority: CN
Inventors: 姜熙哲
Original assignee: Alibaba Singapore Holdings Pte Ltd
Current assignee: Alibaba Innovation Co
Priority date: 2021-07-15
Filing date: 2021-07-15
Publication date: 2023-02-07

Abstract

The embodiment of the application provides a remote login method, equipment, a system and a storage medium. In a telnet system, the bastion machine may send a signing challenge to the key management server when there is a need for signature verification. The private key required for signing is managed by the key management server, and the signing process is implemented in the key management server. During the signing process, the private key does not need to be transmitted from the key management server to the bastion machine. On the one hand, sensitive private key data do not need to be transmitted, the risk that the private key possibly causes leakage in the transmission process is avoided, on the other hand, the private key data do not need to be stored in the memory of the bastion machine, even if the bastion machine has a safety problem, the private key cannot be caused to be leaked, and the safety of the private key is greatly improved.

Description

Remote login method, device, system and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a remote login method, device, system, and storage medium.

Background

Under the scene of machine operation and maintenance, operation and maintenance personnel need to remotely log in a server. In a traditional login mode, an operation and maintenance person holds a login certificate to log in. The login mode has the defects of weak password strength and easy cracking, and the login voucher is held by an operation and maintenance worker and is difficult to manage.

In one solution, the login credentials of the server are hosted using an offline or on-cloud bastion. The login credentials are hosted in the bastion machine, and when the operation and maintenance user logs in the server, the bastion machine can pull the hosted login credentials to the memory for the operation and maintenance user to use.

However, in the scheme for hosting the login credentials, the bastion machine needs to load the plaintext login credentials into the memory, so that the risk of the login credentials being leaked is greatly increased, and the security of the hosted login credentials is reduced. Therefore, a solution is yet to be proposed.

Disclosure of Invention

Aspects of the present application provide a method, device, system, and storage medium for remote login, which are beneficial to effectively improving the security of a hosted login credential.

An embodiment of the present application provides a remote login system, including: the user terminal is used for determining a target server to be logged in; the bastion machine is used for acquiring the target server selected by the user terminal and receiving the signature challenge sent by the target server; sending a target public key to be used and the signing challenge to a key management server so that the key management server signs the signing challenge according to a private key corresponding to the target public key, receives a signing result returned by the key management server to the signing challenge, and sends the signing result to the target server for signature verification; the key management server stores a key pair of the target server and is used for signing the signature challenge according to a private key corresponding to the target public key sent by the bastion machine and returning an obtained signature result to the bastion machine; the target server is configured to: and sending a signature challenge to the bastion machine, receiving the signature result returned by the bastion machine, and verifying the signature result according to the target public key.

The embodiment of the application further provides a remote login method, which is suitable for the fortress machine and comprises the following steps: determining a target server selected to be logged in by a user terminal; establishing connection with the target server and receiving a signature challenge sent by the target server; sending a target public key to be used and the signing challenge to a key management server so that the key management server signs the signing challenge according to a private key corresponding to the target public key; receiving a signature result returned by the key management server to the signature challenge; and sending the signature result to the target server for signature verification.

The embodiment of the present application further provides a remote login method, which is applicable to a key management server, and includes: receiving a signature challenge sent by the bastion machine and a target public key to be used; the signing challenge is sent by a target server to be logged in; determining a private key corresponding to the target public key from the stored key pair of the target server; signing the signature challenge by adopting the private key to obtain a signature result; and returning the signature result to the bastion machine so that the bastion machine sends the signature result to the target server for signature verification.

An embodiment of the present application further provides a server, including: a memory, a processor, and a communication component; the memory is to store one or more computer instructions; the processor is to execute the one or more computer instructions to: the steps in the method provided by the embodiments of the present application are performed.

Embodiments of the present application further provide a computer-readable storage medium storing a computer program, where the computer program can implement the steps in the method provided in the embodiments of the present application when executed by a processor.

Embodiments of the present application also provide a computer program, which includes computer program/instructions, wherein when the computer program is executed by a processor, the processor is caused to implement the steps in the method provided by the embodiments of the present application.

In the remote login system provided by the embodiment of the application, when the signature verification requirement exists, the bastion machine can send the signature challenge to the key management server. The private key required for signing is managed by the key management server, and the signing process is implemented in the key management server. During the signing process, the private key does not need to be transmitted from the key management server to the bastion machine. On the one hand, sensitive private key data do not need to be transmitted, the risk that the private key possibly causes leakage in the transmission process is avoided, on the other hand, the private key data do not need to be stored in the memory of the bastion machine, even if the bastion machine has a safety problem, the private key cannot be caused to be leaked, and the safety of the private key is greatly improved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

FIG. 1 is a block diagram of a telnet system according to an exemplary embodiment of the present application;

FIG. 2 is a schematic diagram of a telnet system according to another exemplary embodiment of the present application;

FIG. 3 is a timing diagram illustrating a telnet system according to an exemplary embodiment of the present application;

FIG. 4 is a flowchart illustrating a telnet method according to an exemplary embodiment of the present application;

FIG. 5 is a flowchart illustrating a telnet method according to another exemplary embodiment of the present application;

fig. 6 is a schematic structural diagram of a server according to an exemplary embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Under the scene of machine operation and maintenance, operation and maintenance personnel need to remotely log in a server. In a traditional login mode, operation and maintenance personnel hold login credentials to log in. Wherein, the login credentials refer to a login password or a private key. The login mode has the defects of weak password strength and easy cracking, and the login voucher is held by an operation and maintenance worker and is difficult to manage.

However, in this scheme of hosting login credentials, the bastion machine needs to load the plaintext login credentials into the memory. When the bastion machine is attacked, the plain text login credentials are exposed to the risk of leakage.

In view of the above technical problems, embodiments of the present application provide a solution, and the technical solutions provided by the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

Fig. 1 is a schematic structural diagram of a remote login system according to an exemplary embodiment of the present application, and as shown in fig. 1, the remote login system 100 includes a user terminal 10, a bastion 20, a key management server 30, and a target server 40.

Among them, the user terminal 10 may be implemented as a terminal device providing a function of accessing a server to a user, such as a user-side computer, a tablet computer, a mobile phone, and other intelligent terminals. When logging in the target server 40 through the bastion machine 20, the user terminal 10 needs to designate the target server 40 to be logged in to the cloud bastion machine 20.

The bastion machine 20 is a platform for operation and maintenance of a core system and safety audit management and control, and the platform is realized by a server with a defense function and a safety audit function. The bastion machine 20 is realized based on a Protocol forward proxy, can realize the whole-process recording of data streams of common operation and maintenance protocols such as a Secure Shell Protocol (SSH), a Windows remote desktop, a Secure File Transfer Protocol (SFTP) and the like in a forward proxy mode, and performs video playback in a Protocol data stream recombination mode to achieve the date of operation and maintenance audit. When different user terminals initiate requests to the server, the requests can be subjected to security audit through the bastion machine. In the process of security audit, the bastion machine can perform security audit on the request initiated by the user terminal according to a set audit strategy and intercept the illegal request. In this embodiment, the fort machine 20 may be provided by a cloud shield, which may also be referred to as a cloud fort machine.

The Key Management server 30 may provide a Key Management Service (KMS). The KMS may provide reliable, secure, compliant data encryption protection capabilities based on a combination of hardware and software. The KMS mainly comprises two functional components of key service and credential steward. The key service provides full escrow and protection of keys, and supports extremely simple data encryption and digital signature based on a cloud native interface. The credential manager provides the credentials with the capabilities of trusteeship encryption, periodic rotation, secure distribution and centralized management, and reduces the security risk caused by configuring static credentials by traditional IT (Internet Technology).

The target server 40 refers to a server that a user wants to access, and the server may be a conventional server, or may be a cloud server, a cloud host, a virtual server, or the like.

In some exemplary embodiments, the user terminal 10 and the bastion machine 20 may communicate with each other using a wireless communication method based on a mobile network. When the mobile network is connected through communication, the network system of the mobile network may be any one of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 4G + (LTE +), 5G, wiMax, and the like.

In some embodiments, the bastion machine 20, the key management server 30 and the target server 40 may be deployed on a cloud platform, and the bastion machine 20, the key management server 30 and the target server 40 may communicate with each other by using a communication interface provided by the cloud platform, which is not limited in this embodiment.

In the telnet system, the user terminal 10 is mainly used for: determines the target server 40 to be logged in and sends a request to the bastion machine 20 to log in to the target server 40, the login request including an identification of the target server 40.

Wherein, fort machine 20 mainly used: receiving a request sent by the user terminal 10, obtaining the target server 40 selected by the user terminal 10 from the request, and establishing a communication connection with the target server 40. After the bastion 20 establishes communication with the target server 40, data forwarding can be performed between the user terminal 10 and the server 40, that is: the access data of the user terminal 10 is forwarded to the target server 40, and the response result returned by the target server 40 may be forwarded to the user terminal 10, so as to implement the session between the user terminal 10 and the target server 40.

The bastion device 20, upon receiving the request for login to the target server 40 from the user terminal 10, can determine the target public key used for the security verification operation of this login. The target public key may be input by the user through the user terminal 10, may be provided from a hosted public key by the bastion machine 20, or may be provided by the key management server 30, which is not limited in this embodiment.

After the bastion machine 20 establishes a communication connection with the target server 40, a signing challenge (challenge) sent by the target server 40 can be received. Upon receiving the signature challenge, the bastion machine 20 may send the original text of the signature challenge and the target public key to be used to the key management server 30.

The key management server 30 stores the key pair of the target server 40, and upon receiving the target public key, can determine the private key corresponding to the target public key transmitted from the bastion 20 from the stored key pair. Next, the signature challenge sent by the bastion machine 20 is signed with the private key, and the obtained signature result is returned to the bastion machine 20.

After the bastion machine 20 acquires the signature result, the signature result can be sent to the target server 40, and the target server 40 can perform signature verification according to the signature result and can open a session with the bastion machine 20 after the verification is passed.

In this embodiment, when logging in to the server remotely, the asymmetric key is used for verification, so that the security of the login process can be improved. Meanwhile, the private key is managed by the key management server, the signing process is realized in the key management server, and the private key does not need to be transmitted to the bastion machine from the key management server in the signing process. On the one hand, sensitive private key data do not need to be transmitted, the risk that the private key possibly causes leakage in the transmission process is avoided, on the other hand, the private key data do not need to be stored in the memory of the bastion machine, even if the bastion machine has a safety problem, the private key cannot be caused to be leaked, and the safety of the private key is greatly improved.

In some alternative embodiments, the public key is held by the operation and maintenance personnel, and when the operation and maintenance personnel have the requirement of logging in the server, the public key can be provided to the bastion machine 20 through the user terminal 10.

In alternative embodiments, the public key is hosted by the cloud platform, for example, the key management server 30 may be hosted by the bastion machine 20. In the implementation mode of the trusteeship, operation and maintenance personnel do not need to memorize the public key, on one hand, login experience is improved, on the other hand, the public key can be prevented from being in direct contact with the user, better isolation between the login certificate and the user is ensured, and the safety in the login process is further improved.

In the following embodiments, an example will be described in which the key management server 30 hosts the public key of the target server.

Alternatively, the key management server 30 may mass-manage key pairs of a plurality of different servers. The bastion machine 20 may transmit a public key acquisition request to the key management server 30 upon receiving a request for the user terminal 10 to log in to the target server 40. The key management server 30, upon receiving the public key acquisition request, can return managed public key information to the bastion machine 20. After the bastion machine 20 receives the public key information returned by the key management server 30, the target public key to be used can be determined based on the public key information.

Alternatively, upon receiving the public key information, the bastion machine 20 may transmit a message inquiring about the type of the public key supported by the target server 40 when transmitting the request for establishing the communication connection to the target server 40. When the target server 40 sends a signature challenge to the bastion 20, the bastion 20 can be informed of the type of the public key supported by itself. Further, the bastion machine 20 can determine the target public key to be used for this login from the public key information based on the fed-back public key type of the target server 40.

Further alternatively, the bastion machine 20 may cache the public key information in a local designated space after acquiring the public key information from the key management server 30. Namely, public key escrow is performed by the baster 20. When the bastion machine 20 receives the login request of the user terminal 10 again, the public key information can be directly acquired from the designated cache space without requesting the acquisition of the public key information to the key management server 30. Based on the embodiment, the times of requesting the key management server 30 by the bastion machine 20 to acquire the public key information can be reduced, and the operation flow in the login process can be reduced.

Compared with the scheme of storing the key pair in the bastion machine 20 in the prior art, the scheme provided by the embodiment ensures that the private key used for signature does not need to be taken out from the key management server 30 in the signature process, the possibility of private key leakage does not exist in the processes of the bastion machine 20 and network transmission, and the security performance of the signature private key is greatly improved.

In some exemplary embodiments, as shown in figure 2, the bastion machine 20 includes: an SSH client 201 and a Self-implemented SSH proxy component 202 (Self-instantiated SSH Agent). Wherein the SSH client 201 is implemented as an SSH client application running on the bastion 20. Wherein SSH agent component 202 may be implemented as a plug-in running on bastion machine 20. The remote login system provided by the embodiment of the present application will be further exemplified with reference to the schematic structure of fig. 2 and the timing chart shown in fig. 3.

As shown in fig. 3, when a user (e.g., an operation and maintenance user) has a request to log in to a remote server, a login request may be initiated through the user terminal 10. The user terminal 10 may send a request message for logging into the target server to the SSH client 201 of the bastion machine 20.

After receiving the request message of the user terminal 10, the SSH client 201 may send a request for establishing a connection to the SSH proxy component 202. The SSH proxy component 202 may send an identity obtaining REQUEST (i.e., SSH _ AGENTC _ REQUEST _ IDENTITIES REQUEST) to the SSH client 201, and the SSH client 201 may also send an identity obtaining REQUEST to the SSH proxy component 202 to REQUEST to obtain the identity of the other party and establish a connection.

After the SSH proxy component 202 establishes a connection with the SSH client 201, it can assist the user terminal to perform a signature verification operation before the server logs in. As shown in fig. 3, after receiving the identity obtaining request sent by the SSH client 201, the SSH proxy component 202 does not search the local memory for the key used for signing, but sends a message (Fetch Public Keys) requesting to obtain the Public key to the KMS. The public key is not sensitive information, and the way to pull the public key from the KMS can avoid the user from manually adding the public key to the SSH proxy component 202, thereby complicating the login process.

After receiving the public key acquisition request of the SSH proxy component 202, the KMS may return the acquired public key information (Response public keys) according to the standard SSH proxy protocol. The public Key information is returned in a form of (Key blob, comment), the Key blob is a storage structure of the public Key, and the storage structure consists of a standard information header and a section of data which is positioned behind the information header and represents the secret Key. comment is used to indicate remark information of the public key, such as the use of the public key.

After acquiring the public key information from the KMS, the SSH proxy component 202 may send the public key information to the SSH client 201.

Next, SSH client 201 may send a connection request to target server 40 based on the SSH protocol. When the connection request is sent, the obtained public key information may be sent to the target server 40, so that the target server 40 may determine whether a supported public key exists in the public key information. If there is a target public key supported by the target server 40 in the public key information, the target server 40 may return the target public key supported by the target server to the SSH client 201.

To ensure the security of the login operation, the target server 40 may send a signing challenge to the SSH client 201, so that the SSH client 201 returns signing challenge information signed with the private key corresponding to the target public key.

Upon receiving the signature challenge sent by the target server 40, the SSH client 201 may send a signature request to the SSH proxy component 202 along with the target public key supported by the target server 40.

Upon receiving the signing request, the SSH proxy component 202 no longer pulls the private key used by the signature from the local cache, but rather sends the target public key supported by the target server 40 and the signing challenge to the KMS.

After receiving the signing challenge and the target public key supported by the target server 40, the KMS may determine a private key corresponding to the target public key from the stored key pair of the target server 40, and sign the signing challenge using the private key to obtain a signing result. Next, the KMS may return the signing result to the SSH proxy component 202 and send the signing result to the SSH client 201 by the SSH proxy component 202 through a standard SSH Agent protocol interface.

Based on the signature result, SSH client 201 may send a signature verification request to target server 40, and after the signature verification passes, start a tunnel (tunnel) protocol and open a session based on the SSH protocol.

In such an embodiment, the above-described interaction process between the SSH proxy component 202 and the KMS can be implemented through customized programming of the SSH proxy component 202. The SSH Agent component 202 and the SSH client 201 can adopt a standard SSH Agent protocol interface, so that the original functions of the bastion machine 20 are less invasive and easy to migrate.

In addition to the remote login system described in the foregoing embodiments, embodiments of the present application further provide a remote login method, which will be exemplarily described below with reference to the accompanying drawings.

FIG. 4 is a flowchart illustrating a telnet method provided by an exemplary embodiment of the present application, which when executed at the bastion side, may include the steps shown in FIG. 4:

step 401, the bastion machine determines a target server selected by the user terminal to log in.

Step 402, establishing a connection with the target server, and receiving a signature challenge sent by the target server.

Step 403, sending the target public key to be used and the signing challenge to a key management server, so that the key management server signs the signing challenge according to a private key corresponding to the target public key.

Step 404, receiving a signature result returned by the key management server to the signature challenge.

And 405, sending the signature result to the target server for signature verification.

And after receiving the signature result, the target server can verify the signature result by adopting the target public key to be used, and if the verification is passed, the successful login is determined, and the session process after the login is started.

Further optionally, before sending the target public key to be used and the signing challenge to the key management server, the bastion machine may further send a public key obtaining request to the key management server, and receive public key information returned by the key management server according to the public key obtaining request. Based on the public key information, a target public key to be used may be determined. Optionally, when the bastion machine can determine the target public key to be used based on the public key information, the bastion machine can further send the public key information to the target server, so that the target server returns the target public key supported by the target server.

Further optionally, after receiving the public key information returned by the key management server according to the public key obtaining request, the public key information may also be cached in a local designated space for subsequent use. And then. When the bastion machine subsequently receives the request of the user terminal login service again, the request of obtaining the public key information from the key management server is not needed, and the request times are reduced.

In this embodiment, after receiving a request for logging in a target server from a user terminal, the bastion machine may establish a connection with the target server and obtain a signature challenge sent by the target server. The private key required by the signature is managed by the key management server, and the bastion machine can send the signature challenge to the key management server so as to realize the signature process of the private key in the key management server. Furthermore, the private key does not need to be transmitted from the key management server to the bastion machine during the signing process. On the one hand, sensitive private key data do not need to be transmitted, the risk that the private key possibly causes leakage in the transmission process is avoided, on the other hand, the private key data do not need to be stored in the memory of the bastion machine, even if the bastion machine has a safety problem, the private key cannot be caused to be leaked, and the safety of the private key is greatly improved.

Fig. 5 is a flowchart illustrating a telnet method according to another exemplary embodiment of the present application, which when executed on a key management server side, may include the steps shown in fig. 5:

step 501, the key management server receives a signature challenge sent by the bastion machine and a target public key to be used; the signing challenge is sent by the target server to be logged in.

Step 502, determining a private key corresponding to the target public key from the stored key pair of the target server.

And 503, signing the signature challenge by using the private key to obtain a signature result.

And step 504, returning the signature result to the bastion machine so that the bastion machine sends the signature result to the target server for signature verification.

The present embodiment is performed by a key management server that may provide reliable, secure, and compliant data encryption protection capabilities based on a combination of hardware and software. In the key management server, a reliable encryption chip is arranged, and the encryption chip can provide security protection at a hardware level and ensure the security of the key.

In this embodiment, a key management service KMS runs on the key management server, and the KMS can be customized and programmed to provide a private key escrow and a private key signing service.

In this embodiment, based on the key escrow service and the private key signing service provided by the key management server, when the bastion machine has a signing requirement, the target public key to be used and the signing challenge can be sent to the key management server, and the key management server realizes a process of signing the signing challenge according to the escrowed private key. In this embodiment, the key management server may provide a key management service with higher security based on software or hardware, and may effectively ensure the security of the private key. Meanwhile, the key management server completes signature operation, so that sensitive private key data can be prevented from being leaked in the transmission process, and the security of the private key is further improved.

It should be noted that the execution subjects of the steps of the methods provided in the above embodiments may be the same device, or different devices may be used as the execution subjects of the methods. For example, the execution subjects of step 201 to step 204 may be device a; for another example, the execution subject of

steps

201 and 202 may be device a, and the execution subject of step 203 may be device B; and so on.

In addition, in some of the flows described in the above embodiments and the drawings, a plurality of operations are included in a specific order, but it should be clearly understood that the operations may be executed out of the order presented herein or in parallel, and the sequence numbers of the operations, such as 201, 202, etc., are merely used for distinguishing different operations, and the sequence numbers do not represent any execution order per se. Additionally, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel.

It should be noted that, the descriptions of "first", "second", etc. in this document are used for distinguishing different messages, devices, modules, etc., and do not represent a sequential order, nor limit the types of "first" and "second" to be different.

Fig. 6 is a schematic structural diagram of a server according to an exemplary embodiment of the present application, and as shown in fig. 6, the server includes: memory 601, processor 602, and communication component 603.

The memory 601 is used for storing computer programs and may be configured to store other various data to support operations on the server. Examples of such data include instructions for any application or method operating on the server, contact data, phonebook data, messages, pictures, videos, and so forth.

The memory 601 may be implemented by any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

Wherein the server can be implemented as the bastion machine in the telnet system provided by the foregoing embodiment.

When implemented as a bastion machine, a processor 602, coupled to the memory 601, executes computer programs in the memory 601 to: determining a target server selected to log in by a user terminal; establishing a connection with the target server through a communication component 603, and receiving a signature challenge sent by the target server; sending a target public key to be used and the signing challenge to a key management server so that the key management server signs the signing challenge according to a private key corresponding to the target public key; receiving a signature result returned by the key management server to the signature challenge; and sending the signature result to the target server for signature verification.

Further optionally, the processor 602 is further configured to: sending a public key acquisition request to the key management server; receiving public key information returned by the key management server according to the target public key acquisition request; and determining the target public key to be used according to the target public key information.

Further optionally, after receiving the public key information returned by the key management server according to the target public key obtaining request, the processor 602 is further configured to: and caching the target public key information in a local designated space for subsequent use.

Further, as shown in fig. 6, the server further includes: power supply components 604, and the like. Only some of the components are schematically shown in fig. 6, and it is not meant that the server includes only the components shown in fig. 6.

Wherein the communication component 603 is configured to facilitate communication between the device in which the communication component is located and other devices in a wired or wireless manner. The device in which the communication component is located may access a wireless network based on a communication standard, such as WiFi,2G, 3G, 4G, or 5G, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component may be implemented based on Near Field Communication (NFC) technology, radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, ultra Wideband (UWB) technology, bluetooth (BT) technology, and other technologies.

The power supply 604 provides power to various components of the device in which the power supply is located. The power components may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device in which the power component is located.

In the embodiment, after receiving the request of the user terminal for logging in the target server, the bastion machine can establish connection with the target server and acquire the signature challenge sent by the target server. The private key required by the signature is managed by the key management server, and the bastion machine can send the signature challenge to the key management server so as to realize the signature process of the private key in the key management server. Furthermore, the private key does not need to be transmitted from the key management server to the bastion machine during the signing process. On the one hand, sensitive private key data do not need to be transmitted, the risk that the private key possibly causes leakage in the transmission process is avoided, on the other hand, the private key data do not need to be stored in the memory of the bastion machine, even if the bastion machine has a safety problem, the private key cannot be caused to be leaked, and the safety of the private key is greatly improved.

The server shown in fig. 6 may also be implemented as a key management server in the telnet system provided in the foregoing embodiment.

When implemented as a key management server, processor 602 may execute computer programs in memory 601 for: receiving a signature challenge sent by the bastion machine and a target public key to be used; the signing challenge is sent by a target server to be logged in; determining a private key corresponding to the target public key from the stored key pair of the target server; signing the signature challenge by adopting the private key to obtain a signature result; and returning the signature result to the bastion machine so that the bastion machine sends the signature result to the target server for signature verification.

In this embodiment, the key management server is provided with a key escrow service and a private key signing service, when the bastion machine has a signing requirement, the target public key to be used and the signing challenge can be sent to the key management server, and the key management server signs the signing challenge according to the escrow private key. In this embodiment, the key management server may provide a key management service with higher security based on software or hardware, and may effectively ensure the security of the private key. Meanwhile, the key management server completes signature operation, so that sensitive private key data can be prevented from being leaked in the transmission process, and the security of the private key is further improved.

Accordingly, the present application further provides a computer-readable storage medium storing a computer program, where the computer program can implement the steps that can be executed by the server in the foregoing method embodiments when executed.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of another identical element in a process, method, article, or apparatus that comprises the element.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A telnet system, comprising:

a user terminal configured to: determining a target server to be logged in;

fort machine, be used for: acquiring a target server selected by the user terminal, and receiving a signature challenge sent by the target server; sending a target public key to be used and the signing challenge to a key management server so that the key management server signs the signing challenge according to a private key corresponding to the target public key, receives a signing result returned by the key management server to the signing challenge, and sends the signing result to the target server for signature verification;

a key management server storing a key pair of the target server for: signing the signature challenge according to a private key corresponding to the target public key sent by the bastion machine, and returning an obtained signature result to the bastion machine;

the target server is configured to: and sending a signature challenge to the bastion machine, receiving the signature result returned by the bastion machine, and verifying the signature result according to the target public key.

2. The system of claim 1, wherein the bastion machine comprises: an SSH client and an SSH proxy component; the bastion machine is connected with the user terminal and the target server through the SSH client, and is connected with the key management server through the proxy component.

3. The system of claim 1, wherein the fort machine is further configured to: sending a public key acquisition request to the key management server; and receiving public key information returned by the key management server according to the target public key acquisition request, and determining the target public key to be used according to the target public key information.

4. The system of claim 3, wherein the bastion machine is further configured to: and after receiving the target public key information returned by the key management server, caching the target public key information in a specified space.

5. A remote login method is suitable for a bastion machine, and is characterized by comprising the following steps:

determining a target server selected to log in by a user terminal;

establishing connection with the target server and receiving a signature challenge sent by the target server;

sending a target public key to be used and the signing challenge to a key management server so that the key management server signs the signing challenge according to a private key corresponding to the target public key;

receiving a signature result returned by the key management server to the signature challenge;

and sending the signature result to the target server for signature verification.

6. The method of claim 5, further comprising:

sending a public key acquisition request to the key management server;

receiving public key information returned by the key management server according to the target public key acquisition request;

and determining the target public key to be used according to the target public key information.

7. The method according to claim 5, wherein after receiving the public key information returned by the key management server according to the target public key obtaining request, further comprising:

and caching the target public key information in a specified space for subsequent use.

8. A remote login method is suitable for a key management server, and is characterized by comprising the following steps:

receiving a signature challenge sent by the bastion machine and a target public key to be used; the signing challenge is sent by a target server to be logged in;

determining a private key corresponding to the target public key from the stored key pair of the target server;

signing the signature challenge by adopting the private key to obtain a signature result;

and returning the signature result to the bastion machine so that the bastion machine sends the signature result to the target server for signature verification.

9. A server, comprising: a memory, a processor, and a communication component;

the memory is to store one or more computer instructions;

the processor is to execute the one or more computer instructions to: performing the steps of the method of any one of claims 5-8.

10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, is adapted to carry out the steps of the method of any one of claims 5 to 8.

11. A computer program comprising computer programs/instructions, wherein the computer programs, when executed by a processor, cause the processor to carry out the steps of the method of any one of claims 5-8.