System and method for establishing a secure communication in a wireless network

Abstract

The present disclosure relates to a system (100) and a method (400) for establishing secure communication between a central server (102) and a remote server (104) in a wireless network. The method includes determining an availability of a hidden directory in a central server's home directory upon successful login to an edge node of the central server (102) and generating key pairs for secure authentication if a public key file is unavailable within the hidden directory. Furthermore, the method includes verifying the presence of a remote host key in a host file on the central server (102) and adding it to the central server (102) if not available. The method further includes securely transmitting generated public key to the remote server (104), enabling password-less communication between the central server (102) and the remote server (104).

Description

SYSTEM AND METHOD FOR ESTABLISHING A SECURE COMMUNICATION IN A WIRELESS NETWORKTECHNICAL FIELD

[0001] The embodiments of the present disclosure generally relate to the field of wireless networks. More particularly, the present disclosure relates to a system and a method for establishing a secure communication in a wireless network.BACKGROUND OF THE INVENTION

[0002] The subject matter disclosed in the background section should not be assumed or construed to be prior art merely because of its mention in the background section. Similarly, any problem statement mentioned in the background section or its association with the subject matter of the background section should not be assumed or construed to have been previously recognized in the prior art.

[0003] Wireless networks form a backbone of modern communication infrastructure, facilitating exchange of vast amount of data across diverse geographic locations. In the wireless networks, data management serves as a crucial foundation for driving operational efficiencies, enhancing service delivery, and informing strategic decision-making processes. However, an effective management of the data within the wireless networks relies on reliable mechanisms for accessing, transferring, and analyzing raw datasets generated by various network elements.

[0004] One critical aspect of the data management in the wireless networks is extraction and utilization of Fault, Configuration, Accounting, Performance, and Security (FCAPS) data. The FCAPS data represents a comprehensive framework for managing network operations, covering essential areas such as fault detection and resolution, configuration management, accounting for network resource usage, performance monitoring, and ensuring network security. The FCAPS data, generated by individual network elements and management systems, serves as a fundamental dataset for identifying the operational inefficiencies, detectinganomalies, optimizing performance, and improving overall service quality of the wireless networks.

[0005] In addition to the FCAPS data, the wireless networks increasingly incorporate a Radio Intelligent Controller (RIC) functionality, enabling a dynamic control and optimization of radio resources to enhance network performance and responsiveness. The integration of the RIC functionality with the FCAPS data highlights an importance of secure data ingestion mechanisms to support planning and the optimization of a dynamic wireless network.

[0006] Heretofore, in conventional data management methods, accessing and extracting the FCAPS data from disparate sources, such as vendor-specific Element Management Systems (EMS), poses significant challenges. The challenges stem from a distributed nature of the wireless networks, where the network elements are often deployed across remote or geographically dispersed locations. Extracting the FCAPS data supporting the RIC functionality requires establishing secure connections between the RIC and EMS platforms. This involves transmitting sensitive credentials (e.g., login credentials, Application Programming Interface (API) tokens) via potentially untrusted network infrastructures and retrieving the FCAPS data without compromising integrity or confidentiality.

[0007] In absence of robust security measures, transmission of the FCAPS data supporting the RIC functionality is vulnerable to security breaches like interception, eavesdropping, or unauthorized access by malicious entities. The security breaches not only expose sensitive network information but also weaken reliability and trustworthiness of data-driven decision-making processes within telecom organizations. Moreover, an exposure of credentials during data transfer poses a significant risk of theft or misuse of the credentials, potentially leading to the unauthorized access to critical network resources and services.

[0008] In light of aforementioned challenges and limitations associated with the conventional data management methods, there is a need for a secure and a reliablemechanism for establishing a secure communication in the wireless networks, while ensuring compliance with 3 GPP standards and guidelines.SUMMARY

[0009] The following embodiments present a simplified summary in order to provide a basic understanding of some aspects of the present disclosure. This summary is not an extensive overview, and it is not intended to identify key / critical elements or to delineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

[0010] In an aspect of the present disclosure, disclosed herein is a method for establishing a secure communication in a wireless network. The method comprises receiving, by a receiving module of a central server, an access request from a remote server. The access request comprises identity data associated with the remote server. The method further comprises determining, by a determination module, based on the identity data, whether a hidden directory associated with the remote server is available or unavailable in a home directory of the central server. Thereafter, the method comprises determining, by the determination module, whether a public key file associated with the remote server is available or unavailable within the hidden directory upon the determination that the hidden directory is available in the home directory of the central server. Further, the method comprises generating, by a generation module, upon the determination that the public key file is unavailable within the hidden directory, a public key and a private key associated with the remote server based on one or more file system commands extracted from the identity data. Furthermore, the method comprises determining, by the determination module, upon the generation of the public key and the private key, whether a remote host key associated with the remote server is available or unavailable in a host file of the central server using the one or more file system commands and adding, by a key management module, the remote host key to the host file of the central server upon the determination that the remote host key is unavailable in the host file of thecentral server. The method further comprises transmitting, by a transmitting module, after the addition of the remote host key to the host file, the public key to the remote server.[Oi l] In one or more implementations, the determining whether the hidden directory is available or unavailable in the home directory of the central server comprises verifying, by a validation module, availability of the hidden directory using the one or more file system commands.

[0012] In one or more implementations, the method further comprises creating, by the generation module, using the one or more file system commands, the hidden directory upon the determination that the hidden directory is unavailable in the home directory of the central server.

[0013] In one or more implementations, the private key is generated to establish a match with the public key transmitted to the remote server. The public key is used by the remote server for encryption and verification, and the private key is stored at the central server for decryption and signing.

[0014] In one or more implementations, the remote host key comprises a cryptographic key to authenticate the remote server on establishing a Secure Shell (SSH) connection between the central server and the remote server.

[0015] In one or more implementations, the transmission of the public key to the remote server is performed over a secured network protocol including a Secure Shell (SSH) protocol or a Transport Layer Security (TLS) protocol.

[0016] In one or more implementations, the remote server is enabled by the key management module to store the public key received from the central server in an authorized key list of the remote server and a password-less connection is established between the central server and the remote server using the public key and the private key.

[0017] In one or more implementations, the authorized key list of the remote server comprises a plurality of public keys to grant access of the remote server to a user device.

