How to connect to VPS via SSH

Quick Answer: How to Secure a VPS

To secure a VPS, update the operating system, create a non-root administrative account, configure SSH key authentication, restrict remote access, enable a firewall, disable unnecessary services, and install security monitoring tools. You should also configure automatic security updates, protect application credentials, enable HTTPS for public-facing services, and maintain tested backups.

Update the operating system and install available security patches.
Create a separate administrative user and apply the principle of least privilege.
Configure SSH key authentication and restrict direct root access.
Enable a firewall and allow only the ports required by your applications.
Disable unnecessary services and remove unused software.
Configure automatic security updates and review system logs.
Install intrusion prevention and monitoring tools where appropriate.
Protect application secrets, databases, and administrative interfaces.
Use HTTPS, secure backups, and regularly test recovery procedures.
Audit the configuration periodically and investigate suspicious activity.

Securing a VPS (Virtual Private Server) is essential for protecting applications, business data, databases, and online services from unauthorized access and cyberattacks. Even if a hosting provider maintains the underlying infrastructure, the server owner is generally responsible for operating system updates, access permissions, firewall rules, application security, and data protection.

A secure VPS configuration combines several layers of protection. These include strong authentication, restricted administrative access, regular security updates, network filtering, intrusion detection, monitoring, and reliable backups. No single measure can eliminate every threat, but a layered approach significantly reduces the risk of compromise.

This guide explains how to secure a Linux VPS running Ubuntu Server, with practical commands and configuration examples. The same principles can be adapted to other Linux distributions and Windows-based virtual servers.

1. Understand VPS Security Fundamentals

A VPS provides an isolated virtual server with its own operating system, allocated resources, and administrative environment. This isolation does not automatically protect the server from weak passwords, vulnerable applications, exposed network ports, or incorrect access permissions.

Effective VPS security starts with identifying the components that need protection:

Administrative access: SSH, remote management tools, control panels, and privileged accounts.
Network services: Web servers, databases, APIs, mail services, and other applications listening on network ports.
Application data: Customer information, uploaded files, configuration files, and database records.
Credentials and secrets: Passwords, API tokens, SSH keys, database credentials, and encryption keys.
Availability: CPU, memory, storage, and network capacity needed to keep services operational.

Security requirements depend on how the VPS is used. A server hosting a personal website may need a relatively simple configuration, while an environment running customer-facing applications or sensitive business systems may require centralized logging, access controls, vulnerability scanning, and a formal incident response plan.

2. Update the Operating System

Outdated operating systems and software can contain publicly documented vulnerabilities. Attackers may exploit these weaknesses to gain unauthorized access, execute code, or disrupt services. Installing security updates is therefore one of the most important VPS maintenance tasks.

Install available updates on Ubuntu

Connect to the server using SSH and refresh the package lists:

sudo apt update

Install available package updates:

sudo apt upgrade

Review the proposed changes before confirming the installation. For maintenance windows where a broader package upgrade is appropriate, you can use:

sudo apt full-upgrade

The full-upgrade command may install or remove packages to resolve dependencies, so review its proposed actions before proceeding on a production server.

After updating, check whether a reboot is required and schedule it if necessary. Critical production environments should use a tested patching procedure that accounts for application compatibility, service availability, and recovery requirements.

Enable automatic security updates

Automatic security updates help reduce the time a server remains exposed to known vulnerabilities. On Ubuntu, you can install the unattended-upgrades package:

sudo apt install unattended-upgrades

Configure automatic updates according to your maintenance policy and verify that they are running as expected. Check the available configuration in /etc/apt/apt.conf.d/50unattended-upgrades and review update logs when troubleshooting.

Automatic updates do not replace regular maintenance. Third-party repositories, application dependencies, container images, and software installed outside the operating system package manager may require separate update procedures.

3. Secure SSH Access

SSH is one of the primary administrative interfaces for Linux VPS environments. Exposing SSH to the internet is common, but weak credentials and permissive configuration can make the service a target for automated attacks.

Create a non-root administrative account

Use a separate account for routine administration rather than performing every task as root. On Ubuntu, create a user and grant administrative privileges only when needed:

sudo adduser sysadmin
sudo usermod -aG sudo sysadmin

Replace sysadmin with your chosen username. Use sudo for administrative commands and avoid granting elevated permissions to accounts that do not require them.

Generate an SSH key pair

Generate the SSH key pair on your local computer, not on the remote server. The following command creates an Ed25519 key:

ssh-keygen -t ed25519 -C "[email protected]"

Use a strong passphrase to protect the private key. Keep the private key on your trusted device and never share it with other users. Only the public key should be installed on the server.

If your system supports ssh-copy-id, you can copy the public key to the administrative account:

ssh-copy-id sysadmin@SERVER_IP

