Hostinger KVM 2 Review: Ubuntu Resources, SSH Security and Maintenance

I inspected one Hostinger KVM 2 VPS running Ubuntu 24.04 to examine its allocated resources, current SSH exposure, firewall posture and pending maintenance.

The short version: this server had a sensible private-access security baseline, but it was not maintenance-free. SSH was reachable over Tailscale and not through the public address during my test. UFW and fail2ban were active. A reboot, package updates and two PAM errors still needed attention.

Hostinger supplied this VPS test environment free of charge. TheLinuxForum may earn an affiliate commission at no extra cost to you. Prices, taxes, renewal rates and Hostinger terms can change, so check the current checkout terms before purchasing.

Test results at a glance

This was one server checked on one date. It is useful for understanding the condition of this machine, but it is not a benchmark or a guarantee that every Hostinger VPS will behave identically.

What resources did the KVM 2 VPS provide?

The guest reported 2 vCPUs, 7.8 GiB of memory, no swap and a 96 GiB ext4 root filesystem. It was running Ubuntu 24.04.4 LTS (Noble) on kernel 6.8.0-136-generic with x86_64 architecture.

The server had been running for 1 week, 3 days, 8 hours and 31 minutes when I checked it. These figures describe the allocated resources and current state; I did not run CPU, disk or network benchmarks.

Was SSH exposed to the public internet?

During the test, administrative access worked through Tailscale SSH. A separate connection attempt to TCP port 22 on the server’s public address timed out.

That is the outcome I wanted for a privately administered VPS: the private route worked while public SSH was unreachable from the test client. It remains a point-in-time result, not proof that every network path will always be blocked.

The effective SSH settings also showed:

• root login disabled;
• password authentication disabled;
• keyboard-interactive authentication disabled;
• public-key authentication enabled;
• a maximum of three authentication attempts;
• X11 forwarding disabled.

What firewall and brute-force protection were active?

UFW was active with incoming traffic denied by default and outgoing traffic allowed. The rules allowed private access through tailscale0 and UDP port 41641 for Tailscale.

fail2ban was also active, and its SSH jail was running. Together with key-only SSH and the private administration path, that gave this server a reasonable access-control baseline at the time of the check.

This does not make every future application or container safe. Any newly published service still needs its own exposure review.

What still needed maintenance?

The server was usable, but it was not fully up to date. Ubuntu reported that a reboot was required for linux-image-6.8.0-137-generic and linux-base. Updates were also available for the QEMU guest agent and Tailscale; Tailscale 1.102.2 was available while 1.98.10 was installed.

OpenSSH was running and systemd reported no failed units. However, the boot journal contained two error-level PAM messages stating that pam_lastlog.so could not be loaded. I did not apply updates, reboot the machine or investigate those PAM errors during this review.

Is Hostinger KVM 2 a sensible choice?

For someone who wants private administration, the machine was in a useful observed state: it reported 2 vCPUs and 7.8 GiB of memory, used key-only SSH, had a default-deny firewall and active fail2ban, and did not answer public SSH during the test. Whether those resources suit a particular service depends on that workload; I did not benchmark them.

The trade-off is operational responsibility. You remain responsible for updates, reboots, service exposure, backups and recovery. I would not treat this single check as proof of long-term performance or reliability, and I did not test Hostinger’s restore or recovery workflow.

My practical verdict: the server showed a reasonable access-control baseline on the test date, but maintenance was pending, two PAM errors still needed investigation, and recovery capability remained untested.