What Is Disabled by Default on Most Linux Servers (And Why It Matters)

When you provision a fresh Linux server — whether it's a VPS, a dedicated server, or a cloud-hosted virtual machine — the system boots into a deliberately minimalist and hardened environment. This is not an oversight or an incomplete setup. It is an intentional design philosophy baked into every major Linux distribution.

Modern Linux server builds strip away unnecessary services, protocols, and interfaces to minimize the attack surface, conserve system resources, and give administrators precise control over what runs on their infrastructure. Understanding what is disabled by default — and why — is foundational knowledge for any systems administrator, DevOps engineer, or developer managing production workloads.

This guide dissects the most common features and services that are disabled or absent by default on Linux servers, explains the security and operational rationale behind each decision, and shows you exactly how to verify each setting on your own system.

Why "Disabled by Default" Is a Security Strategy, Not a Limitation

The principle at work here is often called "secure by default, extensible by choice." Rather than shipping a fully featured system and trusting administrators to lock it down, modern Linux distributions ship a locked-down system and trust administrators to enable only what they need.

This approach directly reduces the risk of misconfiguration — one of the leading causes of server breaches. Every service that is not running is a service that cannot be exploited. Every protocol that is not enabled is a protocol that cannot be intercepted. Every open port that does not exist is an entry point that attackers cannot probe.

With that context established, let's examine each default restriction in detail.

1. Root SSH Login

Status: Disabled by default on virtually all modern Linux server distributions

Direct root login via SSH is universally disabled in contemporary Linux server builds — and for excellent reason. Allowing remote root access creates a single catastrophic failure point: one compromised password gives an attacker complete, unrestricted control over the entire system.

The correct workflow is to log in as a non-privileged user and escalate privileges using sudo or su only when necessary. This creates an audit trail, limits the blast radius of credential theft, and forces deliberate action before executing privileged commands.

How to verify:

grep PermitRootLogin /etc/ssh/sshd_config

Expected output on a properly hardened server:

PermitRootLogin no

If you see PermitRootLogin yes or PermitRootLogin prohibit-password, review your SSH configuration immediately and align it with your organization's security policy.

Best practice:

Create a dedicated administrative user, add it to the sudo group, and ensure PermitRootLogin no is set before deploying any public-facing service.

2. Password Authentication in SSH

Status: Disabled by default on most cloud-provisioned servers

On many cloud platforms and managed hosting environments, SSH password authentication is disabled entirely at provisioning time. SSH key pairs are the only accepted authentication mechanism.

This is a significant security improvement. Password authentication is vulnerable to brute-force attacks, credential stuffing, and dictionary attacks. SSH keys — particularly when protected by a passphrase — are computationally infeasible to brute-force with current technology.

Traditional ISO-based installations may still permit password logins by default, but the best practice is to disable them immediately after setting up key-based authentication.

How to verify:

grep PasswordAuthentication /etc/ssh/sshd_config

Expected output:

PasswordAuthentication no

How to disable password authentication:

Edit /etc/ssh/sshd_config and set:

PasswordAuthentication no
PubkeyAuthentication yes

Then reload the SSH daemon:

# Ubuntu/Debian
sudo systemctl reload ssh

# RHEL/AlmaLinux/Rocky Linux
sudo systemctl reload sshd

> Warning: Always confirm that your SSH key is working before disabling password authentication, or you risk locking yourself out of the server.

3. Legacy and Cleartext Network Protocols

Status: Absent from modern server builds

Services such as Telnet, FTP, Rlogin, and Rsh are not installed on modern Linux server images. These protocols were designed in an era before encryption was a priority. They transmit credentials, commands, and data in plaintext — making them trivially easy to intercept with a packet sniffer on any network segment between client and server.

These protocols have been superseded by secure alternatives:

How to verify no legacy services are running:

ss -tulnp

If ports 21 (FTP) or 23 (Telnet) do not appear in the output, those services are not active. If they do appear, investigate immediately and remove or disable them unless there is a specific, justified requirement.

4. Graphical User Interfaces (GUI)

Status: Not installed on server editions

Server distributions — including Ubuntu Server, Debian, AlmaLinux, Rocky Linux, and CentOS Stream — do not ship with graphical desktop environments such as GNOME, KDE Plasma, or XFCE. This is a deliberate and well-reasoned choice.

A GUI environment:

• Consumes significant RAM and CPU resources that should be dedicated to workloads
• Introduces a large number of additional software packages, each of which represents a potential vulnerability
• Is entirely unnecessary for server administration, which is performed via the command line over SSH

The expectation is unambiguous: servers are managed through the CLI. If you find yourself wanting a graphical interface on a production server, that is generally a signal that a process or workflow needs to be reconsidered.