Replace SERVER_IP with the actual server IP address. If password-based SSH authentication is currently enabled, you may need to use your existing authorized credentials to perform this step.

Connect using the new key to verify that authentication works:

ssh sysadmin@SERVER_IP

Disable direct root login and password authentication

After confirming that key-based access works, review the OpenSSH server configuration. On Ubuntu, the main configuration file is usually /etc/ssh/sshd_config. Some installations also use configuration fragments in /etc/ssh/sshd_config.d/, so check for conflicting settings before making changes.

Set the following options in the effective SSH server configuration:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

These settings disable direct root login and password-based SSH authentication while permitting public-key authentication. Confirm that you have a working administrative account and a valid SSH key before disabling password authentication. Otherwise, you could lock yourself out of the server.

Validate the configuration before reloading SSH:

sudo sshd -t

If the command returns no errors, reload the SSH service using the service name available on your system:

sudo systemctl reload ssh

Keep the existing SSH session open and test a new connection from another terminal. Do not close the original session until you have confirmed that the new connection works.

Restrict SSH access where possible

If you have a stable administrative IP address, restrict SSH connections to that address using the firewall or the network security controls provided by your hosting provider. For teams and production environments, a VPN, bastion host, or centralized access management solution can provide additional control.

Changing the default SSH port may reduce some automated scanning noise, but it is not a substitute for key-based authentication, access restrictions, and timely updates.

4. Configure a Firewall

A firewall limits the network connections that can reach your VPS. A secure baseline blocks unsolicited incoming connections and allows only the ports required by the applications you intend to expose.

Ubuntu includes UFW, a tool for managing firewall rules. Before enabling it, identify the actual SSH port and allow administrative access so that you do not accidentally disconnect yourself.

Set up UFW on Ubuntu

If SSH uses the default port, configure the firewall as follows:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

If SSH uses a custom port, add an allow rule for that port before enabling UFW. The OpenSSH profile may not match a custom port unless you have adjusted its definition.

For a public website, allow HTTP and HTTPS if they are required:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered

Do not open every port simply because an application might use it. Identify the required services and permit only the necessary traffic.

Verify exposed network ports

Use the following command to inspect listening TCP and UDP sockets:

sudo ss -tulpn

Review the output and identify services listening on public network interfaces. Database ports, internal APIs, monitoring interfaces, and administrative dashboards should not be publicly accessible unless there is a specific and properly secured requirement.

Remember that host-level firewall rules and provider-level network firewalls are separate controls. Review both, including IPv4 and IPv6 rules if the server supports both protocols.

5. Disable Unnecessary Services

Every installed application and running network service adds potential attack surface. Removing software you do not need and disabling unused services reduces the number of components that must be secured and maintained.

List active services with:

systemctl --type=service --state=running

Review enabled services that start automatically:

systemctl list-unit-files --type=service --state=enabled

Before disabling a service, confirm its purpose and dependencies. If you identify a service that is unnecessary, stop it and disable automatic startup. For example, the following commands apply only if you have confirmed that the named service is not required:

sudo systemctl stop SERVICE_NAME
sudo systemctl disable SERVICE_NAME

Replace SERVICE_NAME with the actual service name. Do not blindly disable system services, as doing so may break networking, logging, application dependencies, or remote administration.

Remove unused applications, test environments, default accounts, sample configurations, and outdated components when they are no longer needed. Keep the installed software set as small as practical for the server's intended role.

6. Protect Against Brute-Force Attacks

Brute-force attacks attempt to guess credentials by repeatedly submitting authentication requests. Publicly accessible SSH services and login pages often receive automated attempts from scanners and bots.

Key-based SSH authentication, disabling password login, restricting source IP addresses, and using strong unique credentials significantly reduce this risk. For services that still accept passwords, apply rate limiting, multi-factor authentication where supported, and account lockout controls appropriate to the application.

Install Fail2ban

Fail2ban can monitor supported log files and temporarily block IP addresses that repeatedly trigger configured authentication failures. On Ubuntu, install it with:

sudo apt update
sudo apt install fail2ban

Use a local configuration file rather than modifying the default configuration directly. For example, create /etc/fail2ban/jail.local with settings appropriate for your environment:

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

This example enables the SSH jail, using five failed attempts within ten minutes as the threshold and a one-hour ban. The exact settings and backend should be verified against your installed Fail2ban version and logging configuration.

Restart the service and inspect its status:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Fail2ban is an additional defensive measure, not a replacement for secure authentication. Ensure that legitimate administrators are not accidentally blocked and that the service monitors the correct logs.

7. Manage Users and Permissions

Incorrect user permissions can expose configuration files, private keys, application data, and administrative tools. Apply the principle of least privilege: every user and service should have only the permissions required to perform its assigned tasks.

Review user accounts and privileges

List local accounts and inspect which users have administrative privileges. Remove or disable accounts that are no longer needed, and review sudo access regularly.

