💎 Earn 45%—Join Hostman Affiliate Program!
English
Community
Sign In
Sign In

How to Protect a Server: 6 Practical Methods

How to Protect a Server: 6 Practical Methods
Hostman Team
Technical writer
Servers
02.12.2024
Reading time: 8 min
Share

Any IT infrastructure requires robust protection. While information security is a vast topic, there are basic steps that can safeguard against attacks from amateur hackers and bots. This article outlines six straightforward methods to protect your server effectively.

Tools and Methods of Protection

Securing a server from breaches involves a combination of measures. These can be categorized into the following areas:

  • Securing communication channels used for system administration and operation.
  • Implementing multi-layered security for the system.
  • Restricting access to infrastructure resources.
  • Monitoring and auditing system activities.
  • Backing up data.
  • Timely updates or rollbacks of software.
  • Antivirus protection for servers.

Below, we detail six practical methods to achieve a robust security level against amateur attackers and bots.

Privilege Restriction

When managing access to resources, follow the principle of least privilege: users and processes should only have the minimal permissions necessary to perform their tasks. This is particularly important for databases and operating systems. This approach not only prevents unauthorized external access but also mitigates risks from internal threats.

  • Separate Accounts for Administrators: Create individual accounts for each admin. Use non-privileged accounts for operations that don’t require elevated permissions.

  • Active Directory: In environments using Microsoft Active Directory, regularly audit and configure group policies. Mismanagement of these policies can lead to severe security breaches, especially if exploited by a malicious admin or hacker.

  • Minimize Root Usage in Unix Systems: Avoid working as the root user. Instead, disable the root account and use the sudo program for tasks requiring elevated permissions.

To customize sudo behavior, modify the /etc/sudoers file using the visudo command. Below are two useful directives for monitoring sudo activity.

By default, sudo logs to syslog. To store logs in a separate file for better clarity, add the following to /etc/sudoers:

Defaults log_host, log_year, logfile="/var/log/sudo.log"

This directive records command logs, along with input and output (stdin, stdout, stderr), into /var/log/sudo-io:

Defaults log_host, log_year, logfile="/var/log/sudo.log"

For a deeper dive into managing the sudoers file, check this guide.

Mandatory Access Control (MAC)

This recommendation focuses on Linux systems and builds upon the principle of access control. Many Linux administrators rely solely on discretionary access control (DAC) mechanisms, which are basic and always active by default. However, several Linux distributions include mandatory access control (MAC) mechanisms, such as AppArmor in Ubuntu and SELinux in RHEL-based systems.

While MAC requires more complex configuration of the OS and services, it allows for granular access control to filesystem objects, significantly enhancing the server's security.

Remote Administration of Operating Systems

When remotely administering an operating system, always use secure protocols:

  • For Windows, use RDP (Remote Desktop Protocol).
  • For Linux, use SSH (Secure Shell).

Although these protocols are robust, additional measures can further strengthen security.

For RDP, you can block connections of accounts with blank passwords. You can configure it via Local Security Policy under the setting:

Accounts: Limit local account use of blank passwords to console logon only.

RDP sessions can be protected with the secure TLS transport protocol, which will be discussed later.

By default, SSH user authentication relies on passwords. Switching to SSH key-based authentication provides stronger protection, as a long key is far more difficult to brute-force than a password. Additionally, key-based authentication eliminates the need to enter a password during login since the key is stored on the server.

Setting up keys requires only a few simple steps:

Generate a key pair on your local machine:

ssh-keygen -t rsa

Copy the public key to the remote server:

ssh-copy-id username@remote_address

If key-based authentication is not an option, consider implementing Fail2ban. This tool monitors failed login attempts and blocks the IP addresses of attackers after a specified number of failed attempts.

Additionally, changing default ports can help reduce the likelihood of automated attacks:

  • Default SSH port 22/tcp → Choose a non-standard port.
  • Default RDP port 3389/tcp → Use a custom port.

Firewall Configuration

A robust security system is layered. Relying solely on access control mechanisms is insufficient; it is more logical to manage network connections before they reach your services. This is where firewalls come in.

A firewall provides network-level access control to segments of the infrastructure. The firewall decides which traffic to permit through the perimeter based on a specific set of allow rules. Any traffic that does not match these rules is blocked. In Linux, the firewall is integrated into the kernel (via netfilter), and you can manage using a frontend tool such as nftables, iptables, ufw, or firewalld.

The first step in configuring a firewall is to close unused ports and keep only those that are intended for external access. For instance, a web server typically requires ports 80 (HTTP) and 443 (HTTPS) to remain open. While an open port itself is not inherently dangerous (the risk lies in the program behind the port), it is still better to eliminate unnecessary exposure.

