LinuxでSSH接続が遅い時の調査手順｜UseDNS・GSSAPIAuthenticationを切り分けてControlMasterで高速化する方法

この記事のポイント

・SSH接続遅延の原因はUseDNS・GSSAPIAuthentication・ネットワーク経路の3パターン
・ssh -vの出力からどのフェーズで止まっているかを正確に特定できる
・UseDNS no / GSSAPIAuthentication noの2行で大多数の遅延が解消する
・繰り返し接続が多い運用ではControlMasterのセッション多重化が効果大

# クライアントPCから実行する（-vはデバッグ出力を有効化）
$ ssh -v user@192.0.2.10

# さらに詳細が欲しい場合は -vv または -vvv を使う
$ ssh -vv user@192.0.2.10

debug1: Connecting to 192.0.2.10 [192.0.2.10] port 22.
debug1: Connection established.
# ← ここで約8秒間フリーズ（UseDNSが原因）
debug1: Authenticating to 192.0.2.10:22 as 'taro'
debug1: Next authentication method: gssapi-keyex
debug1: Next authentication method: gssapi-with-mic
# ← ここでさらに3秒待つ（GSSAPIが原因）
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Next authentication method: publickey
debug1: Offering public key: /home/taro/.ssh/id_ed25519 ED25519
debug1: Server accepts key: /home/taro/.ssh/id_ed25519 ED25519
debug1: Authentication succeeded (publickey).

# サーバー側で確認（journaldを使用）
$ sudo journalctl -u sshd -f

# 接続時に以下のような逆引きDNS失敗メッセージが出ることがある
Sep 02 12:34:56 server1 sshd[12345]: reverse mapping checking getaddrinfo for
client.example.com [192.0.2.50] failed - POSSIBLE BREAK-IN ATTEMPT!

# サーバー側で作業する
$ sudo vi /etc/ssh/sshd_config

# 以下の行を追加または変更する（コメントアウトされている場合はコメントを外す）
UseDNS no

# 設定構文チェック（先にやっておくと安心）
$ sudo sshd -t
# エラーが出なければ OK

# sshdの設定をリロード（既存セッションは切れない）
$ sudo systemctl reload sshd

# 設定が反映されているか確認
$ sudo sshd -T | grep usedns
usedns no

# GSSAPIAuthenticationを無効化して接続（速くなれば原因確定）
$ ssh -o GSSAPIAuthentication=no user@192.0.2.10

# 速くなった場合は ~/.ssh/config に永続化する
$ vi ~/.ssh/config

# ~/.ssh/config の記述例
Host *
    GSSAPIAuthentication no

# 特定のサーバーだけに適用する場合
Host 192.0.2.10
    GSSAPIAuthentication no

$ sudo vi /etc/ssh/sshd_config

# 以下を追加または変更
GSSAPIAuthentication no
GSSAPICleanupCredentials no

$ sudo sshd -t && sudo systemctl reload sshd

# 確認
$ sudo sshd -T | grep -i gssapi
gssapiauthentication no
gssapicleanupcredentials no

$ vi ~/.ssh/config

Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 60s

# ソケット保存用ディレクトリを作成（パーミッションは700が必須）
$ mkdir -p ~/.ssh/sockets
$ chmod 700 ~/.ssh/sockets

# 通常通り接続するとマスターセッションが確立される
$ ssh user@192.0.2.10
Last login: Mon Sep  2 12:30:00 2026 from 192.168.1.50

# 別ターミナルから再接続してみる（-v で動作確認）
$ ssh -v user@192.0.2.10
debug1: auto-mux: Trying existing master
# → 認証フェーズをスキップしてすぐに接続される

# マスターセッションの状態確認
$ ssh -O check user@192.0.2.10
Master running (pid=23456)

# マスターセッションを明示的に停止する
$ ssh -O stop user@192.0.2.10
Stop sent to master.

$ ping -c 4 192.0.2.10
PING 192.0.2.10 (192.0.2.10) 56(84) bytes of data.
64 bytes from 192.0.2.10: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=64 time=0.389 ms
64 bytes from 192.0.2.10: icmp_seq=3 ttl=64 time=0.401 ms
64 bytes from 192.0.2.10: icmp_seq=4 ttl=64 time=0.395 ms

--- 192.0.2.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 0.389/0.399/0.412/0.009 ms

# TCP Wrappers が有効かどうかを確認（RHEL 9では通常不要）
$ ls /etc/hosts.allow /etc/hosts.deny 2>/dev/null
/etc/hosts.allow  /etc/hosts.deny

# sshdが対象になっているか確認する
$ cat /etc/hosts.allow

# sshdをデバッグモードで別ポートに起動して調査する（本番sshdには影響しない）
$ sudo /usr/sbin/sshd -d -p 2222

# 別ターミナルから接続してサーバー側のログを確認する
$ ssh -p 2222 user@localhost