Lock Down Your VPS: Advanced SSH Settings for Bulletproof Security

Running a VPS opens many possibilities, but the same accessibility that makes VPSes useful also makes them a target. SSH is the primary remote administration interface for Linux servers, and misconfigured SSH is a common vector for compromise. This article walks through advanced SSH hardening techniques you can deploy on your VPS to achieve near bulletproof security while preserving manageability for sysadmins, developers, and operations teams.

Why SSH hardening matters: principles and threat model

SSH provides encrypted shell access, file transfer (SCP/SFTP), and port forwarding. However, default installations often leave several insecure defaults: password authentication enabled, root login permitted, default port 22, and no rate-limiting or intrusion mitigation. Adversaries exploit these weaknesses via automated brute-force attempts, credential stuffing, or targeted attacks leveraging stolen keys.

Hardening SSH aims to reduce the attack surface and increase the cost of attack by enforcing strong authentication, limiting access, containing compromises, and detecting/mitigating malicious activity. The techniques below combine authentication hardening, access control, network defenses, monitoring, and containment.

Authentication: move beyond passwords

Deploy public-key authentication only

The single most effective step is to disable password authentication and require SSH key pairs (ED25519 or RSA at least 3072-bit). Public-key authentication eliminates the bulk of automated password attacks and forces adversaries to obtain private keys to gain access.

• Edit /etc/ssh/sshd_config and set PasswordAuthentication no, ChallengeResponseAuthentication no, and UsePAM no (if not using PAM-authenticated methods).
• Enable specific key types such as PubkeyAcceptedKeyTypes +ssh-ed25519 and prefer ED25519 for smaller size and strong security.

Harden private keys and use passphrases

Require passphrases on private keys and use a secure local key storage method (e.g., hardware-backed keystores or encrypted filesystems). Encourage use of SSH agents for day-to-day workflow but configure agent forwarding only when necessary and understand the risks.

Add multi-factor authentication (MFA)

For an additional layer, integrate MFA. Options include:

• Time-based one-time passwords (TOTP) via Google Authenticator or FreeOTP through libpam-google-authenticator.
• Hardware-backed authentication using U2F/WebAuthn or YubiKey via pam-u2f or pam_yubico.

When using MFA, keep key-based login as the primary factor and require the second factor through PAM. This resists key theft attacks and stolen passphrases.

Access control: limit who and where can connect

Disable direct root login and use sudo

Disable PermitRootLogin in sshd_config to force administrative tasks through non-root accounts with sudo. This creates an audit trail and reduces the blast radius of a single credential compromise.

Strict AllowUsers/AllowGroups and forced commands

Limit which accounts can use SSH by setting AllowUsers or AllowGroups. For service accounts (e.g., Git or backup system users) enforce forced commands in authorized_keys to restrict a key to a single permitted action:

• Use the command="..." option in the authorized_keys file for per-key command restriction.
• Combine with no-agent-forwarding,no-pty,no-X11-forwarding to harden non-interactive keys.

Use network-level restrictions

Restrict access at the network level with firewall rules (iptables/nftables, ufw) and cloud provider security groups. Allow SSH from specific management subnets, corporate IPs, or via bastion hosts only. This reduces the exposure to internet-wide scanners.

Advanced network defenses and intrusion mitigation

Change the default port — but don’t rely on obscurity

Moving SSH off port 22 (e.g., to 2222) reduces automated noise from generic scanners, but it’s not a true security control. Combine port changes with strong authentication and network restrictions for real benefit.

Rate limit and block brute-force attempts

Use tools like fail2ban, sshguard, or crowdsec to monitor logs and temporarily ban IPs showing malicious patterns. Configure short-term bans with exponential backoff to deter repeat offenders without blocking legitimate admins due to transient mistakes.

• For high-frequency attacks, configure connection tracking in the firewall to rate-limit TCP SYNs to the SSH port.
• Use the firewall to drop or reject connection attempts after threshold hits for balance between stealth and visibility.

Port knocking / Single Packet Authorization (SPA)

For extremely sensitive systems, consider port knocking or SPA mechanisms. With SPA, a client must send a cryptographically-signed packet to a guardian process to open an ephemeral firewall rule for SSH. This hides SSH from casual scanning and can be paired with key auth and MFA.