In addition to securing the external perimeter, firewalls can segment infrastructure and control traffic between these segments. If you have public-facing services, consider isolating them from internal resources by using a DMZ (Demilitarized Zone). Additionally, it’s worth exploring Intrusion Detection and Prevention Systems (IDS/IPS). These solutions work on the opposite principle: they block security threats while allowing all other traffic through.

Hostman offers a cloud firewall that provides cutting-edge defense for your server.

Virtual Private Networks (VPNs)

Up until now, we have focused on protecting a single server. Let’s now consider securing multiple servers. The primary purpose of a Virtual Private Network (VPN) is to provide secure connectivity between organizational branches. Essentially, a VPN creates a logical network over an existing network (e.g., the Internet). Its security is ensured through cryptographic methods, so the protection of connections does not depend on the underlying network's security.

There are many protocols available for VPNs, and the choice depends on the size of the organization, network architecture, and required security level.

  • PPTP (Point-to-Point Tunneling Protocol) is a simple option for a small business or home network, as it is widely supported on routers and mobile devices. However, its encryption methods are outdated.

  • For high-security needs and site-to-site connections, protocols like IPsec are suitable.

  • For site-to-host connections, options like WireGuard are more appropriate. WireGuard and similar protocols provide advanced security but require more intricate configuration compared to PPTP.

TLS and Public Key Infrastructure (PKI)

Many application-layer protocols, such as HTTP, FTP, and SMTP, were developed in an era when networks were limited to academic institutions and military organizations long before the invention of the web. These protocols transmit data in plaintext. To ensure the security of a website, web control panels, internal services, or email, you should use TLS.

TLS (Transport Layer Security) is a protocol designed to secure data transmission over an untrusted network. While the term SSL (e.g., SSL certificates, OpenSSL package) is often mentioned alongside TLS, it’s important to note that the modern versions of the protocol are TLS 1.2 and TLS 1.3. Earlier versions of TLS and its predecessor, SSL, are now considered obsolete.

TLS provides privacy, data integrity, and resource authentication. Authentication is achieved through digital signatures and the Public Key Infrastructure (PKI). PKI functions as follows: the server's authenticity is verified using an SSL certificate, which is signed by a Certificate Authority (CA). The CA’s certificate is, in turn, signed by a higher-level CA, continuing up the chain. The root CA certificates are self-signed, meaning their trust is implicitly assumed.

TLS can also be used with Virtual Private Networks (VPNs), such as setting up client authentication using SSL certificates or a TLS handshake. In this case, it would be necessary to organize your own PKI within the local network, including a CA server, as well as the keys and certificates for network nodes.

The Dangers of Attackers

The level of threat depends on the type of attack. Cyberattacks can be broadly categorized into two main types.

  • Breaching the Security Perimeter

This type of attack involves gaining unauthorized access to the account of an authenticated user of a service or system, such as a database. Breaches of privileged accounts pose significant risks because attackers gain the ability to view sensitive information and modify system parameters. The most critical type of breach involves gaining unauthorized access to the superuser account of the operating system, potentially compromising a significant portion of the infrastructure.

  • Disabling Systems

This category of attacks aims to disrupt system operations rather than steal data, but it is no less dangerous. The most prominent example is a DoS (Denial of Service) or DDoS (Distributed Denial of Service) attack. These attacks overload the server with a flood of requests, causing it to fail and become unresponsive to legitimate users. In some cases, a DoS attack serves as a precursor to other forms of cyberattacks.

The results of cyberattacks often include data breaches, financial losses, and reputational damage. For this reason, even the most basic level of security should be implemented when establishing an IT infrastructure.

Servers
02.12.2024
Reading time: 8 min
Share

Similar

Servers

Deploying and Configuring Keycloak