[0018] In one or more implementations, the remote server is enabled by the validation module to verify access permissions of a home directory of the user device and the access permissions are updated by the key management module to a predefined set of access permissions upon determination of a deviation in the access permissions.

[0019] In one or more implementations, the remote server is enabled by the key management module to set the access permissions of the authorized key list to a predefined value.

[0020] According to another aspect of the present disclosure, disclosed herein is a system for establishing a secure communication in a wireless network. The system comprises a receiving module, a determination module, a generation module, a key management module, and a transmitting module. The receiving module is configured to receive an access request from a remote server. The access request comprises identity data associated with the remote server. The determination module is configured to determine whether a hidden directory associated with the remote server is available or unavailable in a home directory of a central server. Thereafter, the determination module is configured to determine whether a public key file associated with the remote server is available or unavailable within the hidden directory upon the determination that the hidden directory is available in the home directory of the central server. Further, the generation module is configured to generate upon the determination that the public key file is unavailable within the hidden directory, a public key and a private key associated with the remote server based on one or more file system commands extracted from the identity data. Furthermore, the determination module is configured to determine, upon the generation of the public key and the private key, whether a remote host key associated with the remote server is available or unavailable in a host file of thecentral server using the one or more file system commands. The key management module is configured to add the remote host key to the host file of the central server upon the determination that the remote host key is unavailable in the host file of the central server. The transmitting module is configured to transmit, after the addition of the remote host key to the host file, the public key to the remote server.

[0021] In one or more implementations, the system further comprises a validation module. To determine whether the hidden directory is available or unavailable in the home directory of the central server, the validation module is configured to verify availability of the hidden directory using the one or more file system commands.

[0022] In one or more implementations, the generation module is further configured to create, using the one or more file system commands, the hidden directory upon the determination that the hidden directory is unavailable in the home directory of the central server.

[0023] In one or more implementations, the transmitting module is further configured to transmit the public key to the remote server over a secured network protocol including a Secure Shell (SSH) protocol or a Transport Layer Security (TLS) protocol.

[0024] In one or more implementations, the key management module is further configured to enable the remote server to store the public key received from the central server in an authorized key list of the remote server.

[0025] In one or more implementations, the validation module is further configured to enable the remote server to verify access permissions of a home directory of the user device and the key management module is further configured to update the access permissions to a predefined set of access permissions upon determination of a deviation in the access permissions.

[0026] In one or more implementations, the key management module is further configured to enable the remote server to set access permissions of the authorized key list to a predefined value.BRIEF DESCRIPTION OF DRAWINGS

[0027] Various embodiments disclosed herein will become better understood from the following detailed description when read with the accompanying drawings. The accompanying drawings constitute a part of the present disclosure and illustrate certain non-limiting embodiments of inventive concepts. Further, components and elements shown in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. For consistency and ease of understanding, similar components and elements are annotated by reference numerals in the exemplary drawings. In the drawings:

[0028] FIG. 1 illustrates a block diagram depicting a system for establishing a secure communication in a wireless network, in accordance with an exemplary embodiment of the present disclosure.

[0029] FIG. 2 illustrates a block diagram depicting a system architecture of a central server, in accordance with an exemplary embodiment of the present disclosure.

[0030] FIG. 3 illustrates a flow diagram depicting a Secure Shell (SSH) connection for establishing the secure communication in the wireless network, in accordance with an embodiment of the present disclosure.

[0031] FIG. 4 illustrates a flowchart depicting a method implemented at the central server for establishing the SSH connection with a remote server, in accordance with an embodiment of the present disclosure.

[0032] FIG. 5 illustrates a flowchart depicting a method implemented at the remote server for establishing the SSH connection with the central server, in accordance with an embodiment of the present disclosure.

[0033] FIG. 6 illustrates a schematic block diagram of a computing system for establishing the secure communication in the wireless network, in accordance with an exemplary embodiment of the present disclosure.DETAILED DESCRIPTION OF THE INVENTION

[0034] Inventive concepts of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of one or more embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Further, the one or more embodiments disclosed herein are provided to describe the inventive concept thoroughly and completely, and to fully convey the scope of each of the present inventive concepts to those skilled in the art. Furthermore, it should be noted that the embodiments disclosed herein are not mutually exclusive concepts. Accordingly, one or more components from one embodiment may be tacitly assumed to be present or used in any other embodiment.

[0035] The following description presents various embodiments of the present disclosure. The embodiments disclosed herein are presented as teaching examples and are not to be construed as limiting the scope of the present disclosure. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified, omitted, or expanded upon without departing from the scope of the present disclosure.

[0036] The following description contains specific information pertaining to embodiments in the present disclosure. The detailed description uses the phrases “in some embodiments” or “some implementations” which may each refer to one or more or all of the same or different embodiments or implementations. The term “some” as used herein is defined as “one, or more than one, or all.” Accordingly, the terms “one,” “more than one,” “more than one, but not all” or “all” would all fall under the definition of “some.” In view of the same, the terms, for example, “in anembodiment” or “in an implementation” refers to one embodiment or one implementation and the term, for example, “in one or more embodiments” refers to “at least one embodiment, or more than one embodiment, or all embodiments ”. Further, the term, for example, “in one or more implementations” refers to “at least one implementation, or more than one implementation, or all implementations.”

[0037] The term “comprising,” when utilized, means “including, but not necessarily limited to;” it specifically indicates open-ended inclusion in the so-described one or more listed features, elements in a combination, unless otherwise stated with limiting language. Furthermore, to the extent that the terms “includes,” “has,” “have,” “contains,” and other similar words are used in either the detailed description, such terms are intended to be inclusive in a manner similar to the term “comprising.”

[0038] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features.

[0039] The description provided herein discloses exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing any of the exemplary embodiments. Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it may be understood by one of the ordinary skilled in the art that the embodiments disclosed herein may be practiced without these specific details.

[0040] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used hereinthe description, the singular forms "a", "an", and "the" include plural forms unless the context of the invention indicates otherwise.

[0041] The terminology and structure employed herein are for describing, teaching, and illuminating some embodiments and their specific features and elements and do not limit, restrict, or reduce the scope of the present disclosure. Accordingly, unless otherwise defined, all terms, and especially any technical and / or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having ordinary skill in the art.

