OpenSSH 10.4 は 2026 年 7 月 6 日、10.5 は 2026 年 8 月 11 日にリリースされました。どちらもディストリビューションの更新を通じてすでにサーバーへ届き始めており、その中には開発元自身が「互換性に影響しうる」と明示した変更が 3 つあります。アップグレード前に目を通す価値があります。sshd が壊れたときの代償は、直すために入ることができないことだからです。

10.4 の互換性に影響しうる 3 つの変更

  • 設定ダンプが大文字小文字混在の指令名になった。sshd -T や ssh -G の出力は全小文字ではなく PubkeyAuthentication の形になります。sshd -T | grep pubkeyauthentication で設定を検査しているスクリプトは静かに一致しなくなります。エラーは出ず、ただ永遠に一致せず、その結果コンプライアンス確認や自動化が誤った結論に達します。grep -i にすれば解決します。
  • Linux では seccomp サンドボックスの初期化失敗が「続行可」から「致命的」に変わった。従来 sshd はサンドボックスが使えないと機能を落として動き続けましたが、いまは停止します。古いカーネル、制限付きコンテナ、一部の仮想化基盤では、アップグレード後に sshd が起動しない可能性があります。方向性は正しい（黙って無効化されたサンドボックスは、前提が崩れているのと同じ）のですが、事後ではなく事前に知っておく必要があります。
  • トランスポート層が厳格化：認証後の再鍵交換（rekey）中に非 KEX メッセージを受け取ると切断する。行儀のよいクライアントは踏みませんが、古いライブラリや踏み台ツール、長時間の接続では、しばらく動いた後に切断が起きうるということです。アップグレード後に「1〜2 時間で落ちる」症状が出たら、まずここを疑ってください。

10.4 はセキュリティ修正も 3 件含みます。悪意あるサーバーによる sftp のダウンロード先の操作、scp のリモート間転送の制限、そして internal-sftp のコマンドライン引数の切り詰めによりセキュリティオプションが効かなくなる問題です。最後の 1 件は特に重要で、internal-sftp に引数を渡して制限付き SFTP アカウントを構成している場合、適用したつもりの制限が実は効いていなかった可能性があります。

10.5 で変わったこと

10.5 の「互換性に影響しうる」項目はひとつだけです。可搬版 OpenSSH は libcrypto に ECC サポート（NISTP521 曲線を含む）を要求するようになりました。ディストリビューションのパッケージを使う分には影響しませんが、機能を削った OpenSSL に対してビルドしている場合、ビルドがその場で失敗します。

新機能で最も実用的なのは ssh -Z——公開鍵認証で試された鍵を、試行順に表示します。これは最も一般的な Permission denied (publickey) に直接効きます。手元の鍵が多すぎ、ssh-agent に 7 つも 8 つも載っていて、正しい鍵の番が来る前にサーバー側の MaxAuthTries（既定値 6）を使い切ってしまう、というやつです。以前は ssh -vvv の出力から順序を数えるしかありませんでしたが、いまはフラグひとつで見えます。

10.5 のその他：ssh-keygen で FIDO 秘密鍵の touch-required / verify-required フラグを設定・解除できるようになり、証明書認証では摩擦の少ない FIDO 鍵を優先して試すようになり、sshd は setproctitle(3) で認証後の監視プロセスを sshd-session と表示するため、プロセス一覧が読みやすくなりました。

sshd を更新するときの作法（バージョン番号より重要）

  • 確立済みのセッションを必ず 1 つ開けたままにする。更新して sshd を再起動したら、まったく新しいウィンドウで接続し直し、入れることを確認してから元のセッションを閉じます。既存接続は sshd の再起動を生き延びます。それが命綱です。
  • 再起動前に構文検査：sudo sshd -t。実効設定を読むなら sudo sshd -T（上記の大文字小文字変更に注意）。
  • コンテナや古いカーネルでは、先に seccomp が利用可能か確認してください。さもないと上記の致命化変更に直撃します。
  • 帯域外の経路をあらかじめ用意する。事業者の VNC やシリアルコンソール、レスキューモードは、障害の最中に学ぶものではなく、すでに一度使ったことがあるものにしておきます。

本当に締め出されたら

まずネットワーク層の問題か SSH サービス自体の問題かを切り分けてください。両者は進む方向がまったく違います。VPS に SSH で入れないときの段階的チェックリストは、ローカルネットワーク、ファイアウォール、ポート、サービス状態という順序を示します。SSH がタイムアウトして接続できないときはタイムアウト型の症状に絞った内容です。予防側——鍵認証、ufw のルール、ポート変更に意味があるか——はVPS のセキュリティ強化：ufw ファイアウォールと SSH 鍵ログインにあります。SharkCloud の各インスタンスはコンソールから到達できるため、sshd が完全に死んでも OS の再インストールは必要ありません。