If you have a web application and you don’t want to write your own authentication from scratch, most likely, Keycloak will come in handy. This is a ready-made user management system that can do everything: logins, roles, tokens, social networks, and even SSO out of the box. In this article, we’ll look at how to deploy Keycloak on a Hostman server and configure authentication for your applications. What Keycloak Is and What It Does Keycloak is a service that takes over all the work with authorization and authentication. Instead of building your own system of logins, passwords, email confirmations, roles, and tokens, you just connect Keycloak and get everything you need. Keycloak functions as an independent service: it has a control panel, a REST API, integration with external systems, and clients for popular languages and frameworks. In essence, Keycloak becomes the central authorization hub in the project: users authorize through it, receive tokens, and then get into your applications. Key scenarios where Keycloak shows itself best: Single Sign-On (SSO) — one login for all your services. OAuth2 and OpenID Connect — ready-made implementation of standards. Roles and groups — determine which actions are available to a user. Social logins — login through Google, GitHub, etc. User management — creation, ban, password reset, email confirmation. Integration with any frontends and backends — Java, Python, Node.js, React, Angular. Keycloak helps not only to quickly launch login via username and password but also to scale access: from one landing page to dozens of microservices with different permissions. Installing Keycloak You can deploy Keycloak anywhere, from a home server to Kubernetes. But if you need a quick start without unnecessary complications, a regular VPS is suitable. Let’s see how to install Keycloak in Hostman conveniently, quickly, and inexpensively. What you will need: A Hostman account A cloud server (VPS) on Ubuntu 22.04 Installed Docker and Docker Compose (we’ll show below) Step 1. Create a server in Hostman Go to the control panel → Cloud servers. Click Create. Select the Ubuntu 22.04 image. Set the parameters (CPU, RAM, disk); the minimum configuration is enough for a test. Launch the server and connect to it via SSH. Step 2. Install Docker and Docker Compose This can be done in two commands: curl -fsSL https://get.docker.com -o get-docker.sh   sh get-docker.sh  Wait until the commands finish executing. Step 3. Create a Docker Compose file Create a folder for the project and a configuration file: mkdir keycloak && cd keycloak   nano docker-compose.yml  Insert the following content: services: keycloak: image: quay.io/keycloak/keycloak:26.3.2 command: start-dev environment: - KEYCLOAK_ADMIN=admin - KEYCLOAK_ADMIN_PASSWORD=admin ports: - "8080:8080" restart: always Save with the key combination Ctrl+O, then Enter to confirm. Close the editor with the combination Ctrl+X. Step 4. Start Keycloak Use the command: docker compose up -d In a minute, Keycloak will be available at: http://<your_IP>:8080 Step 5. Disable the HTTPS requirement (only for testing) By default, Keycloak requires HTTPS even in dev mode, which may result in the message “HTTPS required” when opening. To disable this behavior only in the test environment, run the following commands inside the Keycloak container: docker exec -it keycloak-keycloak-1 /opt/keycloak/bin/kcadm.sh config credentials --server http://localhost:8080 --realm master --user admin --password admin   docker exec -it keycloak-keycloak-1 /opt/keycloak/bin/kcadm.sh update realms/master -s sslRequired=NONE  After this, you can refresh the page; the HTTPS message will disappear. Now you can log in to the panel with the username and password admin. Basic Keycloak Configuration After successfully launching the container with Keycloak, you will get the admin panel at the address: http://<your-server>:8080/admin   This is where all configuration takes place: from creating realms to connecting clients, roles, and users. Realms In Keycloak, everything starts with a realm. It’s like a separate “world” with its own database of users, security settings, and applications. Imagine you are building a platform with two projects: an internal portal for employees and a website for clients. Each has its own users, its own roles, its own login settings. To avoid storing everything together, you create two realms: staff and clients. They are completely isolated from each other: logins, rules, login pages, and even password policies can be configured differently. A realm is a way to maintain order in the system and not mix users from different applications. Let’s create our own realm. To do this, go to the Manage realms tab (1) in the admin panel and click the Create realm button (2). Navigation to creating a realm in Keycloak: the “Manage realms” tab and the “Create realm” button Next, enter the realm name and click the Create button. Realm creation form: entering the name and confirming by clicking “Create” Go back to the Manage realms tab and click on the new realm; now it is selected by default. If you are testing Keycloak, disable the SSL certificate requirement for the new realm; it is not required in the test environment. Use: docker exec -it keycloak-keycloak-1 /opt/keycloak/bin/kcadm.sh update realms/<NEW_REALM_NAME> -s sslRequired=NONE   Users and Roles Users are people or services that will log into your applications through Keycloak. Each has its own username, password, and set of permissions. Users without assigned roles do not get access to any functions. To determine what they can and cannot do, roles are assigned to them. Roles are labels like “admin,” “manager,” “viewer.” They don’t do anything by themselves, but they let the application know: “this person is an admin, they can delete; and that one can only view.” Create your own role. To do this, go to the Realm roles tab (1) and click the Create role button (2). Navigation to the roles section: the “Realm roles” tab and the “Create role” button for creating a new role Enter the role name and click the Save button. Creating a role Now let’s try creating a user. Go to the Users tab and click the Add user button. Be sure to enter a username, and optionally an email, first name, and last name. Click Create. Creating a user: specify the parameters and save with the “Create” button Assign the new user a password for login. To do this, on the opened page, go to the Credentials tab (1), click the Set password button (2), set the password and repeat it. Leave the Temporary parameter enabled so that the new user changes their password after their first login into the system. Assigning login credentials: open the “Credentials” tab and enter the password of the new user Now assign the new user a role. In the same section, go to the Role mapping tab (1), click the Assign role button (2) → Realm roles (3). Assigning a role: open the “Role mapping” tab and select the desired role via “Assign role” → “Realm roles” Select the role and click Assign. Selecting a role from the list and confirming the assignment with the “Assign” button Now the role is assigned to the user. Clients Clients in Keycloak are applications that connect to the authorization system. Through them, the user logs into the service, and Keycloak verifies their identity and rights. Without a client, the system will not understand where the user came from, where to return them after login, and what permissions can be given. For each client, you can configure the login method: by username and password, through social networks, with two-factor authentication, or with tokens. You can allow or deny specific roles. You can specify where to redirect the user after successful login and after logout. Important: the same user can log into different clients. For example, in the frontend client, they log in as a regular user, and in the admin-panel client as a moderator. This is convenient when the application has multiple interfaces with different access levels. Authorization begins with the client. The application redirects the user to Keycloak. It verifies their data and returns them with a token. And the application uses this token to find out who it is dealing with and what is allowed for them. Create a test client. Go to the Clients tab and click the Create client button. Enter the client name in the Client ID field. At the Login settings step, in the Valid redirect URIs field, enter valid paths where the user can be redirected after authorization. For testing, you can leave an asterisk *. The other values can be left by default. Screen after creating a client in Keycloak Configuring Authorization for Applications Keycloak can be connected to almost any application: a frontend in React, a backend in Flask, a native desktop, or a mobile app. Keycloak itself implements standard protocols OAuth 2.0 and OpenID Connect, which means the application does not depend on the platform: if it supports authorization via the standard, it can work with Keycloak. The connection process is always roughly the same. The application redirects the user to Keycloak. It requests their login and password and returns a code. The application exchanges the code for a token and starts working with it. From that moment, the user is considered authorized. You can check their rights, roles, and accesses. On the Keycloak side, the application is set up as a client, for which authorization scenarios and access restrictions are defined in the interface. All these settings depend on the type of application and its capabilities. For example, if the user is writing a regular website, the standard flow will be enough. And if you want to authorize an IoT device, most likely, you will need to use the client credentials flow without user participation. Here's an example of configuring environment variables in the .env file for connecting to Keycloak. In your case, you would enter the IP address or domain of your server instead of the one shown there, and change the realm to the one you created. # Keycloak configuration KEYCLOAK_URL=http://166.1.227.100:8080 KEYCLOAK_REALM=master KEYCLOAK_CLIENT_ID=test-client KEYCLOAK_CLIENT_SECRET=your-client-secret KEYCLOAK_ADMIN_USERNAME=admin KEYCLOAK_ADMIN_PASSWORD=admin # Server configuration PORT=3000 SERVER_URL=http://166.1.227.100:3000 SESSION_SECRET=your-session-secret-change-this # Application URLs (must match Keycloak client configuration) APP_URL=http://166.1.227.100:3000 VALID_REDIRECT_URIS=http://166.1.227.100:3000/*,http://166.1.227.100:3000/oauth2/callback/* Integration with External Services Keycloak can be used not only for your own projects but also for logging into third-party services—for example, GitLab, Jenkins, or Grafana. This is especially convenient if you want to implement single sign-on (SSO) for the team. Documentation for integrating any service with Keycloak can be found publicly. As an example, let’s look at setting up authorization through Keycloak for GitLab. For this, you will need docker-compose and basic configuration in the control panel. Note that in this case, external services require the mandatory presence of an SSL certificate so that Keycloak can ensure secure login. For this, you will need your own domain. Here, it will be convenient to create two additional subdomains, for GitLab and for Keycloak, respectively. If GitLab is already installed, you can add the settings manually. But it’s simpler to deploy everything together right away. Below is an example docker-compose.yml that launches Keycloak and GitLab, already configured to work with each other. Don’t forget to put your domain instead of example.com. version: "3.9" services: traefik: image: traefik:v3.1 container_name: traefik command: - "--api.dashboard=true" - "--providers.docker=true" - "--entrypoints.web.address=:80" - "--entrypoints.websecure.address=:443" - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true" - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - "--certificatesresolvers.letsencrypt.acme.email=admin@example.com" - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports: - "80:80" - "443:443" volumes: - "./letsencrypt:/letsencrypt" - "/var/run/docker.sock:/var/run/docker.sock:ro" restart: unless-stopped networks: - app-network gitlab: image: gitlab/gitlab-ce:latest container_name: gitlab hostname: gitlab.example.com volumes: - gitlab-config:/etc/gitlab - gitlab-logs:/var/log/gitlab - gitlab-data:/var/opt/gitlab restart: unless-stopped environment: GITLAB_OMNIBUS_CONFIG: | external_url 'https://gitlab.example.com' nginx['listen_https'] = false nginx['listen_port'] = 80 gitlab_rails['omniauth_enabled'] = true gitlab_rails['omniauth_allow_single_sign_on'] = ['openid_connect'] gitlab_rails['omniauth_auto_link_user'] = ['openid_connect'] gitlab_rails['omniauth_block_auto_created_users'] = false gitlab_rails['omniauth_providers'] = [ { name: "openid_connect", label: "Keycloak", args: { name: "openid_connect", scope: ["openid", "profile", "email"], response_type: "code", issuer: "https://keycloak.example.com/realms/master", discovery: true, client_auth_method: "query", uid_field: "preferred_username", client_options: { identifier: "gitlab", secret: "secret", redirect_uri: "https://gitlab.example.com/users/auth/openid_connect/callback" } } } ] labels: - "traefik.enable=true" - "traefik.http.routers.gitlab.rule=Host(`gitlab.example.com`)" - "traefik.http.routers.gitlab.entrypoints=websecure" - "traefik.http.routers.gitlab.tls.certresolver=letsencrypt" - "traefik.http.services.gitlab.loadbalancer.server.port=80" networks: - app-network keycloak: image: quay.io/keycloak/keycloak:26.3.2 container_name: keycloak command: start-dev environment: KC_HOSTNAME: https://keycloak.example.com KC_HOSTNAME_STRICT: false KC_HOSTNAME_HTTPS: true KC_PROXY: edge KC_HTTP_ENABLED: true KEYCLOAK_ADMIN: admin KEYCLOAK_ADMIN_PASSWORD: admin labels: - "traefik.enable=true" - "traefik.http.routers.keycloak.rule=Host(`keycloak.example.com`)" - "traefik.http.routers.keycloak.entrypoints=websecure" - "traefik.http.routers.keycloak.tls.certresolver=letsencrypt" - "traefik.http.services.keycloak.loadbalancer.server.port=8080" networks: - app-network volumes: gitlab-config: gitlab-logs: gitlab-data: networks: app-network: driver: bridge In the project, Traefik is used as a reverse proxy. It will automatically issue free Let’s Encrypt SSL certificates for the subdomains. Launch the project: docker compose up -d In the Keycloak admin panel, create a client gitlab, where you specify: Root URL — the GitLab domain with the https protocol. For example, https://gitlab.example.com. Valid redirect URIs — the GitLab domain with the https protocol and all possible paths under this domain. For example, https://gitlab.example.com/*. The default realm is master. If desired, you can create a separate realm. Users for GitLab and other services are created manually through the Keycloak admin panel. After loading GitLab, go to the login page at the domain belonging to GitLab. The service will offer to log in via Keycloak: GitLab login screen with an available option to log in via Keycloak After successful authorization via Keycloak, the editing panel of the new user created after authorization will open. GitLab new user settings window after authorization via Keycloak Troubleshooting Common Issues Sometimes errors occur when deploying and configuring Keycloak, both in the panel itself and during integration with other services. Below we’ve collected common symptoms, causes, and solutions so you can quickly fix the problem and continue setup. Symptom Problem Solution “HTTPS required” in the browser or logs Keycloak требует HTTPS даже в dev-режиме Keycloak requires HTTPS even in dev mode: docker exec -it keycloak-keycloak-1 bash./kcadm.sh config credentials --server http://localhost:8080 --realm master --user admin --password admin ./kcadm.sh update realms/master -s sslRequired=NONE Keycloak UI loads endlessly Error due to incorrect KC_HOSTNAME or CORS Make sure the KC_HOSTNAME variable is not set or matches the address where you are opening Keycloak Keycloak does not save sessions/settings Launched without volume, state is not saved Add a volume in docker-compose.yml:- keycloak_data:/opt/keycloak/data Error Web Crypto API is not available React application is running in an environment without HTTPS or in an old browser Run via HTTPS or in a modern browser. On a dev server, use localhost A 'Keycloak' instance can only be initialized once Multiple Keycloak initializations in React Make sure initialization happens only once, for example, in a separate keycloak.js file, not in each component Ssl connect returned=1 errno=0 ... in GitLab GitLab requires HTTPS, but Keycloak is running over HTTP Temporarily disable SSL requirement in Keycloak (dev only), or configure HTTPS with a self-signed or Let’s Encrypt certificate After login, the user is not created in GitLab Automatic user creation disabled in GitLab Make sure the parameters are set:omniauth_auto_link_user = ['openid_connect'] и omniauth_block_auto_created_users = false  The login button via Keycloak does not appear Error in omniauth_providers or issuer Check client_id, issuer, and redirect_uri in the GitLab configuration. They must exactly match the client in Keycloak Keycloak does not start Old docker-compose file or wrong image version Make sure you are using the current image (for example, quay.io/keycloak/keycloak:26.3.2) and the start-dev startup command Conclusion If you are creating a web application and want to quickly launch authorization, Keycloak becomes an excellent solution. It eliminates routine tasks: logins, roles, sessions, social networks, access rights—everything is available right away. And if you’re looking for a reliable, high-performance, and budget-friendly solution for your workflows, Hostman has you covered with Linux VPS Hosting options, including Debian VPS, Ubuntu VPS, and VPS CentOS. We covered how to deploy Keycloak on a server, configure the basic panel, connect React and Express applications, and integrate a third-party service like GitLab. This is a universal approach: once you configure Keycloak, you can add new services to it in just minutes and manage access from a single panel. This approach saves time, simplifies maintenance, reduces risks, and makes the system more secure. And most importantly, you no longer waste effort reinventing your own authorization.
05 September 2025 · 16 min to read
Ubuntu

