How to Secure Remote Access (SSH and RDP)

The safest SSH or RDP port is one that is invisible to the public internet. Use firewall rules and, where possible, a VPN or zero-trust gateway to ensure remote access ports are only reachable from trusted networks or specific IP ranges. Sensagraph continuously checks whether your remote access ports are exposed to the public internet.

• Block SSH (port 22) and RDP (port 3389) at your perimeter firewall for all source IPs except approved ranges.
• Require employees to connect through a VPN or a jump host before initiating an SSH or RDP session.
• Consider a zero-trust network access (ZTNA) solution for distributed teams instead of exposing ports directly.
• Use cloud provider security groups (AWS Security Groups, Azure NSGs, GCP firewall rules) as a second layer of enforcement.
• Review and remove any port-forwarding rules that expose internal RDP or SSH to the internet.

Running SSH on port 22 and RDP on port 3389 guarantees your service appears in every automated credential-stuffing and vulnerability scan. Changing to a high, non-standard port does not eliminate risk, but it dramatically reduces noise and buys time to detect real threats. Sensagraph scans for common alternative remote access ports and flags any that are unnecessarily exposed.

• Edit /etc/ssh/sshd_config and set Port to a non-standard value above 1024 (e.g., 2222, 22222).
• Change the RDP listening port in the Windows registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber.
• Update firewall rules to allow the new port and block the old one.
• Communicate the new port to all legitimate users and update any scripts, monitoring tools, or jump-host configs accordingly.

Passwords alone are insufficient for remote access. SSH supports public-key authentication which is cryptographically far stronger. RDP should be paired with multi-factor authentication (MFA). Eliminating password-based login removes the most commonly exploited attack vector in remote access breaches.

• Generate an SSH key pair with at least RSA 4096-bit or Ed25519: ssh-keygen -t ed25519 -C "your_email".
• Copy the public key to the server: ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.
• Disable password authentication in sshd_config: set PasswordAuthentication no and ChallengeResponseAuthentication no.
• Protect private keys with a strong passphrase and store them in a secrets manager or hardware security key (e.g., YubiKey).
• For RDP, integrate with an MFA provider (Microsoft Authenticator, Duo, or similar) using an RD Gateway or a third-party MFA agent.
• Enable Windows Hello for Business or smart-card authentication where available for RDP sessions.
• Never share SSH private keys between team members — issue individual keys per user.

The default sshd_config on many distributions enables legacy algorithms and permissive settings that weaken security. A hardened configuration reduces the attack surface to only what is genuinely needed.

• Set PermitRootLogin no — administrators should SSH as a regular user and escalate with sudo.
• Set AllowUsers or AllowGroups to explicitly whitelist which accounts can log in via SSH.
• Set MaxAuthTries 3 to limit failed authentication attempts per connection.
• Set LoginGraceTime 30 to reduce the window for slow brute-force attempts.
• Disable unused authentication methods: KerberosAuthentication no, GSSAPIAuthentication no.
• Restrict accepted ciphers and MACs to modern, secure algorithms — remove RC4, 3DES, MD5, and SHA-1 variants.
• Set ClientAliveInterval 300 and ClientAliveCountMax 2 to auto-terminate idle sessions.
• Disable X11 forwarding unless explicitly required: X11Forwarding no.
• Disable TCP forwarding if not needed: AllowTcpForwarding no.
• After making changes, validate the config with sshd -t before restarting the service.

Windows RDP has a history of critical vulnerabilities (BlueKeep, DejaBlue). Beyond patching, several configuration controls significantly reduce exposure.

• Enable Network Level Authentication (NLA): Group Policy → Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Require NLA.
• Set RDP to use TLS 1.2 or higher only; disable older TLS and SSL modes in Group Policy.
• Restrict RDP access to members of a dedicated security group rather than all authenticated users.
• Disable RDP on servers and workstations that do not require it: Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 1.
• Use Remote Desktop Gateway (RD Gateway) to broker and log all RDP connections, avoiding direct RDP exposure.
• Enforce session time limits and idle disconnection policies via Group Policy.
• Enable the Windows Firewall rule to allow RDP only from specific IP ranges or the internal network.

