SFTPは、SSHの暗号化された接続の上でファイルの転送と操作を行うプロトコルで、正式名はSSH File Transfer Protocolです。この記事では、SFTPがFTPを暗号化したものではなく別物である理由、FTP・FTPS・SCPとのポートや暗号化範囲の違い、sftpコマンドでの対話操作とバッチ実行、sshd_configで取引先専用のchroot環境を作る設定までを、OpenSSH 10.5系（2026年10月時点）の一次情報をもとに整理します。最後に、自前のSFTPサーバーで足りる条件と、マネージドサービスやAPI連携へ移すべき場面を判断基準として示します。
まとめ：SFTPの正体とFTP・FTPS・SCPから選ぶときの判断基準
SFTPはSSHの1本の接続（既定はポート22）で、認証・暗号化・ファイル操作までを完結させます。FTPのように制御用とデータ用で接続が分かれないため、ファイアウォールで開けるポートが1つで済みます。転送の再開、一覧取得、リネーム、削除まで扱えるのが、単発コピー向けのSCPとの差です。
選び方は単純です。サーバーへSSHで入れる相手との定期連携ならSFTP。既存のFTP資産と証明書運用を残したいならFTPS。1回きりのコピーならSCP。取引先が数十社を超える、監査ログを長期保管する、リアルタイム性が要る、のいずれかに当たるなら、自前のSFTPサーバーは見送ってマネージドサービスかAPI連携へ寄せる判断になります。
SFTPの仕組み：SSHのチャネル上で動くファイル操作プロトコルの通信構造
SFTPを理解する近道は、FTPと名前が似ているだけで系譜が違うと押さえることです。土台はFTPではなくSSHにあります。
SFTPの定義とIETFドラフト版3がRFC化されなかった経緯と現状
SFTPの仕様は、IETFのSecure Shellワーキンググループが策定したドラフトです。広く使われているのはプロトコルのバージョン3で、2001年10月付けのdraft-ietf-secsh-filexfer-02が定義しています。その後も版を重ねたドラフトが出ましたが、RFCとして確定しないまま作業が止まりました。
事実上の標準は実装側にあります。OpenSSHのPROTOCOLファイルは、sftpとsftp-serverがリビジョン3を実装し、それより新しいドラフトは扱わないと明記しています。不足する機能は[email protected]、[email protected]、copy-dataなどの拡張で補う方式です。他社製クライアントとの相性問題は、多くがこの拡張の対応差から起きます。
ポート22の1接続で認証・暗号化・転送を完結させる通信の流れ
接続はまずSSHのトランスポート層（RFC 4253）で鍵交換と暗号化を確立し、次にユーザー認証を通します。その後の手順は、SSHの中にチャネルを1本開き、sftpという名前のサブシステムを起動することです。以降はSSH_FXP_OPEN・SSH_FXP_READ・SSH_FXP_WRITEといったパケットがこのチャネルを行き来します。
認証の仕組みはSSHそのものです。公開鍵認証やknown_hostsによるホスト鍵の確認は、SSH接続の仕組みと公開鍵認証・ポート22の運用設定で解説した内容がそのまま当てはまります。SSHでログインできる相手なら、SFTPも追加設定なしで使える構造です。
SFTPとFTP・FTPS・SCPの違いをポート・暗号化・再開可否で比較
「SFTPとFTPSの違い」は名前の近さから混同されがちです。設計上の差は、どの層で暗号化するかと、接続を何本使うかに集約されます。
FTP・FTPS・SFTPを使用ポート・暗号化範囲・FW設定で比べた表
FTPSは、FTPにRFC 4217（2005年10月）のTLSを足したものです。AUTH TLSコマンドで暗号化を始め、PBSZとPROTでデータ接続の保護を決めます。FTPの構造をそのまま残すため、データ用の接続が別に開きます。
| 観点 | FTP | FTPS | SFTP |
|---|---|---|---|
| 土台 | FTP | FTP＋TLS | SSH |
| 接続数 | 制御とデータで2系統 | 制御とデータで2系統 | 1本 |
| 既定ポート | 21＋データ用 | 21＋データ用 | 22 |
| パスワードの暗号化 | なし（平文） | あり | あり |
| 認証の方式 | パスワード | パスワード・証明書 | パスワード・公開鍵 |
| FWの設定負荷 | パッシブ用の範囲が要る | 暗号化で検査できず重い | 22番のみで軽い |
FTPSが残る理由は、既存のFTPサーバーとサーバー証明書の運用をそのまま延命できる点にあります。新規に作るなら、ポートが1つで鍵認証が使えるSFTPを既定にして差し支えありません。
SCPとの関係とOpenSSH 9.0でscpの内部がSFTPに替わった影響
SCPも同じSSH上で動きますが、別のプロトコルでした。OpenSSH 9.0のリリースノート（2022-04-08）は、scpが従来のscp・rcpプロトコルをやめ、既定でSFTPプロトコルを使うよう切り替えたと記しています。互換性の問題が出た場合だけ-Oで旧方式に戻せます。
つまり現在のscpは「SFTPを1行で呼ぶ単発コピー」に近い存在です。対話的な一覧取得や転送の再開が必要ならsftp、1回きりのコピーならscpと分ければ迷いません。scp側のオプションや旧方式に依存した書き方の注意点は、SCPコマンドの基本構文とOpenSSH 9.0以降の挙動変化にまとめています。
sftpコマンドで接続・転送・再開を試す対話モードとバッチ実行の手順
ここからは手を動かします。Linux・macOS・Windows 10以降のOpenSSHクライアントで共通のsftpコマンドを使います。オプションの定義はsftp(1)のマニュアルが一次情報です。
鍵を指定して接続しget・put・lsで操作する対話モードの基本手順
接続先は「ユーザー名@ホスト」で指定します。プロンプトがsftp>に変われば成功です。リモート側はls・cd、手元側は先頭にlを付けたlls・lcdで操作します。
$ sftp -i ~/.ssh/id_ed25519 -P 22 [email protected]
sftp> cd /var/log/nginx
sftp> ls -l
sftp> lcd /tmp
sftp> get access.log
sftp> put ./report.csv /home/deploy/inbox/
sftp> byeポート指定は大文字の-Pです。ディレクトリごと送受信するときはget -r・put -rを使います。初回接続ではホスト鍵の確認が出るので、相手から受け取ったフィンガープリントと照合してからyesを入力してください。
-bバッチで一時名アップロード後にrenameする夜間連携の書き方
取引先とのファイル連携をcronで回すなら、-bでコマンドを列挙したバッチファイルを渡します。要点は、受け手が書き込み途中のファイルを拾わないよう、一時名で送り切ってから本来の名前へ変えることです。
# upload.batch（バッチファイルの中身）
cd inbox
-rm orders_20261004.csv.part
put orders_20261004.csv orders_20261004.csv.part
rename orders_20261004.csv.part orders_20261004.csv
bye
# cronから実行（鍵認証・ホスト鍵は事前登録済みが前提）
sftp -b upload.batch -i ~/.ssh/partner_ed25519 -o StrictHostKeyChecking=yes [email protected]バッチモードはどれか1つのコマンドが失敗すると中断し、終了コードで失敗を返します。先頭に-を付けた行だけは失敗しても続行するため、前回の残骸を消すrmに付けています。パスワード入力は待てないので、鍵認証が前提です。Pythonから同じ処理を組むならParamikoでSSH接続・SFTP転送を行う使い方が参考になります。
中断した転送を-a・regetで再開する方法と-R・-Bの速度調整
回線が切れた大容量転送は、最初からやり直す必要がありません。sftp -aで起動するか、対話中にreget・reputを使うと、手元や相手に残った途中のファイルから続きを送ります。SCPには無い機能です。
速度が出ないときは、同時に投げるリクエスト数の-R（既定64）とバッファサイズの-B（既定32,768バイト）を調整します。遅延の大きい海外拠点との転送では-Rを増やすと効きやすい一方、共有回線では-l（Kbit/s単位）で帯域を絞り、業務通信を圧迫しない配慮が先です。
SFTPサーバー構築：sshd_configで取引先専用のchroot環境を作る手順
取引先にファイルを置いてもらうためだけに、シェルを開放する必要はありません。OpenSSH標準の機能で「SFTPだけ使えて、自分の領域の外が見えない」アカウントを作れます。設定項目の定義はsshd_config(5)のマニュアルに従います。
internal-sftpとMatch Groupでシェルを禁じSFTPだけ許可する設定
手順は、専用グループを作り、そのグループにだけSFTP専用の制約を掛ける流れです。internal-sftpはsshd内部で動くSFTPサーバーで、chroot先に補助ファイルを置かずに済みます。
# /etc/ssh/sshd_config（既存のSubsystem行を書き換え、Matchはファイル末尾へ）
Subsystem sftp internal-sftp
Match Group sftponly
ChrootDirectory /srv/sftp/%u
ForceCommand internal-sftp
PasswordAuthentication no
AllowTcpForwarding no
X11Forwarding no
# アカウントとディレクトリの準備
sudo groupadd sftponly
sudo useradd -g sftponly -s /usr/sbin/nologin -d /inbox partner01
sudo mkdir -p /srv/sftp/partner01/inbox
sudo chown root:root /srv/sftp/partner01
sudo chmod 755 /srv/sftp/partner01
sudo chown partner01:sftponly /srv/sftp/partner01/inbox
# 構文確認してから反映（サービス名はUbuntuでssh、RHEL系でsshd）
sudo sshd -t && sudo systemctl reload sshdForceCommand internal-sftpが、クライアントが要求したコマンドを無視してSFTPだけを起動させます。ホームを/inboxにしておけば、chroot後にログインした時点での移動先は、書き込み可能なディレクトリです。sshd -tを挟まずに反映すると、記述ミスで自分のSSH接続まで失う事故につながります。
ChrootDirectoryの所有者root・書込不可要件で接続が切れる失敗例
構築で最も多い失敗は「認証は通るのに即切断される」症状です。sshd_config(5)は、ChrootDirectoryのパスを構成するすべてのディレクトリがroot所有で、グループやその他から書き込めないことを要件にしています。上の例で/srv/sftp/partner01を利用者の所有にすると、この要件に反して接続が拒否されます。
利用者に書かせたい場所は、chrootの1階層下（例ではinbox）に作って所有者を渡すのが定石です。原因の特定はjournalctl -u sshdなどのsshdログで行い、bad ownership or modes for chroot directoryの行が出ていれば権限の問題と判断できます。
鍵管理と総当たり対策・OpenSSH更新を含む運用時の点検項目
公開したSFTPサーバーには、ポート22への総当たりが必ず届きます。パスワード認証を切って鍵に限定し、接続元IPを取引先のアドレスへ絞るのが基本線です。絞り切れない場合はFail2banによるSSH総当たり攻撃の自動遮断を重ねます。
OpenSSH自体の更新も点検項目に入れます。OpenSSHのリリースノートでは、10.3（2026-04-02）でsftpのメモリ安全性に関する修正、10.4（2026-07-06）で悪意あるサーバーからのダウンロード先に関わるsftpの修正とinternal-sftpの引数処理の修正が入り、最新は10.5（2026-08-11）です。版の確認と更新の手順はOpenSSHのバージョン確認とアップデート手順で扱っています。
SFTPを採用する条件と見送ってマネージドやAPI連携を選ぶ場面の判断
SFTPは枯れた技術で、動かすまでは簡単です。問題は運用が積み上がったときに出ます。どこまで自前で持つかを、条件で線引きします。
自前SFTPサーバーで足りる取引先数・頻度・監査要件の採用条件
自前のSFTPサーバーで足りるのは、次の条件がそろう場合です。取引先が数社から十数社で、連携が日次や週次のバッチ、相手もSSH鍵を扱える技術者を持っている。この範囲なら、前章の設定とOpenSSHの更新だけで回り、月額の固定費もサーバー1台分に収まります。
逆に、相手が非エンジニアで「鍵ファイルを作って送ってください」が通じない場合、SFTPは選択肢から外します。ブラウザで受け渡せる大容量ファイル送信サービスの種類と選び方のほうが、問い合わせ対応の工数まで含めて安く済みます。
SFTP連携を見送りAWS Transfer FamilyやAPI連携へ移す失敗場面
自前運用が破綻するのは次の場面です。
- 取引先が数十社を超え、アカウントと鍵の発行・失効が手作業で追いつかない
- 誰がいつ何を置いたかの監査ログを、年単位で保管・提出する必要がある
- 夜間バッチでは遅く、受注や在庫を数分以内に反映したい
- 受け取ったファイルの検証や取り込み失敗の再送を、人が毎朝確認している
前の2つはサーバー運用の問題なので、AWS Transfer FamilyのSFTPエンドポイント設計と料金のようなマネージドサービスへ移せば解消します。後の2つはファイル連携という方式そのものの限界です。ここでSFTPを延命せず、API開発・システム連携でイベント単位のAPI連携へ切り替えるのが、障害対応の手間まで含めた正解になります。
SFTPの仕組み・接続方法・FTPとの違いについてのよくある質問
SFTPを使い始めるときに検索されやすい疑問へ、短く答えます。
SFTPとFTPSはどちらを選ぶべきですか？
新規構築ならSFTPを選びます。使うポートが22番の1つで済み、公開鍵認証で自動化しやすいためです。FTPSを選ぶのは、既存のFTPサーバーと証明書運用を残したい場合や、取引先がFTPSしか対応していない場合に限られます。どちらも通信は暗号化されるので、選択の軸は安全性より運用のしやすさです。
SFTPのポート番号は何番ですか？変更できますか？
既定はSSHと同じ22番です。SFTPはSSHのサブシステムなので、sshd側のPortを変えればSFTPのポートも変わります。接続側はsftp -P 2222 user@hostのように大文字の-Pで指定します。ポート変更はログのノイズを減らす効果はあっても防御策にはならないため、鍵認証と接続元制限を先に固めてください。
WindowsからSFTPで接続するにはどうすればよいですか？
Windows 10以降はOpenSSHクライアントを標準の機能として備えており、PowerShellやコマンドプロンプトからsftpコマンドをそのまま実行できます。GUIで操作したい場合に使うのは、WinSCPやFileZillaなどのSFTP対応クライアントです。どの方法でも、接続先・ユーザー名・秘密鍵の3点がそろえば接続できます。
SFTPで送れば中身まで安全だと言えますか？
守られるのは通信経路だけです。サーバーに置かれたファイル自体は暗号化されないため、保存先の権限設定や保管期間の管理については、通信経路の保護とは別の対応が必要です。初回接続でホスト鍵を確認せずに受け入れると、なりすましたサーバーへ送ってしまう余地も残ります。鍵の管理とホスト鍵の照合までそろえて、初めて安全と言えます。
SFTPの転送を自動化するにはどうすればよいですか？
シェルならsftp -bにコマンドを並べたバッチファイルを渡し、cronやジョブ管理ツールから実行します。プログラムからはPythonのParamikoなど、SFTPに対応したライブラリを使います。どちらも鍵認証が前提で、パスワードをスクリプトに書き込む方式は避けてください。失敗を検知できるよう、終了コードの監視も組み込みます。
関連記事
- SSH接続とは？仕組み・公開鍵認証・ポート22から安全な運用設定まで実装者向けに解説：SFTPの土台となるSSHの認証と鍵の扱い
- SCPコマンドとは？基本構文・主要オプション・SSH越しの安全なファイル転送を実装者向けに解説【2026年版】：単発コピー向けのscpとOpenSSH 9.0以降の変化
- AWS Transfer Familyとは？SFTP・AS2の料金とエンドポイント設計をCLI手順つきで解説：SFTPサーバーをマネージドで持つ選択肢
- HULFTとは？ファイル転送の仕組みと暗号化・ジョブ連携の設計とiPaaS移行の判断基準を解説：企業間ファイル転送の専用製品との比較に
- Paramikoとは？PythonでSSH接続・コマンド実行・SFTP転送を行う使い方【5.0対応】：プログラムからSFTP転送を組む実装
