VPSのSSH接続が遅い原因と対処｜ログインまで待たされる・入力が重い場合

VPS に SSH でつなぐと、パスワードやパスフレーズを聞かれるまで何十秒も待たされる、ログインした後のキー入力がもたつく、といった症状が出ることがあります。原因は大きく2つに分かれます。

• ログインまでが遅い: 接続を始めてからプロンプトが出るまでに時間がかかる。認証方式の試行、名前の逆引き、IPv6 の失敗など、接続の手続きのどこかで待っていることが多い
• ログイン後の操作が重い: 1文字打つたびに遅れる、コマンドの結果がなかなか出ない。回線の遅延や損失、サーバーの負荷が主な原因

この記事のコマンドは、Ubuntu 24.04 と Rocky Linux 9（RHEL 9 系）の OpenSSH で確かめたものです（2026年11月時点）。

まず遅い場所を確かめる

ログインまでが遅い場合は、手元のパソコンから -vvv（詳細な記録の表示）を付けて接続し、どの行の後で止まるかを見ます。user と 203.0.113.10 は自分の環境に置き換えます。

ssh -vvv user@203.0.113.10

止まる場所と、疑う原因の対応です。

かかった時間は、time を付けて測れます（鍵認証で、コマンドを1つ実行してすぐ終わる例）。

time ssh user@203.0.113.10 true

GSSAPI 認証を止める

GSSAPI は Kerberos を使う社内向けの認証方式です。普通の VPS では使いませんが、クライアントが試行すると、その分待たされることがあります。Ubuntu・Debian の /etc/ssh/ssh_config と、RHEL 系の /etc/ssh/ssh_config.d/50-redhat.conf には、クライアント側で GSSAPIAuthentication yes が設定されています。

手元の ~/.ssh/config に次を書くと、クライアント側で試行しなくなります。

Host myvps
    HostName 203.0.113.10
    User user
    GSSAPIAuthentication no

以後は ssh myvps で接続します。一度だけ試すなら ssh -o GSSAPIAuthentication=no user@203.0.113.10 でも同じです。

サーバー側でも止める場合、Rocky Linux 9 などの RHEL 系では /etc/ssh/sshd_config.d/50-redhat.conf で GSSAPIAuthentication yes になっています（Ubuntu 24.04 の sshd は既定で no）。sshd の設定は最初に読んだ値が使われ、sshd_config.d のファイルは名前の順に読まれるので、50 より前の名前でファイルを作ります。

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

サーバー側の逆引き（UseDNS）を確かめる

UseDNS yes のとき、sshd は接続元の IP アドレスからホスト名を逆引きします。サーバーの DNS の設定が壊れていると、この問い合わせが時間切れになるまで待たされます。現行の OpenSSH の既定は no ですが、古い設定ファイルを引き継いでいると yes のことがあります。サーバーで実際の値を確かめます。

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

usedns yes と出たら、/etc/ssh/sshd_config か /etc/ssh/sshd_config.d/ の中の UseDNS yes を UseDNS no に直します。あわせて、サーバー自身の名前解決が動くかも確かめます。

getent hosts wordpress.org

ここで結果がすぐ返らない場合は、/etc/resolv.conf（systemd-resolved を使う環境では resolvectl status）の DNS サーバーの指定を見直します。

IPv6 で待たされる

接続先をホスト名で指定していて、そのホスト名に IPv6 アドレス（AAAA レコード）があると、ssh は IPv6 で先に接続を試みます。手元の回線や VPS 側で IPv6 が通らないと、時間切れの後で IPv4 に切り替わるため、その分遅くなります。

# IPv4 だけで接続して比べる
ssh -4 user@example.com

-4 で速くなるなら、~/.ssh/config の該当ホストに AddressFamily inet を書きます。根本的には、VPS の IPv6 設定（アドレスやファイアウォール）を見直すか、使わない IPv6 アドレスを DNS から外します。

サーバー側の変更を反映する