[0042] An object of the present disclosure is to provide a system and a method that enables a secure exchange of data between a central server and a remote server without a requirement of sharing credentials or sensitive information.

[0043] Another object of the present disclosure is to provide a system and a method that enables implementing a framework capable of verifying the central server and the remote server, ensuring that only authorized parties can participate in a data exchange process.

[0044] Yet another object of the present disclosure is to provide a system and a method that enables prevention of threats and vulnerabilities such as interception, eavesdropping and an unauthorized access associated with data transfer.

[0045] The present disclosure relates to the system and the method for establishing a secure communication between the central server and the remote server in a wireless network. The method enables secure data transmissions, particularly in environments where multiple vendor Element Management System (EMS) are involved. This is achieved through implementation of a Secure Shell (SSH) protocol for establishing authenticated connections between the central server and the remote server. The remote server serves as a representative node within a broader architecture of a remote vendor EMS. Vendors here may correspond to any equipment manufacturers, or service providers. Further, the SSH protocol acts as a protective barrier which ensures secure transmission of sensitive data, such as Fault,Configuration, Accounting, Performance, and Security (FCAPS) data inputs, and prevents the unauthorized access or the interception.

[0046] Several key terms used in the description play pivotal roles in facilitating the secure communication and system functionality. In order to facilitate an understanding of the description, the key terms are defined below.

[0047] A host file refers to a designated storage location within a central server's file system, where cryptographic keys associated with the remote server are stored. The cryptographic keys, known as remote host keys, are essential for verifying authenticity of remote servers during a Secure Shell (SSH) connection.

[0048] A hidden directory (commonly denoted as ".ssh") corresponds to a secure and concealed directory within the central server's file system, intended for storing Secure Shell (SSH)-related files and configurations. The hidden directory may serve as a repository for critical cryptographic artifacts, including Secure Shell (SSH) keys, configuration files, and known hosts lists. Access to the hidden directory may be restricted to authorized users.

[0049] A home directory corresponds to a designated directory within the central server's file system, uniquely associated with each user account or profile. Within the home directory, users may store personal files, configurations, and settings, including the SSH-related files stored in the hidden directory.

[0050] A public key file represents a specific file within the hidden directory, containing a public component of a Secure Shell (SSH) key pair generated for secure authentication. The public key file (also known as "id rsa.pub" or similar), is shared with the remote servers and EMS platforms to establish secure and password-less SSH connections.

[0051] A remote host key corresponds to a unique cryptographic key associated with each remote server or the EMS platform. The remote host key is stored within the host file on the central server. During initiation of the SSH connection by thecentral server, the remote host key is retrieved from the host file and compared against the key presented by the remote server. The comparison may serve to validate the authenticity of the remote server, thereby mitigating a risk of the unauthorized access.

[0052] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings. FIG. 1 through FIG. 6, discussed below, and the one or more embodiments used to describe the principles of the present disclosure are by way of illustration only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged system or device.

[0053] FIG. 1 illustrates a block diagram depicting a system 100 for establishing the secure communication in the wireless network, in accordance with an exemplary embodiment of the present disclosure. The embodiment of the system 100 shown in FIG. 1 is for illustration only. Other embodiments of the system 100 may be used without departing from the scope of this disclosure.

[0054] The system 100 includes a central server 102, a remote server 104, and a network 106. The central server 102 acts as a primary control unit for managing and coordinating communications within a network infrastructure. In an embodiment, the central server 102 may be implemented using a high-performance computing unit equipped with specialized hardware and software components designed to handle concurrent server operations and maintain network stability. The remote server 104 operates in conjunction with the central server 102 via the network 106.

[0055] The remote server 104 is configured to establish the secure connections and maintain communication with the central server 102. In an embodiment, the remote server 104 may be implemented across various hardware configurations while maintaining consistent communication capabilities with the central server 102. In another embodiment, the system 100 may be extended to support multiple remoteservers communicating simultaneously with the central server 102, enabling distributed computing capabilities across diverse network topologies.