> Note: Tools like VPS Control Panels — such as cPanel, Plesk, or DirectAdmin — provide web-based graphical management interfaces without requiring a full desktop environment to be installed on the server.

5. Development Toolchains and Compilers

Status: Not installed in minimal server images

Compilers such as gcc and build utilities such as make, cmake, and autoconf are intentionally absent from most minimal Linux server images. The rationale is twofold:

1. Reduced image size: Minimal images are faster to deploy, easier to back up, and consume fewer resources.
2. Security hardening: If an attacker gains access to a server, the absence of a compiler prevents them from compiling malicious binaries or exploit code directly on the system. This is a meaningful obstacle in many attack chains.

How to verify:

gcc --version

If the toolchain is not installed, you will see:

-bash: gcc: command not found

How to install if required:

# Ubuntu/Debian
sudo apt update && sudo apt install build-essential

# RHEL/AlmaLinux/Rocky Linux
sudo dnf groupinstall "Development Tools"

Install development tools only on servers where compilation is a genuine operational requirement — such as build servers or development environments — and avoid installing them on production application or database servers.

6. ICMP (Ping Responses)

Status: Enabled by default at the OS level; often restricted at the network/firewall level

Linux servers respond to ICMP echo requests (ping) by default at the operating system level. However, many hosting providers and cloud platforms block ICMP at the network firewall or security group level, making servers appear unreachable to ping even when they are fully operational.

Suppressing ICMP responses makes a server less discoverable during network reconnaissance scans. However, it also complicates legitimate monitoring and diagnostics — tools like ping and traceroute rely on ICMP to function correctly.

How to test:

ping your_server_ip

How to block ICMP at the OS level using iptables (if required):

sudo iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

The decision to block ICMP should be made deliberately, weighing the marginal security benefit against the operational cost to monitoring and troubleshooting workflows.

7. IPv6

Status: Enabled by default in most distributions; may be restricted at the provider level

IPv6 is enabled by default in modern Linux distributions including Ubuntu, Debian, Fedora, and RHEL derivatives. However, many hosting providers disable IPv6 at the network level if their infrastructure does not support it, meaning the OS may be configured for IPv6 but the server will have no routable IPv6 address.

How to check for IPv6 addresses:

ip a | grep inet6

If only ::1 (the loopback address) appears, IPv6 is not configured at the network level even if it is enabled in the OS.

If your workload does not require IPv6 and your provider does not offer it, you can disable it at the kernel level by adding the following to /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Then apply the change:

sudo sysctl -p

8. Unnecessary System Services and Daemons

Status: Varies by distribution; minimal installs disable most non-essential services

Beyond the items listed above, minimal Linux server installations typically disable or omit a range of services that are present on desktop or full-featured builds:

• Bluetooth — irrelevant on servers; not installed
• Avahi/mDNS — local network discovery; unnecessary and potentially a security concern on servers
• Cups (printing) — no use case on a server
• ModemManager — irrelevant on server hardware
• NetworkManager — often replaced by systemd-networkd or manual netplan configuration on servers

How to audit running services:

systemctl list-units --type=service --state=running

Review this list periodically and disable any service that does not serve a documented purpose on that specific server.

Practical Security Checklist for a Freshly Provisioned Linux Server

After provisioning a new server — whether it's shared web hosting upgraded to a VPS or a brand-new dedicated server — run through this checklist to confirm your baseline security posture:

Choosing the Right Hosting Environment for Your Security Requirements

The default security posture of your server is also influenced by the hosting environment you choose. A VPS with cPanel provides a managed, web-based interface that simplifies administration while preserving the underlying Linux security model. A bare-metal dedicated server gives you full control over every layer of the stack, from firmware to application.

For teams running SSL-secured web applications, pairing your server with a properly configured SSL certificate is an essential complement to server-level hardening — encrypting data in transit just as SSH key authentication protects access to the server itself.

Conclusion

Out-of-the-box Linux servers are provisioned in a deliberately secure, stripped-down state. Root SSH login is disabled. Password authentication is restricted or eliminated. Legacy cleartext protocols are absent. No graphical environment is installed. Compilers and build tools are excluded from base images.

By contrast, services such as ICMP responses and IPv6 remain enabled at the OS level by default, but are frequently restricted at the network or firewall layer depending on the provider's infrastructure and security posture.

This "secure by default, extensible by choice" philosophy ensures that administrators retain full agency over their environment. The server exposes only what is explicitly required for its intended role — nothing more. Every service you enable, every port you open, and every package you install is a deliberate decision with a documented justification.

That discipline is the foundation of operational security. It is not a limitation of Linux servers. It is precisely what makes them the platform of choice for production infrastructure worldwide.