How to Install VNC on Ubuntu

If you need to interact with a remote server through a graphical interface, you can use VNC technology.Through a network, users can connect remotely to a server using VNC (Virtual Network Computing). It employs the RFB protocol to send screen images and input data from different devices (such keyboards and mice) and runs on a client-server architecture. Ubuntu, Windows, macOS, and other operating systems are among those that VNC supports. The ability to connect several users at once is another benefit of VNC, which can be helpful for group tasks or training sessions. And if you’re looking for a reliable, high-performance, and budget-friendly solution for your workflows, Hostman has you covered with Linux VPS Hosting options, including Debian VPS, Ubuntu VPS, and VPS CentOS. In this guide, we will describe how to install VNC on Ubuntu, using a Hostman cloud server with Ubuntu 22.04 as an example. Finished installation of VNC on Ubuntu Step 1: Preparing to Install VNC Before starting the installation process on both the server and the local machine, there are a few prerequisites to review.  Here is a list of what you’ll need to complete the installation: A Server Running Ubuntu 22.04. In this guide, we will use a cloud server from Hostman with minimal hardware configuration. Hostman's plan selection in admin panel A User with sudo Privileges. You should perform the installation as a regular user with administrative privileges. Select a Graphical Interface. You’ll need to choose a desktop environment that you will use to interact with the remote server after installing the system on both the server and the local machine. A Computer with a VNC Client Installed.  At the moment, the console is the sole method of communication with a rented server running Ubuntu 22.04. You must install a desktop environment and VNC on the server in order to enable remote management through a graphical interface. The desktop environments and VNC servers that are compatible with Ubuntu servers are listed below. VNC Servers: TightVNC Server. One of the most popular VNC servers for Ubuntu. It is easy to set up and offers good performance. RealVNC Server. RealVNC provides a commercial solution for remote access to servers across various Linux distributions, including Ubuntu, Debian, Fedora, Arch Linux, and others. Desktop Environments: Xfce. A lightweight and fast desktop environment, ideal for remote sessions over VNC. It uses fewer resources than heavier desktop environments, making it an excellent choice for servers and virtual machines. GNOME. The default Ubuntu desktop environment, offering a modern and user-friendly interface. It can be used with VNC but will consume more resources than Xfce. KDE Plasma. Another popular desktop environment that provides a wide range of features and a beautiful design. The choice of VNC server and desktop environment depends on the user’s specific needs and available resources. TightVNC and Xfce are excellent options for stable remote sessions on Ubuntu, as they do not require high resources. In the next step, we will describe how to install them on the server in detail. Step 2: Installing the Desktop Environment and VNC Server To install the VNC server on Ubuntu along with the desktop environment, connect to the server and log in as a regular user with administrative rights. Update the Package List  After logging into the server, run the following command to update the packages from the connected repositories: sudo apt update Install the Desktop Environment  Next, install the previously selected desktop environment. To install Xfce, enter: sudo apt install xfce4 xfce4-goodies Here, the first package provides the basic Xfce desktop environment, while the second includes additional applications and plugins for Xfce, which are optional. Install the TightVNC Server  To install TightVNC, enter: sudo apt install tightvncserver Start the VNC Server  Once the installation is complete, initialize the VNC server by typing: vncserver This command creates a new VNC session with a specific session number, such as :1 for the first session, :2 for the second, and so on. This session number corresponds to a display port (for example, port 5901 corresponds to :1). This allows multiple VNC sessions to run on the same machine, each using a different display port. This command will ask you to create a password during the initial setup, which is necessary for users to access the server's graphical user interface. Don't forget to verify your password to run VNC on Ubuntu Set the View-Only Password (Optional)  After setting the main password, you’ll be prompted to set a password for view-only mode. View-only mode allows users to view the remote desktop without making any changes, which is helpful for demonstrations or when limited access is needed. If you need to change the passwords set above, use the following command: vncpasswd Now you have a VNC session. VNC on Ubuntu is running In the next step, we will set up VNC to launch the Ubuntu server with the installed desktop environment. Step 3: Configuring the VNC Server The VNC server needs to know which desktop environment it should connect to. To set this up, we’ll need to edit a specific configuration file. Stop Active VNC Instances  Before making any configurations, stop any active VNC server instances. In this guide, we’ll stop the instance running on display port 5901. To do this, enter: vncserver -kill :1 Simple command to stop VNC running on Ubuntu Here, :1 is the session number associated with display port 5901, which we want to stop. Create a Backup of the Configuration File  Before editing, it’s a good idea to back up the original configuration file. Run: mv ~/.vnc/xstartup ~/.vnc/xstartup.bak Edit the Configuration File  Now, open the configuration file in a text editor: nano ~/.vnc/xstartup Replace the contents with the following: #!/bin/bashxrdb $HOME/.Xresourcesstartxfce4 & #!/bin/bash: This line is called a "shebang," and it specifies that the script should be executed using the Bash shell. xrdb $HOME/.Xresources: This line reads settings from the .Xresources file, where desktop preferences like colors, fonts, cursors, and keyboard options are stored. startxfce4 &: This line starts the Xfce desktop environment on the server. Make the Configuration File Executable To allow the configuration file to be executed, use: chmod +x ~/.vnc/xstartup Start the VNC Server with Localhost Restriction Now that the configuration is updated, start the VNC server with the following command: vncserver -localhost The -localhost option restricts connections to the VNC server to the local host (the server itself), preventing remote connections from other machines. You will still be able to connect from your computer, as we’ll set up an SSH tunnel between it and the server. These connections will also be treated as local by the VNC server. The VNC server configuration is now complete. Step 4: Installing the VNC Client and Connecting to the Server Now, let’s proceed with installing a VNC client. In this example, we’ll install the client on a Windows 11 computer. Several VNC clients support different operating systems. Here are a few options:  RealVNC Viewer. The official client from RealVNC, compatible with Windows, macOS, and Linux. TightVNC Viewer. A free and straightforward VNC client that supports Windows and Linux. UltraVNC. Another free VNC client for Windows with advanced remote management features. For this guide, we’ll use the free TightVNC Viewer. Download and Install TightVNC Viewer Visit the official TightVNC website, download the installer, and run it. Download VNC from official website In the installation window, click Next and accept the license agreement. Then, select the custom installation mode and disable the VNC server installation, as shown in the image below. This is what you need to install Click Next twice and complete the installation of the VNC client on your local machine. Set Up an SSH Tunnel for Secure Connection To encrypt your remote access to the VNC server, use SSH to create a secure tunnel. On your Windows 11 computer, open PowerShell and enter the following command: ssh -L 56789:localhost:5901 -C -N -l username server_IP_address Make sure that OpenSSH is installed on your local machine; if not, refer to Microsoft’s documentation to install it. This command configures an SSH tunnel that forwards the connection from your local computer to the remote server over a secure connection, making VNC believe the connection originates from the server itself. Here’s a breakdown of the flags used: -L sets up SSH port forwarding, redirecting the local computer’s port to the specified host and server port. Here, we choose port 56789 because it is not bound to any service. -C enables compression of data before transmitting over SSH. -N tells SSH not to execute any commands after establishing the connection. -l specifies the username for connecting to the server. Connect with TightVNC Viewer After creating the SSH tunnel, open the TightVNC Viewer and enter the following in the connection field: localhost:56789 You’ll be prompted to enter the password created during the initial setup of the VNC server. Once you enter the password, you’ll be connected to the VNC server, and the Xfce desktop environment should appear. Stop the SSH Tunnel To close the SSH tunnel, return to the PowerShell or command line on your local computer and press CTRL+C. You found out how to install VNC on Ubuntu Conclusion This guide has walked you through the step-by-step process of setting up VNC on Ubuntu 22.04. We used TightVNC Server as the VNC server, TightVNC Viewer as the client, and Xfce as the desktop environment for user interaction with the server. We hope that using VNC technology helps streamline your server administration, making the process easier and more efficient. We're prepared more detailed instruction on how to create server on Ubuntu if you have some trouble deploying it.
21 August 2025 · 8 min to read
Servers