[0056] The network 106 may include wired and / or wireless networks. For example, the network 106 may include a cellular network (e.g., a Fifth Generation (5G) network, a Long-Term Evolution (LTE) network, a Third Generation (3G) network, a Code Division Multiple Access (CDMA) network, etc.), a Public Land Mobile Network (PLMN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, and / or a combination of these or other types of networks.

[0057] The system 100 implements a password-less authentication mechanism utilizing the cryptographic keys for secure server access. A key-based authentication mechanism may eliminate conventional password-based vulnerabilities while maintaining the secure communication between the central server 102 and the remote server 104.

[0058] FIG. 2 illustrates a block diagram depicting a system architecture 200 of the central server 102, in accordance with an exemplary embodiment of the present disclosure. The embodiment of the central server 102 shown in FIG. 2 is for illustration only. Other embodiments of the central server 102 may be used without departing from the scope of this disclosure.

[0059] The central server 102 may include a memory 204, one or more processors with a processing circuitry 206, a communication interface 208 and an Input-Output (I / O) interface 210 coupled to each other via a first communication bus 212.

[0060] The memory 204 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of Electrically Programmable Memories (EPROM) or Electrically Erasable and Programmable (EEPROM) Memories. Inaddition, the memory 204 may, in some examples, be considered a non-transitory storage medium. The "non-transitory" storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted as the memory 204 is non-movable. In some examples, the memory 204 may be configured to store larger amounts of information. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory 204 may be an internal storage unit or an external storage unit of the central server 102, cloud storage, or any other type of external storage.

[0061] The processing circuitry 206 may include data processing engines configured with suitable logic, instructions, circuitry, interfaces, and / or codes for executing one or more operations of various operations performed by the central server 102. For example, the processing circuitry 206 is configured to execute programs and other processes stored in the memory 204. The processing circuitry 206 is further configured to move data into or out of the memory 204 as required by the execution process. Examples of the processing circuitry 206 may include, but are not limited to, an Application Specific integrated circuit (ASIC) processor, a Reduced Instruction Set Architecture (RISC) processor, a Complex Instruction Set Architecture (CISC) processor, a Field Programmable Gate Array (FPGA), and the like.

[0062] The communication interface 208 includes an electronic circuit specific to a standard that enables wired or wireless communication. The communication interface 208 is configured to communicate internally between internal hardware components. The communication interface 208 may be further configured to communicate with external devices via the network 106. The communication interface 208 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a Radio Frequency (RF) interface, a Universal Serial Bus (USB) interface, a Wi-Fi interface, a cellular network interface, or the like.

[0063] The I / O interface 210 may include suitable logic, circuitry, interfaces, and / or codes that may be configured to receive input(s) and present (or display) output(s) on the central server 102. For example, the I / O interface 210 may have an input interface (not shown) and an output interface (not shown). The input interface may be configured to enable the user to provide input(s) to trigger (or configure) the central server 102 for performing data processing operation(s). Examples of the I / O interface 210 may include, but are not limited to, a touch interface, a mouse, a keyboard, a motion recognition unit, a gesture recognition unit, a voice recognition unit, or the like. The output interface may be configured to display (or present) output(s) generated (or provided) by the central server 102. In some aspects of the present disclosure, the output interface may provide the output(s) based on an instruction provided by the user of the central server 102, by way of the input interface. Examples of the output interface may include, but are not limited to, a digital display, an analog display, a touch screen display, an appearance of a desktop, and / or illuminated characters. Aspects of the present disclosure are intended to include or otherwise cover any type of the input interface and the output interface in the I / O interface 210, including known, related art, and / or later developed technologies without deviating from the scope of the present disclosure.

[0064] According to an exemplary embodiment, the processing circuitry 206 may include a receiving module 206-1, a transmitting module 206-2, a determination module 206-3, a generation module 206-4, a key management module 206-5, and a validation module 206-6 coupled to each other by way of a second communication bus 214.

[0065] The processing circuitry 206 of the central server 102 is configured to initiate and manage the secure communication with the remote server 104. The processing circuitry 206 may utilize the SSH protocol for encrypted and authenticated connections with the remote server 104.

[0066] Referring to FIG. 2, the receiving module 206-1 may be configured to receive an access request from the remote server 104. The access request comprisesidentity data associated with the remote server 104. The determination module 206- 3 may be configured to determine whether the hidden directory associated with the remote server 104 is available or unavailable in the home directory of the central server 102 and determine whether the public key file associated with the remote server 104 is available or unavailable within the hidden directory based upon the determination that the hidden directory is available in the home directory of the central server 102. The generation module 206-4 may be configured to generate upon the determination that the public key file is unavailable within the hidden directory, a public key and a private key associated with the remote server 104 based on file system commands extracted from the identity data. The determination module 206-3 may be further configured to determine, upon the generation of the public key and the private key, whether the remote host key associated with the remote server 104 is available or unavailable in the host file of the central server 102 using the file system commands. The key management module 206-5 may be configured to add the remote host key to the host file of the central server 102 upon the determination that the remote host key is unavailable in the host file of the central server 102. The transmitting module 206-2 may be configured to transmit, after the addition of the remote host key to the host file, the public key to the remote server 104.

[0067] The file system commands used in the description may correspond to, but not limited to a change directory (cd) command, a copy (cp) command, a global search for the regular expression (grep) command, a make directory (mkdir) command, one or more list commands (Is, latr and Irth), a change mode (chmod) command. The file system commands are defined below for making an easy understanding of the one or more embodiments disclosed herein:

[0068] The cd command facilitates navigation between directories within a file system and allows the users to change a current working directory to a specified path.

[0069] The cp command facilitates reading the files and the directories from one location and writing the files and the directories to another location and preserves original content while duplicating the data to a specified destination.

[0070] The grep command scans input files or streams for lines matching a specified pattern and prints matched lines.

[0071] The mkdir command facilitates creation of new directories within the file system and allows the users to establish hierarchical directory structures.

[0072] The Is command lists contents of the directories, including the files and subdirectories, providing details such as the permissions, ownership, and timestamps.

[0073] The Is -latr command lists all the files, including hidden files, in long format, sorted by time in reverse order.

[0074] The Is -Irth command list the files and the sub directories sorted by time, in reverse order, with human readable size.

[0075] The chmod command modifies the files or directory permissions, allowing the users to set read, write, and execute permissions.

[0076] Although FIG. 2 illustrates one example of the central server 102, various changes may be made to FIG. 2. For example, the central server 102 may include any number of components in addition to the components shown in FIG. 2. Further, various components in FIG. 2 may be combined, further subdivided, or omitted and additional components may be added according to particular needs.

[0077] FIG. 3 illustrates a flow diagram 300 depicting the SSH connection for establishing the secure communication in the wireless network, in accordance with an exemplary embodiment of the present disclosure.

[0078] Initially, the central server 102 logs into an edge node and verifies a presence of the hidden directory associated with the remote server 104 in the home directoryof the central server 102. If the hidden directory is absent, the hidden directory is created. The edge node represents a specialized computing node, or a network device positioned at a periphery of a central server’s infrastructure. The edge node serves as a gateway or an access point for managing incoming and outgoing network traffic, facilitating the secure communication with the remote server 104, and providing connectivity to external networks or systems. The edge node may include dedicated hardware components, software modules, and security features tailored to a role of the edge node in network management and data transmission.

[0079] At step 302, the central server 102 checks for the existence of a Secure Shell (SSH) public key inside the hidden directory. If the SSH public key is missing, the SSH key pair (the public key and the private key) associated with the remote server 104 is generated. Additionally, the central server 102 ensures that the remote host key associated with the remote server 104 is available in the host file of the central server 102.

[0080] At step 304, the remote host key is added to the host file of the central server 102 upon the determination that the remote host key is unavailable in the host file of the central server 102.

[0081] At step 306, the public key is copied from the central server 102 to the remote server 104 and at step 308, the public key is further copied in a designated file (also known as authorized keys file) that allows the remote server 104 to recognize and trust the public key.

[0082] At step 310, after the public key is successfully copied, the central server 102 (by using its private key) attempts to establish the SSH connection with the remote server 104. The remote server 104 checks the authorized keys file to verify the public key against the private key. If the keys match, the remote server 104 grants access without requiring the password, establishing the password-less connection.

[0083] FIG. 4 illustrates a flowchart depicting a method 400 implemented at the central server 102 for establishing the SSH connection with the remote server 104,in accordance with an exemplary embodiment of the present disclosure. The method 400 comprises a series of operation steps indicated by blocks 402 through 414. The method 400 starts at block 402.

[0084] The user at the central server 102 initially require necessary credentials required to access the remote server 104. The credentials may include a hostname, password, and an Internet Protocol (IP) address of the remote server 104. The user may correspond to any of system operator, an administrator, or any authorized personnel responsible for managing and configuring a Secure Shell (SSH) authentication and access control.

[0085] At block 402, the receiving module 206-1 may receive the access request from the remote server 104. The access request comprises the identity data associated with the remote server 104. The "identity data" may comprise the hostname or the IP address, and a Secure Shell (SSH) key fingerprint (or the password) of the remote server 104. The identity data uniquely identifies the remote server 104, allowing the central server 102 to authenticate and validate the access request securely.

[0086] At block 404, the determination module 206-3 may determine, based on the identity data, if the hidden directory associated with the remote server 104 exists within the home directory of the central server 102 using the file system commands. In a non-limiting example, the file system command may be represented as: “cd; Is -latr | grep .ssh”. The command “cd; Is -latr | grep .ssh” facilitates navigation to the home directory of the central server 102, listing of all the files and the directories in the home directory including the hidden files and filtering the output to check if the hidden directory associated with the remote server 104 exists within the home directory of the central server 102. In an implementation, if the hidden directory is not found within the home directory of the central server 102, the hidden directory is created using the mkdir command. In a non-limiting example, the file system command may be represented as: cd; mkdir ~ / .ssh.

[0087] At block 406, the determination module 206-3 may determine whether the public key file (id rsa.pub) associated with the remote server 104 is available or unavailable within the hidden directory upon the determination that the hidden directory is available in the home directory of the central server 102 using the file system commands. In a non-limiting example, the file system command may be represented as “Is -Irth ~ / .ssh / id_rsa.pub”. The “Is -Irth ~ / .ssh / id_rsa.pub” command lists detailed information about the id rsa.pub file, if the public key file exists within the hidden directory. The public key file may contain a public key portion of the SSH key pair and is used for the authentication during the SSH connection.

[0088] At block 408, the generation module 206-4 may generate the SSH key pairs i.e., the public key and the private key associated with the remote server 104 using the file system commands and the identity data upon the determination that the public key file is unavailable within the hidden directory (.ssh). In a non-limiting example, the file system command may be represented as: “ssh -keygen -t rsa -q -f ~ / .ssh / id_rsa -N "" “. The command “ssh -keygen -t rsa -q -f ~ / .ssh / id_rsa -N "" “is run in a quiet mode to generate a new SSH key pair to create the private key (id rsa) and the public key (id rsa.pub) in the hidden directory (.ssh) folder. Here -N may include an identifying information such as the username or a hostname from the identity data to associate the keys with the remote server 104. In another nonlimiting example, to determine the creation of the public key, the file system command used is: “Is -Irth ~ / .ssh / ; Is -Irth ~ / .ssh / id_rsa.pub”. The command "Is -Irth ~ / .ssh / ; Is -Irth ~ / .ssh / id_rsa.pub” lists the contents of the hidden directory in detailed format, sorted by modification time (most recently created files at the bottom) and checks if the public key (id rsa.pub) is created and displays details of the public key.

[0089] The key generation command may create both the public key (id rsa.pub) and private key (id rsa) files, used for the secure authentication and the communication between the servers. In an embodiment, the public key is used by the remote server 104 for encryption and verification, and the private key is stored at the central server 102 for decryption and signing purposes.

[0090] At block 410, the determination module 206-3 may determine, upon the generation of the public key and the private key, whether an entry for the remote host key associated with the remote server 104 is present in the host file of the central server 102. In another non-limiting example, if the entry is already available in the host file, the file system command used to list the details is: “grep -i <ip> ~ / .ssh / known_hosts”. The command “grep -i <ip> ~ / .ssh / known_hosts” is used to search for a remote host IP in the known hosts file of the central server 102.

[0091] The host file may store fingerprints of SSH host keys for known remote servers, helping to verify authenticity during the SSH connection. In an embodiment, the host file may exist as a plaintext file or within a structured database, containing entries corresponding to unique remote server identities and associated keys.

[0092] At block 412, the key management module 206-5 may add the remote host key to the host file of the central server 102 upon the determination that the remote host key is unavailable in the host file of the central server 102. In a non-limiting example, if the entry of the remote host key is not available in the host file, then the file system command used to add the remote host key in the host file of the central server 102 is represented as: ssh <remote_username>@<remote-host-ip>

[0093] A yes is entered if the above command prompt to add the remote host key in the host file. In a non-limiting example, the file system command used to further check the availability of the remote host key in the host file is represented as: grep -i <ip> ~ / .ssh / known_hosts.

[0094] At block 414, the transmitting module 206-2 may transmit, after the addition of the remote host key to the host file, the public key to the remote server 104 using the file system command. In a non-limiting example, the file system command may be represented by using a ssh-copy-id command. For instance, “ssh-copy-id -i ~ / .ssh / id_rsa.pub <remote_usemame>@<hostIP>”. The command “ssh-copy-id -i ~ / .ssh / id_rsa.pub <remote_username>@<hostIP>” copies the public key to the authorized keys file of the remote server 104. The public key file is located in thehidden directory under the home directory (~ / .ssh / id_rsa.pub). The command enables password- less authentication between the central server 102 and the remote server 104, thereby enhancing security and convenience. In a non-limiting example, after successful key push to the remote server 104, the file system command used to check if key-based authentication is working or not is represented as: ssh <remote_usemame>@<HostIP>.

[0095] In an implementation, the user may verify whether the key-based authentication is working by attempting to establish the connection with the remote server 104 without being prompted for the password. If successful, the secure and an authenticated connection is established from the central server 102 to the remote server 104, allowing for secure data transfer and the communication. In an embodiment, transmitting the public key to the remote server 104 is performed over the secured network protocol including the SSH protocol or a Transport Layer Security (TLS) protocol.

[0096] Further, the generated key in the method 400 may continue to be utilized for all subsequent communications between the central server 102 and the remote server 104, thereby eliminating the need for passwords. This ensures consistency and the security in future sessions whenever the same remote server 104 reconnects with the central server 102.

[0097] FIG. 5 illustrates a flowchart depicting a method 500 implemented at the remote server 104 within the vendor EMS to establish the SSH connection with the central server 102, in accordance with an exemplary embodiment of the present disclosure. The method 500 comprises a series of operation steps indicated by blocks 502 through 512. The method 500 starts at block 502.

[0098] Referring to FIG. 5, at block 502, the validation module 206-6 may enable the remote server 104 within the vendor EMS, to verify access permissions of the home directory of the user device. The access permissions define a level of the access granted to the users for the directories or the files. This ensures that the home directory has correct security settings for proper access control. In one non-limitingexample, the access permission of a user’s home directory may be checked by using the file system command represented as: “cd; cd Is -Itr | grep <user_home_directory_name>”. Using “cd; cd Is -Itr | grep <user_home_directory_name>” command, the user may navigate to a parent directory containing the user's home directory and then list the user's home directory contents. In a non-limiting example, a Is -Itr command may be used to view the detailed information of the user's home directory such as the access permissions, and the modification times.

[0099] At block 504, the validation module 206-6 may enable the remote server 104 to update the access permissions to a predefined set of access permissions upon determination of a deviation in the access permissions. In a non-limiting example, the validation module 206-6 may update the access permissions using the chmod command if the access permissions of the user's home directory are not set to 700 or 755. Here 700 and 755 refer to numerical values representing the access permissions allowed for the user's home directory. The access permission 700 may give full control of read (r) or access, modify (w), and execute (x) the files only to the user who owns the files or the directories, while blocking the access for other users. The access permission 755 may give the full control of read (access), modify, and execute the files only to the user who owns the files or the directories while other users may only read or access the files or the directories without any modification rights. In view of this, the access permissions are updated by the validation module 206-6, if the access permissions to the user's home directory are not set to any of the 700 or 755. This ensures that the directory has the appropriate security settings for a secure access control. If the chmod command may not show an expected access permission, the file system command used to change the access permission is represented as: cd; cd ..; chmod 700<user_home_directory_name>.

[0100] < user_home_directory_name> is an absolute or relative path to the user’s home directory.

[0101] At block 506, the validation module 206-6 may enable the remote server 104 to check if a hidden directory folder exists within the user's home directory by listing directory contents and searching for the hidden directory folder. In a non-limiting example, the file system command used is cd; Is -lathr | grep .ssh. The hidden directory folder may store the SSH-related files, such as the keys and the configuration files. In another non-limiting example, if the hidden directory folder is not found, the file system command used to create the hidden directory folder is represented as: mkdir ~ / .ssh / . This may ensure that the necessary directory structure is in place for Secure Shell (SSH)-related operations.

[0102] At block 508, after verifying or creating the hidden directory folder, the validation module 206-6 may enable the remote server 104 to ensure whether the access permissions of the hidden directory folder are set correctly. In a non-limiting example, the access permissions are adjusted to 700 using a set of commands represented as: cd; Is -lathr | grep .ssh cd; chmod 700 .ssh cd; Is -lathr | grep .ssh(drxw - which is 700 OR drxwrx-rx— which is 755).The set of commands represented above are used to lists the details of the hidden directory folder to check the access permissions. The access permissions of the hidden directory folder are changed to 700 to ensure that the hidden directory folder is accessible only to the user who owns this folder, cd; Is -lathr | grep .ssh is re- executed to confirm whether the access permissions are now set to 700. In an implementation, the access permissions of the hidden directory folder are changed to 755.

[0103] At block 510, the validation module 206-6 may enable the remote server 104 to check if the authorized keys file exists within the hidden directory folder. In a non-limiting example, if the authorized keys file is not found, the file system command used to create the authorized keys file is represented as: touch ~ / .ssh / authorized_keys. The authorized key file of the remote server 104 maycomprise the public keys to grant access of the remote server 104 to the user device. The touch command creates an empty file with the authorized keys file name if it doesn’t already exist, and creates the authorized keys file inside the hidden directory folder. If the authorized keys file already exists, touch command will update last modified timestamp without altering the content of the authorized keys file. File Path: • ~ / .ssh / authorized_keys store the public keys that are allowed to authenticate via the SSH connection.

[0104] At block 512, the validation module 206-6 may enable the remote server 104 to set the correct access permissions for the authorized keys file. In a non-limiting example, the access permissions are set to 600 using the chmod file system command represented as: cd ~ / .ssh / chmod 600 authorized keys. The chmod file system command here represents that the access permissions for the authorized keys file is set to 600 to allow only the owner or the user of the file to read and write the authorized keys file. The file permissions prevent unauthorized access to sensitive files.

[0105] The method 500 outlines the sequential steps performed at the remote server 104 within the vendor EMS to establish proper permissions and the configurations for secure SSH authentication and the communication. Each step is crucial for ensuring the integrity and security of the SSH infrastructure within an EMS environment.

[0106] FIG. 6 illustrates a schematic block diagram of a computing system 600 for establishing the secure communication in the wireless network, in accordance with an exemplary embodiment of the present disclosure. The computing system 600 may be any type of computer, including a server, a web server, a cloud server, etc. The one or more components of the computing system 600 may perform the functions similar to the components of the central server 102 as disclosed herein with respect to FIG. 2 through FIG. 5.

[0107] The computing system 600 includes a network 610, a network interface 620, a processor 630, an Input / Output (I / O) interface 640 and a non-transitory computer readable storage medium 650 (hereinafter may also be referred to as the “storage medium 650” or the “storage media 650”).

[0108] The network interface 620 includes wireless network interfaces such as Bluetooth, Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), General Packet Radio Service (GPRS), or Wideband Code Division Multiple Access (WCDMA) or wired network interfaces such as Ethernet, Universal Serial Bus (USB), or Institute of Electrical and Electronics Engineers-864 (IEEE-864).

