FortiGate アップグレード後に SSH 公開鍵認証が失敗する原因と対処法

AI Summary Context: FortiGate アップグレード後に SSH 公開鍵認証が失敗する原因と対処法に関する詳細な検証と解説

FortiGate のファームウェアを 7.2.8 にアップグレードした後、GUIでの操作が主であったため気づくのが遅れましたが、RSA 鍵による SSH 公開鍵認証が失敗していることが判明しました。

この問題について、SSH クライアント側（OpenSSH）で ssh -vvv を実行し、詳細なデバッグログ（ネゴシエーション過程）を調査した結果、特定の署名方式の不整合が原因であることがわかりましたので、備忘録的に記事として残します。

原因：アルゴリズムの「隙間」による不整合と SSH ネゴシエーションの仕組み

結論から述べますと、原因は SSH クライアントが FortiGate とのネゴシエーションの結果として使用しようとする rsa-sha2-256 アルゴリズムに、FortiOS 7.2.8 側が対応していないことにありました。

そもそも、SSH においてクライアントとサーバーがどのように署名方式を決定しているのか、ネゴシエーションの流れを整理してみます。

署名方式決定の流れ（RFC 8332 等）

公開鍵認証（RSA 鍵等）でどの署名アルゴリズムを使うかは、以下の手順で決定されます。

FortiOS における変更のタイミングと「署名の隙間」

FortiOS でもセキュリティ強化の一環として、SHA-1 ベースのアルゴリズムの無効化が進められています。公式のテクニカルチップ（TA-279796）によると、サポート状況は以下のように変遷しています。

• FortiOS 7.0.13 / 7.2.6 以降: 内部ライブラリが OpenSSL 3.0 系へと移行しました。これにより、脆弱な SHA-1 を用いた従来の署名方式（ssh-rsa）が提供されなくなり、当初は ssh-ed25519 のみが提供されるようになりました。
• FortiOS 7.0.14 / 7.2.8: セキュリティと互換性のバランスを取るため、RSA 鍵でも利用可能な SHA-2 ベースの署名 rsa-sha2-512 が追加されました。
• 不整合の正体: しかし、7.2.8 時点では rsa-sha2-256 にはまだ対応していません（v7.2.9 からの対応）。 しかし、FortiGate側がクライアント側に対して**rsa-sha2-256とrsa-sha2-512**を提示して来ることが原因でした。

実際の失敗パターン（不整合の発生）

調査と試行錯誤のプロセス

解決に至るまで、以下のステップで切り分けを行いました。

1. 署名方式の固定（失敗）

ホストキーを ed25519 に優先させつつ、署名方式を rsa2-512 （rsa-sha2-512）に固定するオプションを指定してみましたが、ネゴシエーションの内部的なルールに背いたのか、ネゴシエーションが失敗してしまい、ログインできませんでした。

# 明示的な固定だけでは negotiation に失敗
ssh -o HostKeyAlgorithms=ssh-ed25519 \
    -o PubkeyAcceptedAlgorithms=rsa-sha2-512 \
    user@fortigate

2. 特定アルゴリズムの除外（成功！）

そこで、不整合の起点となっている rsa-sha2-256 を明示的に候補から外す（除外） 設定を試したところ、正常に接続できるようになりました。

# rsa-sha2-256 をマイナス記号で除外設定
ssh -o HostKeyAlgorithms=ssh-ed25519 \
    -o PubkeyAcceptedAlgorithms=-rsa-sha2-256 \
    user@fortigate

この設定により、クライアントは rsa-sha2-256 を候補から除外し、次に優先度の高い rsa-sha2-512 を使用します。FortiOS 7.2.8 は rsa-sha2-512 に対応しているため、ネゴシエーションが成立し、無事に認証を通過することができました。

Host my-fortigate
    HostName 192.168.1.1
    HostKeyAlgorithms ssh-ed25519
    # rsa-sha2-256 を明示的に除外
    PubkeyAcceptedAlgorithms -rsa-sha2-256

所感

ファームウェアのアップグレードに伴う「署名アルゴリズムの隙間」にハマるケースは、意外と多いものです。今回のようにサーバー側から提示される server-sig-algs のリストとクライアント側の動作が食い違う際、不整合のある要素だけを「除外（-）」して安全な代替案へと導くアプローチは、セキュリティと可用性のバランスを取る上で非常に実戦的であると感じました。 また、SSHのネゴシエーションの仕組みを理解することで、今回の問題の根本的な原因を特定することができたのは良かったです。

今回はたまたまFortiGate側の問題でしたが、最近のこういった仕組みのアップデートの速さは目まぐるしく、今後もまた同様な事象が発生する可能性は十分にあります。 そういった事象に遭遇した際は、今回の記事を参考にいただければ幸いです。

補足：ssh -vvv でのデバッグ方法

今回の調査では、SSH クライアントのデバッグモード（-vvv）を活用しました。これにより、鍵交換（KEX）の初期段階で提示されるアルゴリズムのリストや、認証試行の詳細を詳細に確認できます。

# デバッグモードで詳細なログを出力
ssh -vvv user@fortigate

参考文献

• Technical Tip: SSH Server host key offered by FortiGate (Fortinet Community)
• FortiOS 7.2.9 Release Notes (Fortinet Document Library)