「OpenSSHの脆弱性」「SSH鍵を確認」と聞いても、Webサイトの管理画面で何をすればよいのか迷うかもしれません。SSHは、技術担当者が離れた場所からサーバーに接続し、設定やプログラムを管理するときに使う仕組みです。
事業担当者が押さえたいのは、サイトを閲覧・編集する入口と、サーバーそのものを管理する入口は別にあるという点です。SSHの役割を知っておくと、開発会社や保守会社に何を確認すればよいかが分かりやすくなります。
SSHは、離れたサーバーを操作するための通信の仕組み
SSHはSecure Shellの略で、ネットワーク越しに接続し、暗号化した通信で遠隔操作するための仕組みです。例えば技術担当者は、サーバーの設定を変える、プログラムを配置する、動作を調べるといった保守作業に利用します。OpenSSHの公式説明、SSHクライアントの説明
OpenSSHは、このSSHの機能を実現する代表的なソフトウェアです。接続する側のプログラム「ssh」と、サーバー側で接続を受け付ける「sshd」などが含まれます。ニュースでどちらの問題なのかを確かめることが、対象を絞る第一歩です。OpenSSHの構成
SSHにはファイル転送などの用途もあります。SFTPという転送方法もSSHを利用するため、保守会社に確認するときは、手作業のサーバー操作だけでなく、ファイルの受け渡しや自動処理でも使っていないかを聞くとよいでしょう。OpenSSHの関連ツール
Webの管理画面と、サーバー管理の入口は別
サイト運営で使う入口は、大きく分けて次のように整理できます。
- Webサイトの閲覧：利用者がブラウザーでページを見る入口。
- サイトの管理画面：担当者が記事や商品を編集する入口。
- サーバーの管理：技術担当者がSSHなどで接続し、ソフトウェアや設定を扱う入口。
同じサーバーで提供されることもありますが、認証や更新の担当範囲は同じとは限りません。サイトの管理画面でパスワードを変えても、SSH用の認証情報やOpenSSH本体が更新されるとは限らない、ということです。
サービス提供会社がサーバー管理を引き受ける契約もあれば、自社や外注先が管理する契約もあります。最初に確認したいのは製品名を暗記することより、「この入口は誰が管理し、誰が更新するのか」です。
SSH鍵は、サーバーに本人だと確かめてもらうためのもの
SSHには複数の認証方法があります。パスワード認証は、入力したパスワードをサーバー側で確かめる方法です。公開鍵認証は、組になる「公開鍵」と「秘密鍵」を使い、秘密鍵を持っていることを証明する方法です。OpenSSHの認証の説明
一般的な公開鍵認証では、サーバーに公開鍵を登録し、接続する担当者が秘密鍵を管理します。秘密鍵そのものを相手に渡して本人確認する仕組みではありません。秘密鍵は、メールや共有チャットに貼り付けず、管理方法と利用できる人を決めておく必要があります。
担当者の退職や外注先の変更時には、その人のアクセスをどう止めるかも確認します。個人ごとに権限と鍵を把握できれば、関係のない担当者の作業を止めずに、不要なアクセスを外しやすくなります。
「鍵で使う」と「パスワードを受け付けない」は別
自分たちが毎回SSH鍵で接続していても、サーバーが別の接続にパスワード認証を許している場合があります。公開鍵認証を許可する設定と、パスワード認証を許可する設定は別々に存在します。OpenSSHのパスワード認証設定、公開鍵認証設定
そのため、「鍵を使っているので大丈夫です」という説明を受けたら、必要に応じて「サーバー側で許可している認証方法も確認しましたか」と聞くと具体的になります。接続するユーザーや接続元によって設定が変わる仕組みもあるため、一部の担当者の使い方だけでは判断できません。条件別の設定
なお、認証設定を不用意に変更すると、正規の担当者も接続できなくなるおそれがあります。変更は技術担当者が復旧手段を用意し、設定の検証、サービスへの反映、新しい接続のテストまで行うことが大切です。
「管理者権限」は、ログインできることとは別に確認する
サーバーにログインできるアカウントでも、操作できる範囲は一律ではありません。特定のファイルだけを扱う人もいれば、サーバー全体を管理できる人もいます。Linuxなどでrootと呼ばれるアカウントは、特に強い権限を持ちます。
SSHにはrootでの接続を制限する設定もあります。ただし、一般のアカウントで接続してから管理者権限に切り替えられる構成もあるため、「rootでは直接入れません」という説明だけで、できる操作の範囲を判断しないことが大切です。OpenSSHのrootログイン設定
外注先には、使うアカウント、操作できる対象、管理者権限が必要な場面、不要になったアクセスを止める方法を確認しておきましょう。
脆弱性の連絡が来たら、確認と完了報告を分ける
SSH関連のニュースが出たときは、次の順に担当者へ確認すると整理しやすくなります。
- 利用の有無：本番、開発・検証、踏み台など、どこで該当ソフトウェアが動いているか。
- 対象条件：バージョンだけでなく、OSや認証設定など、今回の脆弱性が成立する条件に当たるか。
- 対応する人と時期：誰が更新・設定変更を担当し、業務への影響をどう確認するか。
- 反映の確認：修正済みのプログラムが実際に動いているか。必要な再起動や、正規の担当者による再接続を確認したか。
- 記録の確認：不審な接続や、想定しない権限・登録鍵の変更がないか。
例えば、2026年11月のAlpine LinuxのOpenSSH認証回避問題では、パッケージ更新後のsshd再起動が明示されています。「修正版をインストールした」と「実際の接続を受けるプログラムが修正済みになった」を分けて確認する必要がある例です。Alpineの修正リリース案内
事業担当者がサーバーの設定を直接変更する必要はありません。日頃から管理者、接続する人、更新の担当、作業後の確認方法を整理しておけば、脆弱性の連絡が来たときに、必要な人へ具体的に依頼できます。
情報確認日：2026年11月7日。認証や更新の手順は構成によって異なるため、利用する製品・サービスの公式案内と保守担当者の説明を確認してください。