[0109] The processor 630 may include various processing circuitry and communicate with the storage medium 650 and the VO interface 640. The processor 630 is configured to execute instructions stored in the storage medium 650 and to perform various processes. The processor 630 may include may include an intelligent hardware device including a general-purpose processor, such as, for example, and without limitation, the CPU, an Application Processor (AP), a dedicated processor, or the like, a graphics-only processing unit such as a Graphics Processing Unit (GPU), a microcontroller, a Field-Programmable Gate Array (FPGA), a programmable logic device, a discrete hardware component, or any combination thereof. The processor 630 may be configured to execute computer- readable instructions 652 stored in the storage medium 650 to cause the central server 102 to perform various functions.

[0110] The storage medium 650 stores a set of instructions 652 required by the processor 630 for controlling its overall operations. The storage media 650 may include an electronic storage medium, a magnetic storage medium, an optical storage medium, a quantum storage medium, or the like. For example, the storage media 650 may include, but are not limited to, hard drives, floppy diskettes, optical disks, ROMs, RAMs, EPROMs, EEPROMs, flash memory, magnetic or optical cards, solid-state memory devices, or other types of physical media suitable for storing electronic instructions. In one or more implementations, the storage media1650 includes a Compact Disk-Read Only Memory (CD-ROM), a Compact Disk- Read / Write (CD-R / W), and / or a Digital Video Disc (DVD).