For web applications and background processes, use dedicated service accounts instead of running everything as root. Separate administrative users from application users wherever practical.

Protect sensitive files

Restrict access to SSH private keys, configuration files, application secrets, and database credentials. For example, SSH directories and authorized key files should have appropriate ownership and permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

These commands assume you are operating on the intended user's SSH directory. Ensure the directory and files are owned by the correct account. Avoid applying broad recursive permission changes to system directories or application files without understanding the consequences.

Do not store passwords, API tokens, or private keys in public repositories, web-accessible directories, or application logs. Use environment-specific secret management and restrict who can read configuration files containing credentials.

8. Secure Applications and Databases

Securing the operating system is only one part of protecting a VPS. Vulnerable web applications, outdated frameworks, exposed databases, and insecure application configurations can still allow attackers to compromise the environment.

Update application dependencies: Keep frameworks, libraries, plugins, and runtime environments patched.
Remove unused components: Delete abandoned applications, test endpoints, sample files, and development tools from production systems.
Protect databases: Bind database services to private interfaces where possible and allow access only from trusted application servers.
Use separate credentials: Create dedicated database accounts with only the permissions required by each application.
Validate input: Apply server-side validation, parameterized queries, and appropriate access controls.
Protect sessions: Use secure cookie attributes, appropriate session expiration, and strong authentication for privileged functions.
Separate environments: Avoid exposing development and staging services to the public internet without a clear need.

For containerized deployments, keep base images and container packages updated, avoid running containers as root when possible, restrict container capabilities, and do not expose the Docker socket or other privileged management interfaces to untrusted users.

Review application logs for authentication failures, unexpected administrative actions, permission errors, unusual requests, and other indicators of suspicious activity.

9. Configure HTTPS and TLS

If your VPS hosts a website, API, or other public-facing service, configure HTTPS to protect data in transit and authenticate the server to connecting clients. Use a trusted TLS certificate and maintain a secure configuration supported by your web server and client requirements.

A basic HTTPS deployment should include the following steps:

Configure the domain's DNS records to point to the correct server IP address.
Set up the web server's virtual host or application endpoint.
Obtain a trusted TLS certificate from a certificate authority.
Configure HTTPS and redirect HTTP requests where appropriate.
Set up certificate renewal and monitor expiration dates.
Verify that only the necessary network ports are exposed.

For supported web server configurations, Let's Encrypt and compatible ACME clients can automate certificate issuance and renewal. Test renewal procedures instead of assuming that automation will always succeed.

HTTPS protects data transmitted between clients and the service, but it does not fix insecure application logic, weak account permissions, compromised credentials, or vulnerabilities on the server itself.

10. Detect Malware and Suspicious Activity

Malware detection and intrusion prevention tools can help identify suspicious files, unauthorized changes, and repeated authentication failures. However, no single tool can guarantee that a VPS is free from compromise.

Depending on the workload and risk profile, consider the following controls:

Fail2ban: Temporarily blocks sources that repeatedly trigger configured authentication failures.
ClamAV: Scans files for known malware signatures and may be useful on file-upload or mail-processing servers.
File integrity monitoring: Detects unexpected changes to important files and system configurations.
Endpoint detection tools: Provide additional visibility into suspicious processes and host activity when supported.
Vulnerability scanners: Help identify outdated packages, exposed services, and known configuration weaknesses.

Install tools only when they are appropriate for your environment, and configure them to avoid unnecessary resource consumption or conflicts with production applications.

If you suspect a compromise, do not rely solely on deleting suspicious files. Preserve relevant logs, restrict further unauthorized access, investigate the initial entry point, rotate affected credentials from a trusted device, and rebuild from a known-good image if system integrity cannot be established.

11. Monitor Logs and Server Resources

Monitoring helps detect security incidents, resource exhaustion, service failures, and unexpected configuration changes. Logs are especially important because a successful attack may not cause an immediate, obvious outage.

Inspect system logs

On Ubuntu, use systemd's journal to inspect service events and errors:

sudo journalctl -p err -b
sudo journalctl -u ssh --since "24 hours ago"
sudo systemctl --failed

Depending on the distribution and logging configuration, authentication events may also be available in files such as /var/log/auth.log. Verify the actual logging setup on your system.

Monitor resource usage

Check CPU load, memory, disk space, and active network listeners using standard system utilities:

uptime
free -h
df -h
ss -tulpn

For production systems, configure monitoring and alerts for unusual CPU usage, memory pressure, disk capacity, unexpected network traffic, service failures, and repeated authentication errors.

Restrict access to logs and monitoring dashboards. Avoid recording passwords, access tokens, private keys, or other secrets in log entries. Where appropriate, forward security-relevant logs to a separate, protected logging system so that an attacker who compromises the VPS cannot easily erase all evidence.