Even with strong authentication, brute-force and credential-stuffing attacks generate noise and can expose weaknesses in your rate-limiting. Layered protection ensures repeated failed attempts are automatically blocked.

• Install and configure Fail2Ban on Linux servers to automatically ban IPs after a configurable number of failed SSH attempts (e.g., 5 failures in 10 minutes).
• For Windows, use Windows Defender Firewall with a script or a tool like RdpGuard or Cyberarms IDDS to block repeat RDP failures.
• Configure OS-level account lockout: lock accounts after 5–10 failed login attempts and require admin unlock or a timed reset.
• Use /etc/hosts.deny and /etc/hosts.allow (TCP Wrappers) on Linux for additional IP-level restriction.
• Review Fail2Ban or equivalent logs weekly to identify persistent sources of attack and proactively block their IP ranges at the firewall.

You cannot respond to an intrusion you cannot see. Every remote access session — successful and failed — should be logged, centralised, and monitored for anomalies. Timely alerts are the difference between a contained incident and a full breach.

• Enable verbose SSH logging: set LogLevel VERBOSE in sshd_config to capture key fingerprints on every successful login.
• Ship SSH logs (/var/log/auth.log or /var/log/secure) and Windows Event Logs (Event IDs 4624, 4625, 4648) to a centralised SIEM or log management platform.
• Set up real-time alerts for: multiple failed logins from the same IP, successful login from a new geographic location, login at unusual hours, and privilege escalation events post-login.
• Enable Windows RDP audit logging: audit Logon/Logoff events and Terminal Services session events.
• Retain logs for a minimum of 90 days (or as required by your compliance framework) to support forensic investigation.
• Periodically test your alerting pipeline — trigger a test login failure and confirm the alert fires within the expected SLA.

Many of the most damaging SSH and RDP exploits target unpatched versions of OpenSSH, the Windows RDP stack, or underlying OS components. A disciplined patching cadence is non-negotiable. Sensagraph flags known-vulnerable service versions detected on your exposed ports.

• Subscribe to security advisories for OpenSSH, your Linux distribution, and Microsoft Windows.
• Apply critical security patches within 24–72 hours of release; schedule non-critical patches on a monthly cycle.
• Enable automatic security updates for Linux distributions: unattended-upgrades (Debian/Ubuntu) or dnf-automatic (RHEL/Fedora).
• Enable Windows Update to install security patches automatically, or integrate with WSUS/SCCM for enterprise control.
• Keep RDP client software (e.g., Remote Desktop app) updated on end-user devices as well — client-side vulnerabilities can also be exploited.
• Run a vulnerability scan after each major patch cycle to confirm that previously detected issues are resolved.

Access creep is one of the most common causes of remote access compromise. Former employees, contractors, and forgotten service accounts with SSH keys or RDP privileges are ready-made entry points for attackers. Regular audits keep your authorised-user list clean and current.

• Maintain an inventory of every account that has SSH or RDP access, including service accounts and CI/CD pipeline users.
• Review ~/.ssh/authorized_keys on every server at least monthly — remove keys belonging to departed team members immediately upon offboarding.
• Rotate SSH key pairs at least annually, or immediately after any suspicion of compromise.
• Audit Windows Local Users and Groups and Active Directory groups with RDP permission quarterly.
• Implement a formal offboarding checklist that explicitly includes revoking SSH keys, RDP access, and VPN credentials on the employee's last day.
• Use privileged access management (PAM) tooling to issue just-in-time, time-limited remote access credentials instead of persistent access.
• Schedule a full remote-access configuration review at least twice per year, using this checklist as a baseline.