最終更新：2026-01-11

scpはSSHによって通信経路が暗号化されるため、盗聴（パケットキャプチャ）に対しては強力な耐性を持つ。

しかし、通信相手が「本物のサーバー」であることを確認できない場合、中間者攻撃（Man-in-the-Middle Attack） の被害に遭うリスクがある。本記事では、scp利用時におけるこの攻撃の仕組みと、それを防ぐための「ホスト認証」について解説する。

中間者攻撃（MitM）とは#

中間者攻撃とは、悪意ある第三者がクライアントとサーバーの間に割り込み、通信を中継・改ざんする攻撃手法である。

攻撃のシナリオ#

ユーザー（Alice）が、サーバー（Bob）へファイルをscpで送信しようとしているとする。攻撃者（Eve）がネットワーク経路に介入した場合、以下のような事態が発生する。

1. なりすまし: EveはBobのふりをしてAliceの接続に応答する。
2. 偽の鍵交換: Eveは自分の公開鍵をAliceに送りつける。
3. 暗号化通信の確立: AliceはEveとの間で暗号化通信を確立してしまう（AliceはBobと繋がっていると思い込んでいる）。
4. データ窃取: Aliceが送ったファイルはEveによって復号され、盗み見られる。
5. 再送信: Eveは盗んだデータを（怪しまれないように）本物のBobへ転送する。

この場合、通信自体は「Alice⇔Eve」と「Eve⇔Bob」の間でそれぞれ暗号化されているため、単なる暗号化だけでは中間者攻撃を防ぐことはできない。

scp (SSH) の防御策：ホスト鍵検証#

この攻撃を防ぐ唯一の手段は、接続先が「本物のBobである」と数学的に証明することである。これがSSHプロトコルにおけるホスト認証の役割である。

初回接続時の警告#

scp（およびssh）で初めて接続するサーバーの場合、以下のような警告が表示される。

The authenticity of host 'remotehost (192.168.1.10)' can't be established.
ED25519 key fingerprint is SHA256:KpG... (省略) ...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

これは「相手が本物か分からないが、提示された身分証明書（フィンガープリント）はこれである。信用するか？」という問いかけである。

正しい対応: サーバー管理者に事前に確認したフィンガープリントと一致することを確認して yes を入力する。

危険な対応: 確認せずに反射的に yes を入力する。（ここで攻撃者の鍵を承認してしまうと、MitMが成立する）

一度承認すると、その鍵は ~/.ssh/known_hosts に保存され、次回以降は自動的に照合が行われる。

危険な運用：検証の無効化 自動化スクリプトやクラウド環境でのセットアップ時において、エラー回避のためにホスト認証を無効化するケースが見られるが、これはセキュリティ上極めて危険である。

StrictHostKeyChecking=noのリスク 以下のオプションは、ホスト鍵の確認をスキップし、どんな相手でも無条件で接続を受け入れる設定である。

scp -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null" file.txt user@host:~

このコマンドは「誰でもいいから、そのIPアドレスに応答した相手にデータを送る」という意味になる。DNSスプーフィングやARPスプーフィングによって攻撃者が偽のサーバーを立てていた場合、警告なしで攻撃者にファイルを送信してしまうことになる。

警告が出た場合の対処 もし、過去に接続したことがあるサーバーへのscp実行時に以下の警告が出た場合は、最大級の警戒が必要である。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

これは「以前保存した鍵と、今提示された鍵が違う」という警告である。

正当な理由: サーバーのOS再インストールや鍵の更新が行われた（管理者へ確認が必要）。

攻撃の検知: 何者かが中間者攻撃を仕掛けている可能性がある。

この警告を無視して known_hosts から該当行を削除し、再接続を試みるのは、管理者に確認が取れた場合のみに限定すべきである。

まとめ#

scpの暗号化だけでは中間者攻撃は防げない。

ホスト鍵指紋（Fingerprint）の確認が、なりすましを防ぐ唯一の砦である。

利便性を優先して StrictHostKeyChecking=no を恒常的に使用することは、セキュリティ機構を自ら放棄する行為に等しい。

安全なファイル転送のためには、プロトコルの選択（sftpの利用）だけでなく、正しい鍵管理と認証プロセスの理解が不可欠である。