Slow SSH Connection to a VPS: Fixing Slow Logins and Laggy Typing

This article is a localized edition of the Japanese original. Read the Japanese original

When you connect to a VPS over SSH, you may wait tens of seconds before being asked for a password or passphrase, or keystrokes may lag after you log in. The causes fall into two broad groups.

• Logging in is slow: It takes a long time from starting the connection until the prompt appears. Usually something in the connection handshake is waiting, such as an authentication method being tried, a reverse name lookup, or a failed IPv6 attempt
• Working after login is sluggish: Every character you type lags, or command output is slow to appear. The main causes are network latency or packet loss and server load

The commands in this article were checked with OpenSSH on Ubuntu 24.04 and Rocky Linux 9 (RHEL 9 family) as of November 2026.

First, find where it slows down

If logging in is slow, connect from your own computer with -vvv (verbose debug output) and see which line it pauses after. Replace user and 203.0.113.10 with your own values.

ssh -vvv user@203.0.113.10

Where it pauses and the likely cause:

You can measure the time with time (an example with key authentication that runs one command and exits immediately):

time ssh user@203.0.113.10 true

Turning off GSSAPI authentication

GSSAPI is an authentication method that uses Kerberos, mostly on corporate networks. An ordinary VPS does not use it, but when the client tries it, you can end up waiting. Client-side GSSAPIAuthentication yes is set in /etc/ssh/ssh_config on Ubuntu and Debian and in /etc/ssh/ssh_config.d/50-redhat.conf on RHEL-based systems.

Add the following to ~/.ssh/config on your computer so the client stops trying it:

Host myvps
    HostName 203.0.113.10
    User user
    GSSAPIAuthentication no

From then on, connect with ssh myvps. To try it once, ssh -o GSSAPIAuthentication=no user@203.0.113.10 does the same thing.

To turn it off on the server as well: on RHEL-based systems such as Rocky Linux 9, /etc/ssh/sshd_config.d/50-redhat.conf sets GSSAPIAuthentication yes (sshd on Ubuntu 24.04 defaults to no). In sshd configuration the first value read wins, and files in sshd_config.d are read in name order, so create a file whose name sorts before 50.

echo 'GSSAPIAuthentication no' | sudo tee /etc/ssh/sshd_config.d/10-local.conf

Checking the server-side reverse lookup (UseDNS)

With UseDNS yes, sshd looks up the host name for the client's IP address. If the server's DNS settings are broken, you wait until that lookup times out. Current OpenSSH defaults to no, but it may be yes if an old configuration file was carried over. Check the actual value on the server:

sudo sshd -T | grep -iE 'usedns|gssapiauthentication'

If it shows usedns yes, change UseDNS yes to UseDNS no in /etc/ssh/sshd_config or in /etc/ssh/sshd_config.d/. Also check that name resolution works on the server itself:

getent hosts wordpress.org

If this does not return right away, review the DNS servers in /etc/resolv.conf (or resolvectl status on systems that use systemd-resolved).

Waiting on IPv6

If you connect by host name and that name has an IPv6 address (AAAA record), ssh tries IPv6 first. If IPv6 does not work on your network or on the VPS side, it falls back to IPv4 only after a timeout, which slows things down.

# Compare by connecting over IPv4 only
ssh -4 user@example.com

If -4 is faster, add AddressFamily inet to that host in ~/.ssh/config. The underlying fix is to review the VPS's IPv6 settings (address and firewall) or to remove IPv6 addresses you do not use from DNS.

Applying server-side changes

After changing sshd settings, check the syntax and then restart. Keep your current SSH session open, and confirm from another window that you can make a new connection. A mistake in the settings can lock you out, so also confirm beforehand that the console in your VPS control panel works.

# Syntax check (no output means no problems)
sudo sshd -t

# Ubuntu / Debian
sudo systemctl restart ssh

# RHEL / Rocky Linux / AlmaLinux
sudo systemctl restart sshd

Waiting on processing after login

If -vvv reaches Authenticated to ... quickly but the prompt is slow to appear afterward, suspect the processing that runs when you log in.

• Check whether your ~/.bashrc or ~/.bash_profile contains slow commands (ones that make network connections or scan large files)
• On Ubuntu, the scripts that build the login message live in /etc/update-motd.d/ and run at every login. Check whether any scripts were added later

If time ssh user@203.0.113.10 true is fast and only a normal login is slow, this kind of interactive-login processing is the cause.

If typing is sluggish after login

Network latency and packet loss

# Check round-trip time
ping -c 10 203.0.113.10

# See where along the route packets are lost (requires the mtr package)
mtr -rwc 100 203.0.113.10

If the round-trip time is large (hundreds of milliseconds) or there is loss (Loss%), the problem is on the network side. Compare using a different local connection (such as another Wi-Fi network), and if loss persists on the VPS side of the route, contact your VPS provider with the mtr results.

Server load

uptime          # is the load average staying above the number of CPUs?
free -h         # is free memory low and is swap in use?
top             # processes using a lot of CPU or memory
df -h           # is the disk full?

On a VPS running WordPress, PHP-FPM or MySQL/MariaDB can use up memory, swap grows, and everything slows down. In that case, identify the process responsible and consider revising its settings or moving to a plan with more memory.

Congestion from brute-force attacks

Port 22 exposed to the internet receives a constant stream of password-guessing connections. sshd has a mechanism (MaxStartups, default 10:30:100) that refuses some new connections when there are many unauthenticated ones, so heavy attack traffic can cause your own connections to be refused or delayed. Check the logs:

# Ubuntu / Debian
sudo journalctl -u ssh --since "1 hour ago" | grep -c "Failed\|Invalid user"

# RHEL-based
sudo journalctl -u sshd --since "1 hour ago" | grep -c "Failed\|Invalid user"

If the count is high, restricting which IP addresses can reach port 22 with a firewall is effective. For a firewall on Ubuntu, see "Setting up a firewall with ufw on Ubuntu". Switching from password authentication to key authentication only is covered in "Setting up SSH public key authentication".

Reusing the connection when you connect often

The OpenSSH client on Linux and macOS can reuse an existing connection and skip the handshake for the second and later connections (this feature is not available in OpenSSH on Windows). Add the following to ~/.ssh/config:

Host myvps
    HostName 203.0.113.10
    User user
    ControlMaster auto
    ControlPath ~/.ssh/cm-%C
    ControlPersist 10m

For 10 minutes after the first connection ends, ssh and scp to the same host reuse that connection and connect immediately.

Summary

• First use ssh -vvv to see where the login stalls
• If it stops after gssapi-with-mic, use GSSAPIAuthentication no; if it stops on an IPv6 connection, use -4 or AddressFamily inet
• On the server, check actual values such as UseDNS with sudo sshd -T, and after changes, confirm the syntax with sudo sshd -t before restarting
• If typing lags after login, check the network with ping and mtr, server load with uptime, free -h and top, and the volume of brute-force attempts in the logs

If your connection drops after a period of time, see "Settings for SSH connections that time out".

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)