OpenSSH 10.6の欠陥、Ubuntuは版そのままで9件を修正

やること

Ubuntu のサーバーでは apt で OpenSSH を更新してください。USN-8928-1（10月14日）が 26.04 LTS、24.04 LTS、22.04 LTS の修正です。

Ubuntu は OpenSSH 10.6 へは上げず、今のバージョンに修正だけを取り込みます。これをバックポートといいます。たとえば 24.04 LTS は 9.6p1 のままで、古い番号に見えても修正済みのことがあります。バージョン番号だけでは判断できないので、パッケージのバージョンが 1:9.6p1-3ubuntu13.20 以降かを見てください。同じ仕組みの例は Apache httpdに20件の脆弱性、最大CVSS 9.8で更新を にもあります。

Ubuntu 以外で公式の配布物を使う場合は、10.6 / 10.6p1 以降へ更新してください。公式にはその後、11月5日に 10.6p2 も出ています。

USN-8928-1 のページには、再起動についての記載がありません。通常のシステム更新で必要な変更は入る、と書かれています。9月3日の USN-8721-1 には OpenSSH の再起動が必要と書かれているので、設定の反映を確実にしたい場合は、保守の時間に sshd を再起動してください。ただし、遠隔から作業している場合は、再起動の前に別の接続を1本つないで確かめます。

何が危ないのか

OpenSSH は10月6日に 10.6 を公開しました。Ubuntu の通知は9件の CVE を挙げており、主なものは次のとおりです。

• CVE-2026-106585：圧縮されたデータを展開するときに最大の長さを確かめておらず、遠隔からサービスを妨害されるおそれがあります。CVSS は 6.5 で、Ubuntu のページで確かめた3件のうち最も高い値です。認証は要らず、ネットワークから届く評価です
• CVE-2026-106552：sftp の再帰コピーで、悪質なサーバーに意図しない場所へファイルを書かれるおそれがあります。CVSS は 4.2 で、利用者の操作が前提の評価です
• CVE-2026-106582：圧縮の仕組みから、情報が漏れるおそれがあります。CVSS は 3.7 です
• CVE-2026-106553：GSSAPI 認証で、失敗した試行の資格情報が残ることがあります

残りの5件は、次のとおりです。

• CVE-2026-106583：ssh のコマンドラインのユーザー名に特殊な文字を入れて、任意のコマンドを実行させられるおそれがあります
• CVE-2026-106584：ssh-keygen が日付を変換するときの夏時間の扱いが誤り、証明書の有効期限がずれるおそれがあります
• CVE-2026-106586：sshd が authorized_keys の restrict をトンネル転送に適用せず、許可された鍵を持つ人が制限を回避できます
• CVE-2026-106587：「none」を受け付ける設定項目の扱いが誤っています
• CVE-2026-106555：106553 と同じく、sshd が認証の試行のあいだで GSSAPI の状態を取り違えます

悪用の確認は公表されていません。

圧縮の変更

10.6 は、圧縮の仕組みから平文が推測されるおそれへの対策として、圧縮の辞書の使い方を止めました。公式のリリースノートは、この変更で Compression の設定の効果が下がることを書いています。通信量を減らすために Compression yes を使っている場合は、転送が遅くなったり量が増えたりすることがあります。

また、ssh のコマンドラインのユーザー名に $ と \ が使えなくなりました。ProxyCommand などに、ユーザー名を渡すスクリプトを組んでいる場合は、動かなくなることがあるので試験してください。設定ファイルの User は対象外です。

対象

Ubuntu では 26.04 LTS、24.04 LTS、22.04 LTS に修正が出ました。26.10 は USN-8937-1 です。20.04 LTS 以前は Ubuntu のページで「確認中」です。

CVE-2026-106552 などは sftp のクライアント側の欠陥で、接続先のサーバーが悪質な場合に当たります。接続先を自社や取引先の管理下のサーバーだけにしている場合は、当たる条件が狭くなります。

11月5日に伝えたパスワード回避の欠陥は別のものです。musl を使う環境が対象で、Ubuntu は対象外です。

中小企業が学べること

踏み台のサーバーや保守用の接続で、sftp や scp を使うときは、接続先を決めておきます。今回の sftp の欠陥は、悪質なサーバーへつないだときに当たるので、知らないサーバーへ手元の端末からつながないだけで、当たる条件を避けられます。

authorized_keys に restrict を付けて鍵ごとの許可を絞っている場合は、更新のあとに転送の動作が変わっていないかを確かめます。必要な機能は、restrict のあとに個別に足す形にしておくと、何を許可しているかが一目で分かります。