12. Configure Secure Backups

Backups help recover from accidental deletion, software failures, ransomware, and infrastructure incidents. They are a critical part of VPS security because preventing every incident is not realistic.

A reliable backup strategy should include:

Regular backups: Set a schedule based on how frequently data changes and how much data loss is acceptable.
Off-server storage: Keep copies separate from the VPS so that a server compromise does not automatically expose every backup.
Access restrictions: Limit who can view, modify, or delete backup data.
Encryption: Encrypt sensitive backups in transit and at rest where appropriate.
Retention policies: Keep enough historical copies to recover from incidents that are discovered late.
Recovery testing: Restore files, databases, and applications periodically to verify that the backups actually work.

RAID, snapshots, and backups serve different purposes. RAID can help maintain availability after certain disk failures, while snapshots can simplify point-in-time recovery. Neither should automatically be treated as a complete backup strategy, especially when snapshots remain on the same underlying storage.

Document recovery procedures, including the order in which services must be restored, where encryption keys are stored, and how administrators regain access during an emergency.

13. Protect Your VPS Against DDoS Attacks

A distributed denial-of-service (DDoS) attack attempts to overwhelm a service or its network capacity with excessive traffic or requests. Depending on the attack, it may exhaust bandwidth, connection limits, CPU, memory, or application resources.

Basic server hardening alone cannot mitigate every DDoS attack, particularly attacks that saturate the network connection before traffic reaches the VPS.

To reduce the impact of denial-of-service attacks:

Use network-level DDoS mitigation provided by your hosting provider or a specialized protection service.
Place public websites behind a suitable reverse proxy, CDN, or web application firewall where appropriate.
Apply application-level rate limits and connection limits based on expected traffic patterns.
Optimize application queries and resource-intensive endpoints to reduce the impact of abusive requests.
Monitor bandwidth, connection counts, request rates, and server resource consumption.
Document an escalation procedure for traffic floods and service disruption.

Choose protection based on the services you operate and the types of attacks you need to withstand. Confirm the mitigation capacity and response process with your provider rather than assuming that every VPS plan includes comprehensive DDoS protection.

14. VPS Security Checklist

Use this checklist when securing a new VPS or auditing an existing server.

Install all applicable operating system security updates.
Use a supported operating system release.
Create a dedicated administrative account with limited privileges.
Configure SSH key authentication and test it before changing login policies.
Disable direct root login and password-based SSH authentication where appropriate.
Restrict SSH access by source IP or VPN where practical.
Enable a firewall and allow only required network ports.
Review listening services and disable unnecessary components.
Install and configure intrusion prevention tools where appropriate.
Protect database ports, application secrets, and management interfaces.
Configure HTTPS for public-facing web services.
Monitor system logs, authentication attempts, and resource usage.
Set up backups outside the primary server and test recovery.
Configure DDoS mitigation appropriate to the service's risk profile.
Document access procedures and maintain an incident response plan.
Review the security configuration regularly and after significant changes.

15. Common VPS Security Mistakes

Using weak or reused passwords

Weak credentials make accounts easier to compromise, especially when the same password is reused across services. Use unique passwords, a password manager, SSH keys, and multi-factor authentication wherever supported.

Exposing all network ports

Permissive firewall rules can expose databases, control panels, development tools, and administrative services to unnecessary risk. Allow only the traffic required by your server's intended role.

Disabling password authentication before testing SSH keys

Incorrect SSH configuration can lock administrators out of a remote server. Keep an existing session open and verify a new key-based connection before applying restrictive authentication settings.

Assuming that backups are always recoverable

A backup that has never been restored is an untested recovery mechanism. Perform regular restoration tests and protect backup credentials from compromise.

Ignoring application-level vulnerabilities

A properly configured firewall cannot compensate for vulnerable application code, exposed secrets, or excessive database permissions. Maintain application dependencies and review the security of the entire deployment.

Relying on a single security tool

A firewall, malware scanner, or intrusion prevention tool addresses only part of the threat landscape. Combine preventive controls with monitoring, backups, access management, and incident response procedures.

Conclusion

Securing a VPS requires more than installing a firewall or changing an SSH port. A dependable configuration combines timely security updates, strong authentication, restricted privileges, minimal exposed services, protected application data, monitoring, and tested backups.

Start with the highest-impact measures: update the system, secure SSH, configure firewall rules, remove unnecessary services, and protect sensitive credentials. Then add monitoring, intrusion prevention, backup automation, HTTPS, and DDoS mitigation according to your workload and risk profile.

VPS security is an ongoing process. Review access permissions, patch software, investigate suspicious events, test recovery procedures, and reassess the configuration whenever the server's role changes.

If you need infrastructure for websites, APIs, business applications, or development environments, explore Cloud2Y VPS hosting and choose a configuration that matches your performance, availability, and security requirements.