[0111] In one or more implementations, the storage medium 650 stores computer program code configured to cause the computing system 600 to perform at least a portion of the processes and / or methods. Accordingly, in at least one embodiment, the computing system 600 performs the method for establishing the secure communication in the wireless network.

[0112] Embodiments of the present disclosure have been described above with reference to flowchart illustrations of methods and systems according to the embodiments of the disclosure, and / or procedures, algorithms, steps, operations, formulae, or other computational depictions, which may also be implemented as computer program products. In this regard, each block or step of the flowchart, and combinations of blocks (and / or steps) in the flowchart, as well as any procedure, algorithm, step, operation, formula, or computational depiction can be implemented by various means, such as hardware, firmware, and / or software including one or more computer program instructions embodied in computer-readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors, including without limitation a general -purpose computer or special purpose computer, or other programmable processing apparatus to perform a group of operations comprising the operations or blocks described in connection with the disclosed methods.

[0113] Further, these computer program instructions, such as embodied in computer-readable program code, may also be stored in one or more computer- readable memory or memory devices (for example, the memory 204 or the storage medium 650) that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions 652 stored in the computer-readable memory or memory devices produce an article of manufacture including instruction means which implement the function specified in the block(s) of the flowchart(s).

[0114] It will further be appreciated that the term “computer program instructions” as used herein refer to one or more instructions that can be executed by the processing circuitry 206 to perform one or more functions as described herein. The instructions 652 may also be stored remotely such as on a server, or all or a portion of the instructions can be stored locally and remotely.