How to Correct Server Time

The method you choose for correcting the time on your server depends on how far off the server's clock is. If the difference is small, use the first method. If the clock is significantly behind or ahead, it's better not to adjust it in a single step — it's safer to change the time gradually. Configuration on Ubuntu/Debian Quick Fix To quickly change the time on the server, use the ntpdate utility. You need sudo privileges to install it: apt-get install ntpdate To update the time once: /usr/sbin/ntpdate 1.north-america.pool.ntp.org Here, the NTP pool is the address of a trusted server used to synchronize the time. For the USA, you can use NTP servers from this page. You can find pool zones for other regions at ntppool.org. You can also set up automatic time checks using cron: crontab -e 00 1 * * * /usr/sbin/ntpdate 1.north-america.pool.ntp.org This schedules synchronization once a day. Instead of a set interval, you can specify a condition. For example, to synchronize the time on every server reboot using cron reboot: crontab -e @reboot /usr/sbin/ntpdate 1.north-america.pool.ntp.org Gradual Correction To update the time gradually, install the ntp utility on Ubuntu or Debian. It works as follows: The utility checks data from synchronization servers defined in the configuration. It calculates the difference between the current system time and the reference time. NTP gradually adjusts the system clock. This gradual correction helps avoid issues in other services caused by sudden time jumps. Install NTP: apt-get install ntp For the utility to work correctly, configure it in the file /etc/ntp.conf. Add NTP servers like: server 0.north-america.pool.ntp.org server 1.north-america.pool.ntp.org iburst server 2.north-america.pool.ntp.org server 3.north-america.pool.ntp.org The iburst option improves accuracy by sending multiple packets at once instead of just one. You can also set a preferred data source using the prefer option: server 0.ubuntu.pool.ntp.org iburst prefer After each configuration change, restart the utility: /etc/init.d/ntp restart Configuration on CentOS The method choice rules are the same. If you need to correct a difference of a few seconds, the first method will do. For minutes or hours, the second method is better. Quick Fix To quickly adjust the time, use ntpdate. Install it with: yum install ntpdate For a one-time sync: /usr/sbin/ntpdate 1.north-america.pool.ntp.org Use Crontab to set automatic periodic synchronization. For daily sync: crontab -e 00 1 * * * /usr/sbin/ntpdate 1.north-america.pool.ntp.org To sync on boot instead of at regular intervals: crontab -e @reboot /usr/sbin/ntpdate 1.north-america.pool.ntp.org Gradual Correction To change the time on the server gradually, use ntp in CentOS. Install it: yum install ntp Enable the service on startup: chkconfig ntpd on In the file /etc/ntp.conf, specify accurate time sources, for example: server 0.north-america.pool.ntp.org server 1.north-america.pool.ntp.org iburst server 2.north-america.pool.ntp.org server 3.north-america.pool.ntp.org The iburst parameter works the same as in Ubuntu/Debian — it improves accuracy by sending a burst of packets. Restart the service after making changes: /etc/init.d/ntp restart Then restart the daemon: /etc/init.d/ntpd start Additional Options Time synchronization is usually done with the server closest to your server geographically. But in the configuration, you can specify the desired region directly in the subdomain. For example: asia.pool.ntp.org europe.pool.ntp.org Even if the NTP server is offline, it can still pass on system time. Just add this line: server 127.127.1.0 You can also restrict access for external clients. By default, these parameters are set: restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery The options notrap, nomodify, nopeer, and noquery prevent changes to the server's configuration. KOD (kiss of death) adds another layer of protection: if a client sends requests too frequently, it receives a warning packet and then is blocked. If you want to allow unrestricted access for the local host: restrict 127.127.1.0 To allow devices in a local network to sync with the server: restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap After any changes, restart the service: service restart ntp To check the service’s operation, use the command: ntpq -p It will display a table showing the time source address, server stratum, last synchronization time, and other useful data.
16 April 2025 · 4 min to read

Do you have questions,
comments, or concerns?

Our professionals are available to assist you at any moment,
whether you need help or are just unsure of where to start.
Email us
Hostman's Support