Linux & OS Intermediate

Troubleshooting Slow SSH Logins: Resolving DNS Reverse Lookup Delay on Ubuntu 20.04 LTS

Resolve SSH login delays on Ubuntu 20.04 LTS caused by DNS reverse lookup failures or misconfigurations in sshd. Optimize your server for faster access.

👨‍💻
Senior Systems Architect • Verified in Staging Labs

Resolve SSH login delays on Ubuntu 20.04 LTS caused by DNS reverse lookup failures or misconfigurations in sshd. Optimize your server for faster access.

Introduction

Experiencing a significant delay when attempting to SSH into your Ubuntu 20.04 LTS server can be a frustrating productivity drain. Instead of an immediate password prompt or shell, you might face a noticeable pause lasting anywhere from 5 to 30 seconds. While various factors can contribute to slow SSH connections, one of the most common culprits is a delay in DNS reverse lookup, where the SSH daemon (sshd) attempts to resolve the connecting client's IP address to a hostname. This guide will walk you through diagnosing and resolving this issue efficiently.

Symptom & Error Signature

The primary symptom is a delay after initiating an SSH connection or after successfully authenticating but before the shell prompt appears. There's often no explicit error message, just the elapsed time. You can observe this delay using the time command:

$ time ssh username@your_server_ip
# A long pause occurs here
username@your_server_ip's password: 
# (Another potential pause after password entry)
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-164-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

... (standard MOTD output) ...

username@your_server_ip:~$ exit
logout
Connection to your_server_ip closed.

real    0m18.523s  # This 'real' time indicates the total delay
user    0m0.015s
sys     0m0.009s

Occasionally, if the lookup fails completely, you might see related messages in the server's authentication log (/var/log/auth.log):

Jan  1 10:00:05 yourserver sshd[1234]: Failed reverse lookup for 203.0.113.42.

However, often the daemon simply waits for a timeout without explicit log entries, making diagnosis challenging without understanding the underlying mechanism.

Root Cause Analysis

The core of this problem lies with the OpenSSH server's default configuration, specifically the UseDNS directive, combined with potential issues in your server's DNS resolution capabilities or the absence of proper reverse DNS records for connecting clients.

  1. UseDNS yes in sshd_config: By default, sshd on many systems, including Ubuntu 20.04, has UseDNS enabled. When UseDNS is set to yes, the sshd daemon performs a reverse DNS lookup on the connecting client's IP address. This is primarily done for logging purposes (to log the client's hostname instead of just its IP) and for hostname-based authentication rules (e.g., AllowUsers or DenyUsers directives that specify hostnames instead of IPs).

    • Problem: If the client's IP address does not have a corresponding PTR (pointer) record configured in DNS, or if the DNS servers configured on your Ubuntu server are slow, unreachable, or misconfigured, the sshd process will wait for a DNS query timeout before proceeding. This timeout is typically what causes the multi-second delay.
  2. Misconfigured or Unresponsive DNS Servers on the SSH Server: Even if client PTR records exist, if your Ubuntu server's /etc/resolv.conf points to DNS resolvers that are slow, incorrect, or blocked by a firewall, any DNS query initiated by sshd (including reverse lookups) will suffer delays or fail. Ubuntu 20.04 uses systemd-resolved by default, which manages /etc/resolv.conf via a symlink.

  3. Firewall Blocking Outbound DNS (UDP/53): A local firewall (like ufw or iptables) on your server, or an upstream network firewall, might be blocking outbound UDP traffic on port 53, which is essential for DNS queries.

  4. GSSAPIAuthentication yes: While less common for typical web hosting setups, GSSAPIAuthentication can also introduce delays if Kerberos services are not available or misconfigured, as sshd might attempt to contact a Key Distribution Center (KDC) which relies on DNS.

Step-by-Step Resolution

Follow these steps to diagnose and resolve slow SSH logins due to DNS delays.

1. Verify DNS Resolution from Your Server

First, ensure your server can perform DNS lookups generally. This helps rule out a fundamental DNS issue.

# Check current DNS resolvers (on Ubuntu 20.04, this is usually a symlink to systemd-resolved)
cat /etc/resolv.conf

# Test forward DNS resolution
dig google.com

# Test reverse DNS resolution for a known public IP (e.g., Google DNS)
dig -x 8.8.8.8

# Test reverse DNS for the IP address you are connecting from
# Replace CLIENT_IP with your actual client machine's public IP
dig -x CLIENT_IP

If dig commands are slow, fail, or time out, your server's DNS configuration (or network connectivity to DNS servers) is an issue. Proceed to Step 4, then return here to re-test.

2. Modify sshd_config to Disable DNS Lookups

