Server Security: Safe Starting Steps for a Linux VPS

For server security, first clarify which system you have authority over: on a shared hosting account, the operating system and firewall are managed by the provider, while on a managed Linux VPS, you make the basic settings yourself with an administrator account. This guide shows how to handle updates, SSH access, the firewall, permission boundaries, and logs on a VPS in a controlled way.

Determine the environment before starting server security work

These procedures assume a remotely managed Linux VPS where you have an operating-system administrator account or sudo privileges. If the hosting panel lets you see only website, database, and email settings, do not try to change the SSH policy, kernel updates, or firewall. In that case, review the provider’s security options and access logs.

Before making changes, do not close your current SSH connection; keep a second administrator session open. Note the current SSH port, administrator users, firewall rules, and backup status. An incorrect rule, especially in remote-access settings, can block new connections. Therefore, change only one factor at a time and preserve the previous value so that it can be restored.

A secure starting sequence for server security on a Linux VPS

1. Review the operating system and package status. Check the maintenance or update screen in the management panel, as well as pending security updates in the distribution’s package manager. If security updates are available for the kernel, SSH server, or network components, first confirm that the provider’s snapshot or backup option is available, then update only from trusted repositories. After the update, check the system version and package status again. If critical packages are still pending, do not restart randomly before reviewing the application’s maintenance window and the provider’s instructions.
2. Switch SSH access to key-based authentication. First verify in a second session that a separate administrator user can log in with a key. If this connection works, gradually disable password login and direct root login in the SSH configuration, provided that your organization’s access procedure permits it; save the change and run the SSH service’s configuration validation. Open a new SSH connection with the same user: if the key is accepted, the setting is moving in the right direction; if it is rejected, restore the previous value before closing the open session. Before disabling password login, store a backup copy of the key in a secure, encrypted location.
3. Allow only necessary traffic through the firewall. In the firewall screen in the panel or operating system, assess the management port separately from the HTTP and HTTPS traffic used by the web application. If management access can be limited to specific office or VPN addresses, narrow the SSH rule to those sources; if there is no fixed source address, use a more cautious rule that preserves the current connection. Before applying the rule, check whether the provider offers emergency console access. Then test with a new SSH connection and the site’s normal HTTPS request; if the site works but SSH is interrupted, correct the management source or port rule, not the web rule.
4. Reduce permissions and running services. In the user and group screen, check that the application uses a separate user for file operations and that administrator privileges are limited to the maintenance account. In the service list, first identify unused database, file-sharing, or test services together with their configuration dependencies; address only those that are genuinely unnecessary by using the provider’s safe stop and disable options. If a web application needs write access, identify only the directory where the application actually writes instead of broadening permissions for the entire directory. If the write error does not disappear, do not assume that it is a quota limitation or an application error; inspect the new, timestamped lines in the application log separately.
5. Verify logs and the rollback plan. Determine which panel or log viewer contains failed SSH logins, administrator actions, firewall events, and application error logs. If you see an unexpected login, first revoke the relevant account’s key or session, then note the time and source address and compare them with other records; a single line does not prove the scope of an attack. After the change, perform the same administrator SSH login and the same HTTPS request again, and check the new records from the same time period for the expected successful access and the absence of unnecessary denied traffic. If the problem continues, do not add another change; restore the last setting and return to a safe state through the provider’s console access or restore-from-backup procedure.

Which setting should you address based on the symptom?

If login with a new SSH key succeeds while password attempts appear as failures in the logs, this indicates that the authentication method changed, not network access; preserve the key and recovery access before disabling passwords. Conversely, if the website opens over HTTPS but the administrator connection times out, do not change application settings; first inspect the firewall’s source-address and port rules.

Suppose a small VPS has a site that works only over HTTPS and SSH administration performed through a VPN. Limiting SSH to the VPN network instead of leaving it open to everyone is an appropriate choice that reduces the attack surface; however, this rule alone is not suitable if the team needs emergency access from outside the VPN. In that situation, preserve key-based access, a separate administrator account, and the provider’s emergency console path together rather than simply closing access.

Do not confuse backups with security settings

A backup does not automatically prevent incorrect configuration; it only provides a recovery option. Note the text copy of critical settings and the backup time, but do not place keys or credentials from logs in a publicly accessible location. After completing the basic controls for the application, you can compare the environment options on the server rental solutions page with your own management and access requirements.

The first safe next step is to keep the current SSH session open and test the key connection for the separate administrator account. Do not change password login, root access, or firewall rules until this connection has been verified; if verification fails, choose to regain access first and then address one setting at a time.