[0115] Now, referring to the technical abilities and advantageous effect of the present disclosure, operational advantages that may be provided by one or more embodiments may include providing techniques for secure communication between the central server and the remote server. By establishing the authenticated connection between the central and the remote servers using the SSH keys, the need for passwords is eliminated, thereby enhancing the security and reducing the risk of the unauthorized access. The technique not only improves data security but also simplifies management tasks for system administrators. Furthermore, an ability to securely ingest the data from multiple vendor EMS enhances the network performance, resource allocation, and overall operational efficiency. By leveraging standard operating system commands, the implementation of the invention is straightforward, resulting in reduced complexity and improved reliability. Further, the technique ensures a secure ingestion of the FCAPS data supporting for a Radio Intelligent Controller (RIC) functionality from the multiple vendor EMS, thereby enhancing the performance and the resource allocation in the wireless network.

[0116] Those skilled in the art will appreciate that the methodology described herein in the present disclosure may be carried out in other specific ways than those set forth herein in the above disclosed embodiments without departing from essential characteristics and features of the present disclosure. The above-described embodiments are therefore to be construed in all aspects as illustrative and not restrictive.

[0117] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certainelements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Any combination of the above features and functionalities may be used in accordance with one or more embodiments.

[0118] In the present disclosure, each of the embodiments has been described with reference to numerous specific details which may vary from embodiment to embodiment. The foregoing description of the specific embodiments disclosed herein may reveal the general nature of the embodiments herein that others may, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications are intended to be comprehended within the meaning of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and is not limited in scope.LIST OF REFERENCE NUMERALS

[0119] The following list is provided for convenience and in support of the drawing figures and as part of the text of the specification, which describe innovations by reference to multiple items. Items not listed here may nonetheless be part of a given embodiment. For better legibility of the text, a given reference number is recited near some, but not all, recitations of the referenced item in the text. The same reference number may be used with reference to different examples or different instances of a given item. The list of reference numerals is:100 - System102 - Central Server104 - Remote Server106 - Network200 - System Architecture of the central server204 - Memory206 - Processing circuitry206-1 - Receiving module206-2 - Transmitting module206-3 - Determination module206-4 - Generation module206-5 - Key management module206-6 - Validation module208 - Communication Interface210 - I / O Interface212 - First communication bus214 - Second communication bus300 - Flow diagram of the SSH connection302-310 - Steps in the flow diagram 300400 - Method implemented at the central server402-414 - Steps of the flow diagram 400500 - Method implemented at the remote server502-512 - Steps of the flow diagram 500600 - Computing system610 - Network620 - Network Interface630 - Processor640 - I / O Interface650 - Non transitory computer readable storage medium652 - Instructions

Claims

We Claim:

1. A method (400) for establishing a secure communication in a wireless network, the method comprising: receiving (402), by a receiving module (206-1) of a central server (102), an access request from a remote server (104), wherein the access request comprises identity data associated with the remote server (104); determining (404), by a determination module (206-3), based on the identity data, whether a hidden directory associated with the remote server (104) is available or unavailable in a home directory of the central server (102); determining (406), by the determination module (206-3), whether a public key file associated with the remote server (104) is available or unavailable within the hidden directory upon the determination that the hidden directory is available in the home directory of the central server (102); generating (408), by a generation module (206-4), upon the determination that the public key file is unavailable within the hidden directory, a public key and a private key associated with the remote server (104) based on one or more file system commands extracted from the identity data; determining (410), by the determination module (206-3), upon the generation of the public key and the private key, whether a remote host key associated with the remote server (104) is available or unavailable in a host file of the central server (102) using the one or more file system commands; adding (412), by a key management module (206-5), the remote host key to the host file of the central server (102) upon the determination that the remote host key is unavailable in the host file of the central server (102); and transmitting (414), by a transmitting module (206-2), after the addition of the remote host key to the host file, the public key to the remote server (104).

