SSH IP Authentication | NOC.org Support

SSH IP Authentication restricts SSH access to your origin server so that only connections from approved IP addresses are allowed. When your site is behind the NOC CDN and WAF, HTTP/HTTPS traffic flows through NOC's edge network, but SSH access to your server should be locked down to prevent unauthorized access. IP-based SSH restrictions add a critical layer of origin security.

Why Restrict SSH by IP

SSH is the primary way administrators access Linux servers for configuration, deployment, and troubleshooting. An open SSH port (typically port 22) is a constant target for brute force attacks, credential stuffing, and exploit attempts. Even with strong passwords and key-based authentication, leaving SSH open to the entire internet increases your attack surface.

IP-based restrictions ensure that only connections from known, trusted IP addresses can reach your SSH service. All other connection attempts are dropped at the firewall level before they can even attempt authentication.

Setting Up SSH IP Whitelisting

There are two approaches to restricting SSH access by IP: using your server's firewall or using NOC's origin protection features.

Using iptables (Linux)

Configure iptables to allow SSH only from specific IPs:

# Allow SSH from your office IP
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.10 -j ACCEPT

# Allow SSH from your home IP
iptables -A INPUT -p tcp --dport 22 -s 198.51.100.25 -j ACCEPT

# Drop all other SSH connections
iptables -A INPUT -p tcp --dport 22 -j DROP

# Save the rules (Debian/Ubuntu)
iptables-save > /etc/iptables/rules.v4

Using UFW (Ubuntu/Debian)

If you use UFW (Uncomplicated Firewall), the syntax is simpler:

# Allow SSH from specific IPs
ufw allow from 203.0.113.10 to any port 22
ufw allow from 198.51.100.25 to any port 22

# Deny all other SSH
ufw deny 22

# Enable UFW
ufw enable

Using firewalld (CentOS/RHEL)

For servers running firewalld:

# Create a zone for trusted SSH access
firewall-cmd --permanent --new-zone=ssh-trusted
firewall-cmd --permanent --zone=ssh-trusted --add-source=203.0.113.10/32
firewall-cmd --permanent --zone=ssh-trusted --add-source=198.51.100.25/32
firewall-cmd --permanent --zone=ssh-trusted --add-port=22/tcp

# Remove SSH from the default zone
firewall-cmd --permanent --zone=public --remove-service=ssh

# Reload
firewall-cmd --reload

Managing the Whitelist

Maintaining your IP whitelist requires ongoing attention:

• Document all whitelisted IPs: Keep a record of which IPs are whitelisted and who they belong to (office, home, VPN, CI/CD server).
• Use static IPs: Ensure your whitelisted IPs are static, not dynamic. If your ISP assigns dynamic IPs, use a VPN with a static exit IP for SSH access.
• Review regularly: Remove IPs that are no longer in use (former employees, old office locations, decommissioned servers).
• Use CIDR notation for ranges: If your office uses a block of IPs, whitelist the entire range (e.g., 203.0.113.0/24) rather than individual addresses.

Whitelisting NOC Edge IPs

When your site is behind the NOC CDN and WAF, HTTP/HTTPS traffic originates from NOC's edge IP addresses, not from visitor IPs directly. You should whitelist NOC's edge IP ranges on your origin server's HTTP/HTTPS ports (80 and 443) to ensure CDN traffic is not blocked by your firewall.

However, do not whitelist NOC edge IPs for SSH access. SSH connections should only be allowed from your own trusted IP addresses. The CDN does not proxy SSH traffic.

NOC publishes its current edge IP ranges in the dashboard under Account Settings > Edge IP Ranges. Use these ranges to configure your origin firewall for HTTP/HTTPS traffic.

Additional SSH Hardening

IP whitelisting should be combined with other SSH security best practices:

• Disable password authentication: Use SSH key pairs only. Set PasswordAuthentication no in /etc/ssh/sshd_config.
• Disable root login: Set PermitRootLogin no and use a regular user account with sudo privileges.
• Change the default port: Move SSH to a non-standard port (e.g., 2222) to reduce automated scan noise. This is not a security measure on its own but reduces log clutter.
• Use fail2ban: Even with IP restrictions, install fail2ban as an additional layer. It automatically bans IPs that fail authentication attempts.
• Keep SSH updated: Ensure your SSH server software (OpenSSH) is kept up to date to patch known vulnerabilities.

Troubleshooting Access Issues

If you are locked out of SSH after applying IP restrictions:

• Use your hosting provider's console: Most hosting providers and cloud platforms offer an out-of-band console (web-based terminal) that does not rely on SSH. Use this to fix firewall rules.
• Check your current IP: Your public IP may have changed if you are on a dynamic IP connection. Verify your current IP at a service like ifconfig.me before troubleshooting firewall rules.
• Review firewall rule order: Firewall rules are processed in order. Ensure your ALLOW rules appear before any DENY rules for port 22.