sshd の設定を変えたら、構文を確かめてから再起動します。今つないでいる SSH の画面は閉じずに、別の画面から新しく接続できることを確かめてください。設定を誤るとログインできなくなるため、VPS の管理画面のコンソールが使えることも事前に確かめておきます。

# 構文チェック（何も出なければ問題なし）
sudo sshd -t

# Ubuntu・Debian
sudo systemctl restart ssh

# RHEL・Rocky Linux・AlmaLinux
sudo systemctl restart sshd

ログイン後の処理で待たされる

-vvv の表示で Authenticated to ... まで速く進み、その後プロンプトが出るまでが遅い場合は、ログインのときに動く処理を疑います。

• 自分の ~/.bashrc や ~/.bash_profile に、時間のかかるコマンド（ネットワークにつなぐもの、大きなファイルを調べるもの）が書かれていないか
• Ubuntu では、ログイン時のメッセージを作るスクリプトが /etc/update-motd.d/ にあり、ログインのたびに実行されます。後から追加したスクリプトが無いか確かめます

time ssh user@203.0.113.10 true が速く、普通にログインしたときだけ遅いなら、こうした対話ログイン時の処理が原因です。

ログイン後の入力が重い場合

回線の遅延と損失

# 往復時間を見る
ping -c 10 203.0.113.10

# 経路のどこで損失が出ているかを見る（mtr パッケージが必要）
mtr -rwc 100 203.0.113.10

往復時間が大きい（数百ミリ秒）か、損失（Loss%）が出ている場合は回線側の問題です。手元の回線（Wi-Fi など）を変えて比べ、VPS 側の経路で損失が続くなら、VPS 事業者に mtr の結果を添えて問い合わせます。

サーバーの負荷

uptime          # load average が CPU の数より大きく続いていないか
free -h         # 空きメモリが少なく、Swap が使われていないか
top             # CPU やメモリを多く使っているプロセス
df -h           # ディスクがいっぱいになっていないか

WordPress を動かしている VPS では、PHP-FPM や MySQL・MariaDB がメモリを使い切り、Swap が増えて全体が遅くなることがあります。その場合は原因のプロセスを特定し、設定の見直しやメモリの多いプランへの変更を検討します。

総当たり攻撃による混雑

インターネットに公開している 22 番ポートには、パスワードを試す接続が絶えず届きます。sshd は、認証が終わっていない接続が多いと、新しい接続を一部断る仕組み（MaxStartups、既定は 10:30:100）を持っているため、攻撃が多いと自分の接続も断られたり遅れたりします。ログで状況を確かめます。

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

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

件数が多い場合は、ファイアウォールで 22 番ポートに接続できる IP アドレスを絞るのが効果的です。Ubuntu のファイアウォールは「Ubuntu の ufw でファイアウォールを設定する」を参照してください。パスワード認証をやめて鍵認証だけにする手順は「SSH の公開鍵認証を設定する」で説明しています。

何度もつなぐ場合は接続を使い回す

Linux や macOS の OpenSSH クライアントでは、一度つないだ接続を使い回して、2回目以降の接続の手続きを省けます（Windows の OpenSSH ではこの機能は使えません）。~/.ssh/config に次を書きます。

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

最初の接続が終わってから10分間は、同じホストへの ssh や scp がその接続を使うため、すぐにつながります。

まとめ

• まず ssh -vvv で、ログインまでのどこで止まるかを見る
• gssapi-with-mic の後で止まるなら GSSAPIAuthentication no、IPv6 の接続で止まるなら -4 か AddressFamily inet
• サーバー側は sudo sshd -T で UseDNS などの実際の値を確かめ、変更後は sudo sshd -t で構文を確認してから再起動する
• ログイン後の入力が重いなら、ping・mtr で回線を、uptime・free -h・top でサーバーの負荷を、ログで総当たり攻撃の量を確かめる

接続が一定時間で切れてしまう場合は「SSH 接続がタイムアウトで切れるときの設定」を参照してください。