2. The method (400) as claimed in claim 1, wherein determining whether the hidden directory is available or unavailable in the home directory of the central server (102) comprises verifying, by a validation module (206-6), availability of the hidden directory using the one or more file system commands.

3. The method (400) as claimed in claim 2, further comprising creating, by the generation module (206-4), using the one or more file system commands, the hidden directory upon the determination that the hidden directory is unavailable in the home directory of the central server (102).

4. The method (400) as claimed in claim 1 , wherein the private key is generated to establish a match with the public key transmitted to the remote server (104), wherein the public key is used by the remote server (104) for encryption and verification, and the private key is stored at the central server (102) for decryption and signing.

5. The method (400) as claimed in claim 1, wherein the remote host key comprises a cryptographic key to authenticate the remote server (104) on establishing a Secure Shell (SSH) connection between the central server (102) and the remote server (104).

6. The method (400) as claimed in claim 1, wherein transmitting the public key to the remote server (104) is performed over a secured network protocol including a Secure Shell (SSH) protocol or a Transport Layer Security (TLS) protocol.

7. The method (400) as claimed in claim 1, further comprising: enabling, by the key management module (206-5), the remote server (104) to store the public key received from the central server (102) in an authorized key list of the remote server (104); and establishing, by the key management module (206-5), a password-less connection between the central server (102) and the remote server (104) using the public key and the private key.

8. The method (400) as claimed in claim 7, wherein the authorized key list of the remote server (104) comprises a plurality of public keys to grant access of the remote server (104) to a user device.

9. The method (400) as claimed in claim 8, further comprising: enabling, by the validation module (206-6), the remote server (104) to verify access permissions of a home directory of the user device; and updating, by the key management module (206-5), the access permissions to a predefined set of access permissions upon determination of a deviation in the access permissions.

10. The method (400) as claimed in claim 8, further comprising enabling, by the key management module (206-5), the remote server (104) to set the access permissions of the authorized key list to a predefined value.

11. A system (100) for establishing a secure communication in a wireless network, the system (100) comprising: a receiving module (206-1) configured to receive an access request from the remote server (104), wherein the access request comprises identity data associated with the remote server (104); a determination module (206-3) configured to: determine, based on the identity data, whether a hidden directory associated with the remote server (104) is available or unavailable in a home directory of the central server (102); determine whether a public key file associated with the remote server (104) is available or unavailable within the hidden directory upon the determination that the hidden directory is available in the home directory of the central server (102); a generation module (206-4) configured to generate, upon the determination that the public key file is unavailable within the hidden directory, a public key and a private key associated with the remote server (104) based on one or more file system commands extracted from the identity data, wherein: the determination module (206-3) is further configured to determine, upon the generation of the public key and the private key, whether a remote host key associated with the remote server (104) is available or unavailablein a host file of the central server (102) using the one or more file system commands; a key management module (206-5) configured to add the remote host key to the host file of the central server (102) upon the determination that the remote host key is unavailable in the host file of the central server (102); and a transmitting module (206-2) configured to transmit, after the addition of the remote host key to the host file, the public key to the remote server (104).

12. The system (100) as claimed in claim 11, further comprising a validation module (206-6), wherein to determine whether the hidden directory is available or unavailable in the home directory of the central server (102), the validation module (206-6) is configured to verify availability of the hidden directory using the one or more file system commands.

13. The system (100) as claimed in claim 12, wherein the generation module (206-4) is further configured to create, using the one or more file system commands, the hidden directory upon the determination that the hidden directory is unavailable in the home directory of the central server (102).

14. The system (100) as claimed in claim 11, wherein the private key is generated to establish a match with the public key transmitted to the remote server (104), wherein the public key is used by the remote server (104) for encryption and verification, and the private key is stored at the central server (102) for decryption and signing.

15. The system (100) as claimed in claim 11, wherein the remote host key comprises a cryptographic key to authenticate the remote server (104) on establishing a Secure Shell (SSH) connection between the central server (102) and the remote server (104).

16. The system (100) as claimed in claim 11 , wherein the transmitting module (206-2) is further configured to transmit the public key to the remote server (104)over a secured network protocol including a Secure Shell (SSH) protocol or a Transport Layer Security (TLS) protocol.

17. The system (100) as claimed in claim 11, wherein the key management module (206-5) is further configured to enable the remote server (104) to store the public key received from the central server (102) in an authorized key list of the remote server (104).

18. The system (100) as claimed in claim 11, wherein a password-less connection is established between the central server (102) and the remote server (104) using the public key and the private key.

19. The system (100) as claimed in claim 17, wherein the authorized key list of the remote server (104) comprises a plurality of public keys to grant access of the remote server (104) to a user device.

20. The system (100) as claimed in claim 19, wherein the validation module (206-6) is further configured to enable the remote server (104) to verify access permissions of a home directory of the user device and the key management module (206-5) is further configured to update the access permissions to a predefined set of access permissions upon determination of a deviation in the access permissions.

21. The system (100) as claimed in claim 19, wherein the key management module (206-5) is further configured to enable the remote server (104) to set the access permissions of the authorized key list to a predefined value.

22. A computer program product comprising computer-executable instructions that are stored on a non-transitory computer-readable medium and that, when executed by at least one processor performs operations comprising: receiving, by a central server (102), an access request from a remote server (104), wherein the access request comprises identity data associated with the remote server (104);determining, based on the identity data, whether a hidden directory associated with the remote server (104) is available or unavailable in a home directory of the central server (102); determining whether a public key file associated with the remote server (104) is available or unavailable within the hidden directory upon the determination that the hidden directory is available in the home directory of the central server (102); generating, upon the determination that the public key file is unavailable within the hidden directory, a public key and a private key associated with the remote server (104) based on one or more file system commands extracted from the identity data; determining, upon the generation of the public key and the private key, whether a remote host key associated with the remote server (104) is available or unavailable in a host file of the central server (102) using the one or more file system commands; adding the remote host key to the host file of the central server (102) upon the determination that the remote host key is unavailable in the host file of the central server (102); and transmitting, after addition of the remote host key to the host file, the public key to the remote server (104).

Images