問題の概要古いCisco CatalystスイッチやレガシーなCentOS 6サーバーを管理しようとしているのに、最新のUbuntu 24.04を搭載したノートPCから接続できないことがあります。接続は即座に切断され、パスワード入力プロンプトの代わりに次のエラーが表示されます。
$ ssh root@192.168.1.10
Unable to negotiate with 192.168.1.10 port 22: no matching host key type found. Their offer: ssh-rsa
原因これはバグではなく、意図的なセキュリティ対策です。2021年9月にリリースされたOpenSSH 8.8以降、ssh-rsa署名アルゴリズムはデフォルトで無効化されました。
問題はSHA-1ハッシュ関数にあります。セキュリティ研究者により、SHA-1は「選択プレフィックス攻撃（chosen-prefix attacks）」に対して脆弱であることが証明されています。2020年時点で、このような攻撃の実行コストは約5万米ドルと推定されており、多くの悪意ある攻撃者にとって十分に可能な範囲です。最新のSSHクライアントはSHA-1を「壊れている」と見なすため、サーバー側からの利用提案を拒否します。あなたは、最新のセキュリティ標準と老朽化したインフラの板挟みになっている状態です。
解決策1：クイックフィックス（コマンドライン）設定ファイルを更新するために一度だけサーバーにログインする必要がある場合は、グローバル設定を変更しないでください。-oフラグを使用することで、そのセッションのみ古いアルゴリズムを許可するようにSSHに指示できます。
ssh -o HostKeyAlgorithms=+ssh-rsa root@192.168.1.10
SSHキーを使用してログインしており、それも失敗する場合は、公開鍵に対してもRSAを再有効化する必要があります。
ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa root@192.168.1.10
解決策2：「一度設定すればOK」の修正（推奨）毎回長いフラグを入力するのは面倒です。より良い方法は、ローカル設定ファイルでその特定のサーバーに対する例外を作成することです。これにより、他のすべての接続のセキュリティを維持しつつ、レガシー機器へシームレスにアクセスできるようになります。
- ユーザーレベルのSSH設定ファイルを開きます：
nano ~/.ssh/config- 特定のデバイスのIPまたはホスト名に対して以下の行を追加します：Host 192.168.1.10 HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa- 保存して終了します。SSHがファイルを無視しないよう、正しいパーミッション（権限）が設定されていることを確認してください：``` chmod 600 ~/.ssh/config
これで、余計なフラグを付けずに `ssh root@192.168.1.10` と入力するだけで接続できるようになります。
## 解決策3：最終手段（グローバル設定）何百台ものレガシーマシンがあるラボで作業している場合、これをグローバルに有効化したくなるかもしれません。**注意してください：これを行うと、開始するすべてのSSH接続のセキュリティがわずかに低下します。**
sudoを使用して `/etc/ssh/ssh_config` を編集し、ファイルの末尾に以下の行を追加します：
HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
## 接続の確認修正が意図通りに機能しているか確認するには、詳細モード（verbose mode）でSSHを実行します。出力をフィルタリングして、どのアルゴリズムがネゴシエートされたかを正確に確認できます。
ssh -v root@192.168.1.10 2>&1 | grep -i "host key"
成功を確認するために、次のような行を探してください：
debug1: kex: host key algorithm: ssh-rsa
## 長期的な解決策セキュリティチェックの回避は一時しのぎに過ぎません。リモートサーバーへの管理者権限がある場合は、ホストキーを**Ed25519**のような現代的なものにアップグレードすべきです。これはRSAよりも高速で、大幅に安全です。
リモートサーバーで以下を実行し、新しいホストキーを生成します：
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key < /dev/null
その後、サーバーの `/etc/ssh/sshd_config` に `HostKey /etc/ssh/ssh_host_ed25519_key` を追加し、SSHサービスを再起動します。これで、最新のクライアントからワークアラウンドなしで接続できるようになります。