Remote Access Security Best Practices

Every server with an open SSH port is being attacked right now. Not might be. Is.

Automated scanners crawl the entire Internet continuously, probing every IP address for open remote access ports. When they find one, brute-force attacks begin immediately—thousands of username and password combinations tried in minutes. The credentials they try aren't random. They're harvested from data breaches, compiled from common defaults, refined by years of successful intrusions.

This isn't hypothetical. Check the authentication logs on any Internet-facing server. You'll see failed login attempts from IP addresses around the world, trying root, admin, ubuntu, deploy—with passwords like password, 123456, admin. Every few seconds. Forever.

Remote access security isn't about preventing some theoretical future attack. It's about ensuring the attacks happening right now—constantly—continue to fail.

The Three Barriers

Think of remote access security as three concentric barriers:

1. Can they reach the door? Network-level controls that determine whether an attacker can even attempt to connect.

2. Can they open the door? Authentication that verifies identity before granting access.

3. What can they do inside? Authorization that limits what authenticated users can access.

Strong security requires all three. A weakness in any barrier can compromise everything behind it.

Barrier One: Reaching the Door

The most effective security measure is making the door invisible.

Don't expose remote access to the Internet at all. Servers that don't need direct Internet access shouldn't have it. Put them on private networks (10.x.x.x, 172.16.x.x, 192.168.x.x) unreachable from outside. Require VPN connection before anyone can attempt SSH or RDP. The attack surface drops to zero for anyone who hasn't already authenticated to your VPN.

Use bastion hosts when Internet access is necessary. One hardened server accepts remote connections from the Internet. Everything else connects only through the bastion. Now you're securing one door instead of fifty.

Firewall by IP address when you can. If your team works from known locations with static IPs, configure firewalls to accept SSH connections only from those addresses. Attackers can't brute-force what they can't reach.

Changing the default port (moving SSH from 22 to something else) isn't real security—anyone scanning specifically for your server will find it. But it does reduce noise. Automated scanners hitting port 22 won't see your service, which means fewer log entries to sift through and fewer resources consumed rejecting garbage connections.

Barrier Two: Opening the Door

When attackers do reach your remote access service, authentication must hold.

SSH keys replace passwords. This isn't a recommendation—it's the baseline. Passwords can be guessed, stolen, phished. SSH keys are cryptographically strong. The private key never leaves your machine, never travels over the network. Disable password authentication entirely once keys are deployed:

ssh-keygen -t ed25519 -C "your_email@example.com"

Ed25519 is modern, fast, and secure. For systems requiring RSA compatibility, use 4096-bit keys minimum.

Protect private keys with passphrases. If someone steals your key file, the passphrase is your last defense. Without it, the key is useless.

Add multi-factor authentication for sensitive systems. Even if credentials are compromised—phishing happens, laptops get stolen—attackers can't proceed without the second factor. Hardware security keys like YubiKeys are strongest, resistant to phishing attacks that defeat SMS or app-based codes.

Disable root login. Administrators connect with personal accounts and escalate with sudo. This provides accountability (logs show who did what) and limits blast radius (compromised user credentials don't immediately grant full system access).

Certificate-based authentication solves key distribution at scale. A certificate authority issues short-lived certificates that servers automatically trust. No more managing authorized_keys files across hundreds of servers. Certificates expire automatically—no forgotten keys lingering for years.

Barrier Three: Limiting the Interior

Authentication confirms who someone is. Authorization determines what they can do.

Principle of least privilege: grant exactly the access required and nothing more. Database administrators get database access. Web developers get web server access. Nobody gets everything "just in case."

Just-in-time access beats permanent privileges. Users request elevated access for specific time windows and purposes. Access is approved, used, and automatically revoked. No accumulation of permissions over time.

Review access regularly. People change roles. People leave. Their access should change too. Quarterly reviews catch the developer who moved to marketing but still has production SSH access.

Encryption in Transit

Strong encryption prevents interception even if attackers can see the traffic.

Use modern protocol versions. SSHv1 has known vulnerabilities—it should be disabled everywhere. For RDP, enable Network Level Authentication and require TLS.

Configure strong cipher suites. Disable weak algorithms in sshd_config:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256

Verify host keys. That fingerprint prompt on first SSH connection isn't a formality—it's protection against man-in-the-middle attacks. If a host key changes unexpectedly, something is wrong. Investigate before connecting.

Watching the Doors

Security without visibility is hope without evidence.

Log everything: authentication attempts (successful and failed), session times, source IPs, commands executed. Send logs to a central system attackers can't reach to delete.

Monitor for patterns: multiple failed attempts from one IP, logins from unusual locations, access at strange hours, privilege escalation. Automated alerting catches attacks in progress.

Review logs regularly. Automated monitoring catches obvious attacks. Human review catches slow-moving intrusions and insider misuse that algorithms miss.

Staying Current

Remote access software has vulnerabilities. Updates fix them.

Enable automatic security updates where possible. Many Linux distributions install critical patches automatically.

Patch promptly. When you hear about a critical SSH or RDP vulnerability, you have days—not weeks—before attackers add it to their automated tools.

Know what you're running. You can't patch systems you've forgotten about. Inventory your remote access endpoints.

The Uncomfortable Truth

Perfect security doesn't exist. Every measure here reduces risk; none eliminates it. Defense in depth means that when one barrier fails—and eventually something will fail—other barriers hold.

The attacks are happening now. The question isn't whether your security will be tested. It's whether it will pass.