Ubuntu VPSにSSH接続できない原因を切り分ける

失敗を1回記録し、使える接続を残す

成功しているSSH接続を閉じず、提供元の復旧コンソールを確認します。クライアントのコマンドは手元のLinux、macOS、WSL、サーバーのコマンドは現在の接続か認証済みコンソールで実行します。

文書用IPの203.0.113.10、ubuntu、22番、鍵ファイルを実際の設定に変更します。まず有効なクライアント設定を表示し、新しい接続を1回試します。

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

hostname、user、port、identityfile、プロキシを確認します。2つ目のコマンドは接続共有を無効にします。時刻と最後のエラーを記録し、新しいホスト鍵は後述の方法で確認してください。デバッグ出力の共有前にユーザー名、IP、パスを伏せ、秘密鍵は共有しません。

メッセージから確認する場所を選ぶ

表を横にスクロールすると、残りの項目を確認できます。

原因を一つに断定する情報ではありません。Connection establishedの後にタイムアウトするなら、全パケットが遮断されたと考えず、SSHのハンドシェイクとサーバーログを調べます。

タイムアウトなら経路をたどる

ssh -vの宛先と現在の管理画面を比べます。ホスト名の場合は古いDNSや異なるIPv6を疑い、公開IP、VPN、踏み台のどれが必要かを確認します。

VMの起動、公開経路、実際のSSHポート、現在の接続元公開IPを調べます。回線のIPが変わっても/32許可が古いままの場合があります。ゲストの通信設定もコンソールから確認します。

Oracleではリスト、NSG、経路、ゲストの全てが関係します。診断のためにUFWを入れたりiptablesを消したりせず、Oracleのネットワーク構成を確認します。ping失敗だけではSSH不可と断定できません。

接続拒否なら待受を調べる

拒否応答があっても正しいVPSだと認証されたわけではありません。宛先とポートを確認し、サーバーの既存接続かコンソールで読み取り用の確認を行います。

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

目的のポートとアドレスに待受があるか、試行時刻のログを見ます。Ubuntuではソケット起動を使う場合があり、ssh.serviceがinactiveでもssh.socketが待受していることがあります。

sshd -tは設定とホスト鍵の妥当性を確認し、デーモンは起動しません。無出力の成功はネットワーク到達の証明ではありません。エラーなら該当箇所を特定してから再読み込みを検討します。

公開鍵が拒否されたらユーザーと提示鍵を照合する

推測したユーザー名ではなく、提供元の初期ユーザーか自分で作った管理者を使います。クライアントログで提示された指紋を確認し、不要なエージェント鍵を減らすため手元で次を試します。

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

IdentityFile設定はなお適用され得るためssh -Gも確認します。ローカルの秘密鍵が読めない、権限が広すぎるというエラーなら、サーバー変更の前にそのファイルのアクセスを直します。

サーバーでユーザーと認証済み公開鍵を調べます。例の/home/ubuntuはgetentで確認したホームへ変更してください。

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

提示された指紋と登録指紋を比べ、所有者、権限、アカウント方針のログを調べます。AuthorizedKeysFile、Include、Match、提供元の鍵管理も確認します。既存の公開鍵を残し、StrictModes無効化やパスワード有効化で原因を隠さないでください。

ホスト鍵が変わったら接続先を検証する

再構築やIP再割り当てで鍵が変わることはありますが、誤った接続先や傍受の可能性もあります。認証済み管理画面でVM識別子と計画した変更を確認します。

信頼できるゲストコンソールで、クライアントが示した種類のホスト公開鍵を調べます。Ed25519の場合は次です。

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

警告のSHA256と比べます。これはログイン鍵やコンソール・ゲートウェイの鍵ではありません。交換を検証できた場合だけ、保存ファイルをバックアップしてそのホストの項目を更新します。known_hosts全体の削除や確認の無効化はせず、説明できないなら接続を中断して調査します。

特定した修正を新しい接続で確認する

確認したIP、ユーザー、鍵、狭い許可ルール、設定エラーだけを直します。独立したアクセス経路を残し、サーバー変更は設定検証後に適用します。ポート変更ではソケット起動の設定も関係する場合があります。

接続共有を無効にして元の試行を繰り返し、正しいユーザーと必要なsudoを確認します。古い接続の維持だけではテストになりません。原因と変更内容を記録し、初期設定の続きへ戻ります。