Containment and least privilege

Chroot and restricted shells

For service accounts that require SFTP-only access, configure chrooted SFTP in OpenSSH to restrict filesystem access. For interactive accounts, consider restricted shells or RBAC mechanisms to limit available commands.

Minimize installed services and surface area

Run as few daemons as possible on the VPS. Each service increases potential entry points. Where possible, isolate functions into separate VMs/containers and minimize cross-access.

Monitoring, logging, and alerting

Centralize logs and enable audit

Forward auth logs to a central logging system (rsyslog, syslog-ng, or an ELK/Graylog stack). Monitor for unusual authentication patterns: repeated failed logins, rare usernames, logins at odd hours, or logins from new geographies. Maintain sufficient retention to investigate incidents.

Use file integrity monitoring and session recording

Tools like AIDE or Tripwire can detect unauthorized changes to key files like /etc/ssh/sshd_config or authorized_keys. For sensitive environments, use SSH session recording (audit logging or ttyrec) on bastion hosts to retain command histories for compliance and incident response.

Harden configuration options in sshd_config

Key recommended options to set in /etc/ssh/sshd_config:

• Protocol 2 — disallow the deprecated SSHv1.
• PermitRootLogin no — force sudo-based admin workflows.
• PasswordAuthentication no — enforce key-based auth.
• PermitEmptyPasswords no and UseDNS no (speeds up auth).
• MaxAuthTries 3 — lower brute-force attempt window.
• LoginGraceTime 30s — reduce timeouts for unauthenticated connections.
• AllowTcpForwarding no and X11Forwarding no unless explicitly required.
• Banner /etc/issue.net — show legal notices for clarity (optional).

Remember to test any changes on a secondary session before terminating your primary connection to avoid lockouts.

Operating system and kernel-level protections

Harden the OS to mitigate escalation after an SSH compromise:

• Keep the system up-to-date with security patches for OpenSSH, kernels, and libraries.
• Enable SELinux or AppArmor to enforce mandatory access controls and limit process capabilities.
• Harden PAM configurations, disabling weak modules and enforcing account lockouts.
• Limit sudo privileges with carefully defined sudoers entries and avoid NOPASSWD wherever possible.

Use bastion hosts and jump servers

Centralize remote administration through hardened bastion hosts. All admins connect to the bastion and then to internal servers, enabling:

• Consolidated logging and session recording.
• Strict network ACLs that only allow bastion IPs to reach internal SSH ports.
• Simplified key lifecycle and rotation management.

Operational best practices and key management

Security is as much people and process as it is technology. Enforce policies:

• Rotate keys periodically and remove stale public keys from user accounts.
• Perform periodic audits of authorized_keys, sudoers, and user accounts.
• Use configuration management (Ansible, Puppet, Salt) to keep SSH configurations consistent and auditable.
• Maintain an incident response plan and tested recovery steps for locked-out admins.

Choosing the right VPS and deployment considerations

When selecting a VPS provider or plan for sensitive workloads, consider these factors:

• Network controls: ability to configure private networks, restrict inbound rules, and create security groups.
• Instance recovery: snapshot and backup capabilities to recover quickly after compromise or misconfiguration.
• Performance: CPU and memory headroom for running intrusion detection agents and auditing tools without impacting services.
• Geographic location and compliance requirements for data sovereignty and latency.

For administrators who need to balance security with predictable latency and U.S.-based hosting, a provider with dedicated USA VPS plans can simplify compliance and connectivity for regional operations.

Summary

Locking down SSH requires a layered approach: eliminate weak authentication, restrict access, apply network-level defenses, contain potential compromises, and monitor continuously. Practical steps include enforcing public-key authentication, disabling root/password logins, integrating MFA, rate-limiting and blocking brute-force attempts, and using bastion hosts for centralized control. Complement these with OS hardening, logging, and sound operational procedures.

Implementing these measures will dramatically raise the bar for attackers and make your VPS a far tougher target. If you’re evaluating hosting options while planning a secure deployment, consider a provider with robust network controls, easy snapshotting, and U.S.-based infrastructure. Learn more about VPS hosting options at VPS.DO and check dedicated USA VPS plans at https://vps.do/usa/.