最終更新：2026-01-11

注意：生成AIにより記事を生成したため、一部情報に偏りや誤りがある可能性があります。自己責任でお読みください。

前述までの記事では、scpの便利なオプションや実際の運用方法について解説した。

しかし、現代のセキュリティ基準において、scpはその設計思想に起因するいくつかの課題を抱えている。本章では、エンジニアが知っておくべきscpの「歴史的な脆弱性」と、具体的なCVE事例、そしてOpenSSHプロジェクトが推奨する代替手段について解説する。

scp の設計思想とセキュリティリスク#

scpのセキュリティリスクは、単発的なバグというよりも、「信頼モデル（Trust Model）」が現代の要件と合わなくなっている点にある。

1. rsh 時代の設計と思想#

scpは、かつて使われていたrcp（リモートコピー）コマンドの互換ツールとして設計された。通信経路こそSSHで暗号化されているものの、プロトコルの挙動自体は以下のような古い前提（性善説）に基づいている。

• 「接続先のサーバーは常に正しい」
• 「サーバーは要求された通りのファイル名やパスを返す」

つまり、通信は暗号化されているが、データ内容の妥当性検証は弱いという構造的欠陥を持っている。

2. サーバーが「嘘をつける」問題とCVE事例#

scpクライアントは、仕様上、サーバーから送られてくるファイル名やディレクトリ構造をほぼ無条件で信頼してしまう。この設計に起因する代表的な脆弱性として、以下のような事例が存在する。

代表的な脆弱性：CVE-2019-6111#

この脆弱性は、scpの設計上の欠陥を象徴するものである。

• 概要: 悪意あるSSHサーバー（または侵害されたサーバー）が、クライアントの意図しないファイルを上書きできる。
• 仕組み: サーバーが返すファイル名に ../（パストラバーサル）や絶対パスを含めることで、クライアントが指定したディレクトリ外（例: ~/.ssh/authorized_keys や ~/.bashrc）への書き込みを実行させる。
• 根本原因: クライアント側で、サーバーから送られてきたファイル名が、リクエストしたものと一致するか検証していなかったため。

その他の関連脆弱性#

• CVE-2018-20685: サーバー側がディレクトリのパーミッションを不正に変更できる脆弱性。
• CVE-2020-15778: ファイル名処理の不備により、特定条件下でscpが想定外のシェル展開を行い、結果としてローカル側で任意のコマンド実行につながる可能性がある脆弱性。

これらはパッチによって修正されているものも多いが、「サーバーを信頼する」というプロトコルの根幹が変わらない限り、類似の問題が再発するリスクが指摘されている。

現代における推奨解：sftp と rsync#

OpenSSH の公式見解#

開発元のOpenSSHプロジェクトは、scp/rcpプロトコルについて「設計上の制約があり、現代的な安全要件を満たしにくい」として、可能な限り sftp の利用を推奨している。

Note: OpenSSH 8.0以降では、scpコマンドを実行しても、内部的にSFTPプロトコルを使用して転送を行うモード（-sオプション等）が実装されている。さらに一部のディストリビューションでは、デフォルトでSFTPプロトコルを使うように変更されている場合もある。

※ ただし、この挙動はOpenSSH実装およびディストリビューションの設定に依存するため、環境によっては従来のscp/rcpプロトコルが使われる場合もある。

代替手段のメリット#

まとめ：どのように使い分けるべきか#

「scpは危険だから即座に使用禁止」とする必要はないが、その特性を理解した上で使い分けることが重要である。

• scp を使っても良い場面

  • 自分が管理しているサーバーや、信頼できるイントラネット内での転送。
  • ワンショットの単純なファイルコピー（利便性が高い）。

• sftp / rsync を使うべき場面

  • 不特定多数が利用する共用サーバーや、信頼性が不確かなホストへの接続。
  • スクリプトによる自動化（より厳密なエラーハンドリングが必要な場合）。
  • 大量のファイル転送やバックアップ用途。

scpは「暗号化されたrcp」であることを認識し、信頼できないサーバーに対してはより堅牢なプロトコルを選択するのが、現代のエンジニアに求められる作法と言えるだろう。

##　追記：CVEの具体的な内容

この記事で取り上げる scp のセキュリティリスクを理解するうえで、実際に報告された脆弱性（CVE）を具体例として紹介します。これらは単なるバグではなく、scp の設計思想に由来する根本的な弱点の表れと評価されています。

CVE-2019-6111：不正なファイル上書きの脆弱性#

scp の実装は、古くから継承された rcp 互換プロトコルに基づいています。この設計では、サーバーが送信するファイル名やパスをクライアントが十分に検証せず、そのままファイルとして生成・上書きしてしまうという前提が存在します。

問題の概要

• 悪意ある SSH サーバー（または侵害されたサーバー）が、応答で意図的に変則的なパス（例: ../../target）を返す。
• クライアント側 scp がそれを検証せずに解釈し、意図しないファイルの上書きや生成につながる。
• 例として ~/.ssh/authorized_keys などの重要ファイルを書き換えられる可能性がある。

影響

• 攻撃者が制御するサーバーに接続した際、クライアントのファイルシステムを意図せず改変されるリスクがある。

この問題は Debian セキュリティアナウンスでも報告され、scp のプロトコル仕様そのものの設計上の問題として指摘されました。
参照: Debian セキュリティアナウンス ― scp のファイル名検証に関する欠陥

CVE-2020-15778：コマンドインジェクションの可能性#

この脆弱性は、scp が内部でシェルコマンドを生成する際に、サーバ側から送られたファイル名を十分にサニタイズせずに扱ってしまう点に起因します。これにより、悪意あるファイル名が クライアント側でシェル展開され、結果として意図しないコマンドが実行される可能性が報告されました。

問題の仕組み

• サーバーが応答の一部としてメタ文字（例: バッククォート `cmd` やその他の特殊文字）を含む文字列を送る。
• クライアント側の scp がこれを検証せずにシェルに渡し、バッククォート内のコマンドが展開・実行される可能性がある。

例（概念）：

scp /local/file remoteserver:'touch /tmp/exploit/targetfile'

上記のような応答が scp に渡されると、クライアント側で /tmp/exploit が生成されるなどの副作用が起きることが確認されています。

影響

• ファイル転送時にクライアント側で不正なコマンドが実行される可能性。
• この種の問題はファイル名処理の不備に端を発するため、悪意あるサーバーに接続した場合に顕在化するリスクがある。

これらの CVE は単なる実装バグではなく、scp プロトコルが前提としている 「サーバから送られるファイル名やパスをほぼ無条件で信頼する」設計そのものが、現代のセキュリティ要件と相性が悪い点を示しています。

• CVE-2019-6111 は検証不足による任意ファイル上書きの危険性を、
• CVE-2020-15778 は不適切な文字列処理に起因するコマンドインジェクションの可能性をそれぞれ表しています。

これらを踏まえ、OpenSSH プロジェクトや多くの運用者は、安全性の高いプロトコルとして sftp や rsync -e ssh を推奨しています。