The most common and effective fix is to instruct sshd not to perform reverse DNS lookups.

  1. Open the sshd_config file:

    sudo nano /etc/ssh/sshd_config
    
  2. Locate and modify the UseDNS directive: Find the line UseDNS yes. If it's commented out (starts with #), it defaults to yes. Change it to:

    UseDNS no
    

    If UseDNS is not present, add it at the end of the file:

    UseDNS no
    

    Disabling UseDNS means sshd will log connecting clients solely by IP address. If you rely on hostname-based rules in sshd_config (e.g., AllowUsers [email protected]), these rules will no longer function correctly, as sshd won't resolve the client's hostname. For most server environments using IP-based security, this is a negligible risk.

  3. Locate and modify the GSSAPIAuthentication directive (Optional but Recommended): While less common as a primary cause, GSSAPIAuthentication can also introduce delays. For most web hosting environments, it's not needed. Find the line GSSAPIAuthentication yes. Change it to:

    GSSAPIAuthentication no
    

    If it's commented out, ensure it remains commented out or explicitly set it to no.

  4. Save and exit the editor.

  5. Restart the SSH service:

    After modifying sshd_config, you must restart the sshd service for changes to take effect.

    sudo systemctl restart sshd
    

    Keep your current SSH session open while testing. If your configuration change inadvertently locks you out, you can revert the changes in your existing session.

  6. Test the SSH connection: Try connecting from your client machine again. The delay should now be gone.

3. Optimize Your Server's DNS Resolvers

If UseDNS no fixed the issue, you might still want to ensure your server's DNS resolvers are optimal for other services. If dig was slow in Step 1, this step is critical.

On Ubuntu 20.04, systemd-resolved manages DNS. Direct edits to /etc/resolv.conf are often temporary because it's a symlink to ../run/systemd/resolve/stub-resolv.conf.

  1. Configure systemd-resolved: Edit the resolved.conf file:

    sudo nano /etc/systemd/resolved.conf
    
  2. Add or modify DNS and FallbackDNS: Uncomment and set DNS to reliable, fast public DNS servers. For example:

    [Resolve]
    DNS=8.8.8.8 1.1.1.1 8.8.4.4 1.0.0.1
    #FallbackDNS=
    #Domains=
    #DNSStubListener=yes
    #ReadEtcHosts=yes
    
    • 8.8.8.8 / 8.8.4.4: Google Public DNS
    • 1.1.1.1 / 1.0.0.1: Cloudflare DNS
  3. Save and exit the editor.

  4. Restart systemd-resolved:

    sudo systemctl restart systemd-resolved
    
  5. Verify changes: Check the new resolv.conf content and then re-test DNS resolution.

    cat /etc/resolv.conf
    # The 'nameserver' entry should now point to 127.0.0.53 (the local stub resolver)
    # The actual configured DNS servers are used by systemd-resolved internally.
    
    systemd-resolve --status | grep 'DNS Servers'
    # This command should show your configured public DNS servers.
    

4. Configure Proper Reverse DNS (PTR Records)

While disabling UseDNS is the direct fix for the server-side delay, implementing proper reverse DNS (PTR records) for your client IP addresses is a best practice. This ensures that when any service does perform a reverse lookup for your client IP, it resolves correctly to a hostname.

  • For static client IPs: Contact your ISP or cloud provider where your client machine's public IP address is allocated. Request them to set up a PTR record that maps your client's IP to a fully qualified domain name (FQDN) that you control (e.g., myclient.example.com).
  • For dynamic client IPs: It's generally not practical to manage PTR records for dynamic IPs. In such cases, disabling UseDNS on the server is the most sensible approach.

5. Check Firewall Rules for DNS

If your dig commands from Step 1 were consistently failing or timing out, a firewall might be blocking outbound DNS queries.

  1. Check UFW (Uncomplicated Firewall):

    sudo ufw status verbose
    

    Look for rules that might deny outbound UDP traffic on port 53. By default, UFW allows all outbound traffic.

  2. Check IPTables (if UFW is not used or custom rules exist):

    sudo iptables -vnL
    

    Review the OUTPUT chain for any restrictive rules. Ensure there isn't a rule blocking UDP traffic on port 53 to destination 0.0.0.0/0 (anywhere).

If you identify a blocking rule and need UseDNS yes for a specific reason, you'll need to open UDP port 53 outbound. Example for UFW (if outbound is restricted):

sudo ufw allow out 53/udp comment 'Allow outbound DNS queries'
sudo ufw reload

By systematically working through these steps, you should successfully eliminate the SSH login delay caused by DNS reverse lookup issues on your Ubuntu 20.04 LTS server.

👨‍💻

Johnathon Wheeler

Senior Systems Architect & DevOps Engineer • Austin, TX

Connect on LinkedIn →

Johnathon has over 16 years of hands-on experience designing, debugging, and scaling Linux web hosting stacks, container clusters, and high-availability database architectures. Every guide on ButItWorkedLocal is independently tested against Debian 12, Ubuntu 24.04/22.04 LTS, Rocky Linux, and Docker environments to guarantee reproducibility in production.

🛡️

Our Production Verification Guarantee

Encountering a bug not covered here or running a non-standard kernel configuration? Our solutions are continually refined against real production incidents. Submit an environment trace for our editorial team to replicate.