取引先から「SFTPでファイルを送ってください」と言われた瞬間、手が止まることありませんか。
FTPと何が違うのか、FTPSとは別物なのか、接続情報のどこを入れればいいのかが曖昧なまま触ると、接続エラーだけでなく、設定ミスで提出や納品が遅れます。
ロロメディア編集部でも、納品前日に「SFTP指定なのにFTPSのつもりで設定していた」ことに気づき、接続先のポートも認証方式も合わずに30分以上止まったことがありました。
SFTPは難しい技術に見えますが、先に「何の上で動くのか」と「接続時に何を確認すべきか」を押さえると、一気に整理できます。
結論から言うと、SFTPは「SSHという安全な通信の上でファイルをやり取りする仕組み」です。
SSHは暗号化、サーバー認証、完全性保護を提供するプロトコルで、SFTPのサーバー側はSSHサーバーのサブシステムとして動くのが一般的です。FTPSは別物で、FTPにTLSを組み合わせて保護する方式です。
ここからは、SFTPの意味、仕組み、接続手順、FTPSとの違い、現場で詰まりやすいポイントまで、実務で使える形で整理します。
SFTPとは
SFTPは「SSHで守られたファイル転送」です
ここで勘違いしやすいのが、「SFTPはSecure FTPの略だからFTPの一種だろう」という理解です。
名前は似ていますが、SFTPはFTPをそのまま暗号化したものではありません。土台になっているのはFTPではなくSSHです。
この違いを曖昧なまま設定すると、接続先からSFTPと言われているのに、クライアント側でFTPSや通常のFTP設定を選んでしまいます。
現場ではここが最初の詰まりどころです。
図で見るとSFTPの流れ
会議前にサーバーへ資料を上げる場面を想像してください。
あなたのPCからいきなりファイルが飛ぶのではなく、まずSSHで安全な通路を作り、その上でファイル操作が流れます。
図解イメージはこうです。
SSH Connection Protocol は、1本の暗号化トンネル上で複数のチャネルを扱える設計です。
OpenBSD の sftp-server も、SFTPサーバーは sshd から Subsystem として呼ばれると説明しています。つまり、SFTP単体で独立して待ち受けるより、SSHサーバーの一機能として動く理解が近いです。
SFTPの仕組みを実務レベルで解説
SSHが土台なので、まず守られるのは通信路そのものです
SFTPでやり取りする内容は、ファイル本文だけではありません。
ログイン情報、ファイル名、ディレクトリ操作、削除や移動の命令も含めて、通信全体がSSHの保護対象になります。
この仕組みを知らないと、接続できないときに「ファイル転送ソフトの問題」と考えがちです。
でも実際には、鍵認証、サーバー鍵の確認、ポート、SSH接続可否など、ファイル転送以前のSSH層で止まっていることがかなりあります。
認証はパスワードだけとは限りません
「SFTPのログイン情報」と言われると、IDとパスワードだけを想像しやすいですよね。
でもSSHの認証はそれだけではありません。
SSH Authentication Protocol は、公開鍵認証、パスワード認証、ホストベース認証などを扱う一般的なユーザー認証プロトコルです。
OpenSSH系の運用でも、SFTP接続に公開鍵認証を使うケースは普通です。
実務では、接続情報として次のどれを渡されるかで準備が変わります。
| 相手から渡されるもの | 意味 | こちらで必要な準備 |
|---|---|---|
| ホスト名 | 接続先サーバーの住所 | クライアントへ入力 |
| ポート番号 | 接続口 | 通常はSSH系の設定で指定 |
| ユーザー名 | 接続アカウント | クライアントへ入力 |
| パスワード | パスワード認証用 | 入力または保存 |
| 秘密鍵ファイル | 公開鍵認証用 | クライアントへ読み込む |
| フィンガープリント | サーバー本人確認用 | 初回接続時に照合 |
SFTPとFTPSの違いは「どのプロトコルの上で安全にするか」
名前は似ていても土台が違います
SFTPとFTPSは、どちらも安全なファイル転送っぽく見えます。
でも、仕組みははっきり別です。
ここを曖昧にしたまま接続設定を始めると、クライアント側で「FTP over TLS」を選ぶべきなのか、「SFTP/SSH」を選ぶべきなのかで止まります。
接続先が指定している方式と一致しない限り、正しいホスト名とユーザー名を入れてもつながりません。
実務ではポートと認証の考え方でも差が出ます
IANAのサービス名登録では、SSHは22番、FTPは21番、FTPSは990番が登録されています。
もちろん運用上は別ポートへ変更されることもありますが、標準的な入口としてはこの差を押さえると理解しやすいです。
迷ったらこの見分け方で十分です
この3つのどれかが出たら、まずSFTPを疑ってください。
逆に、FTP over TLS や FTPS と明示されているなら、SFTPとは別設定です。
SFTP接続に必要なものを最初に揃える
接続できない人は入力情報を揃えずにクライアントを開いています
SFTPが難しく感じる一番の理由は、接続ソフトを先に開くことです。
画面を見ながら考え始めると、どの項目に何を入れるのかで止まります。
でも実務では逆です。
先に接続情報を紙かメモに揃えてから、最後にクライアントへ入力したほうが速いです。
最低限、次の6点を確認してください。
OpenSSH の sftp マニュアルでも、接続先は [user@]host[:path] や sftp:// 形式で指定できます。
つまり、少なくとも「どこへ」「誰として」「必要ならどのパスへ」接続するのかが分からないと始まりません。
サーバー鍵の確認で止まるのは正常です
初回接続時に「このサーバー鍵を信頼しますか」といった警告が出ることがあります。
これ、エラーに見えますが正常な確認です。
ここで怖がって閉じる人が多いですが、本当にやるべきことは閉じることではありません。
相手から渡されたフィンガープリントと一致するかを確認してください。違うなら止める、一致するなら登録する。この順番です。
SFTPの接続方法は「コマンド」と「GUI」で考えると整理しやすい
コマンド接続は最短ですが、情報の意味が分かっていないと詰まります
たとえば OpenSSH 系の環境なら、sftp user@host のような形で接続できます。sftp は OpenSSH の公式マニュアルでも、ファイル転送プログラムとして案内されています。
ただ、実務ではコマンドでつなぐより、GUIクライアントを使う人のほうが多いでしょう。
その場合でも、考え方は同じです。ホスト、ポート、ユーザー名、認証方式、パスを埋めるだけです。
GUI接続でも入力の順番を固定すると迷いません
おすすめの順番はこうです。
| 入力順 | 何を入れるか | 見落としやすい点 |
|---|---|---|
| 1 | プロトコル | SFTP / SSH を選ぶ |
| 2 | ホスト | ドメインかIPか確認する |
| 3 | ポート | 指定がなければ標準運用を確認する |
| 4 | ユーザー名 | メールアドレス形式のこともある |
| 5 | 認証方式 | パスワードか鍵かを確認する |
| 6 | 保存先パス | 接続後に置く場所を確認する |
この順番だと、途中で迷ってもどこが未確認か分かりやすいです。
現場では「認証方式」と「保存先パス」の確認漏れが本当に多いです。
SFTPで接続できないときの原因はほぼこの5つです
1つずつ切り分ければ大半は直ります
SFTP接続エラーが出ると、全部同じに見えます。
でも実際は、原因を切り分ければほぼ定番です。
実務でよくある原因を整理すると、こうなります。
| 原因 | 何が起きるか | 先に見る場所 |
|---|---|---|
| プロトコル違い | そもそも接続開始できない | SFTP/FTPS/FTPの選択 |
| ポート違い | 接続タイムアウトしやすい | 接続先案内書 |
| 認証方式違い | パスワードを入れても入れない | 鍵認証かどうか |
| サーバー鍵未確認 | 警告で止まる | フィンガープリント照合 |
| 保存先パス違い | つながるが置けない | 指定ディレクトリ権限 |
この5つを上から潰すだけで、かなり解決します。
逆に、エラー文だけを見て感覚で触ると時間が溶けます。
「接続できない」ではなく「どこまで進んだか」で判断してください
接続トラブルで大事なのは、どの段階で止まっているかです。
ホストへ到達していないのか、認証で落ちているのか、接続後の操作で詰まっているのか。ここを分けるだけで対処が変わります。
たとえば、ホスト鍵確認の画面まで行けているなら、通信先には届いています。
その場合、ネットワークではなく認証か確認手順の問題です。
SFTPを使うメリットは「安全」だけではありません
運用をシンプルにしやすいのが強みです
SFTPというと、暗号化ばかり注目されがちです。
もちろん安全性は大きな理由ですが、現場では運用のしやすさもかなり重要です。
つまり、別途ファイル転送のためだけにまったく別の認証基盤を持たずに済む構成を取りやすいわけです。
セキュリティ運用とアカウント運用を近い考え方でまとめたいとき、SFTPはかなり扱いやすいです。
社外連携でも説明しやすいです
取引先へ接続方法を説明するときも、SFTPは比較的整理しやすいです。
「ホスト」「ポート」「ユーザー」「鍵またはパスワード」という形で渡しやすく、接続後の操作も一般的なクライアントで対応できます。
逆に、方式を曖昧にして「安全なFTPです」などと伝えると混乱が起きます。
SFTPなのかFTPSなのかを最初から明示するだけで、設定事故はかなり減ります。
実務でSFTPを使うならこの確認だけは先にやってください
接続前チェックをしないと本番直前に止まります
納品直前、移行作業直前、バックアップ受け渡し直前。
このタイミングで初めて接続確認をするのは危険です。
SFTPは難しい技術というより、事前確認が必要な技術です。
相手から情報を受け取った段階で、一度テスト接続まで済ませておくと、本番で止まりにくいです。
最低限、次を事前チェックしてください。
この5つが揃っていれば、現場ではかなり強いです。
接続できるかどうかだけでなく、「どこへ置くか」まで確認しておくと再作業が減ります。
まとめ
SFTPは、SSHの上でファイルを安全にやり取りする仕組みです。
SSHは暗号化、サーバー認証、完全性保護を提供し、SFTPのサーバー側はSSHサーバーのサブシステムとして動くのが一般的です。FTPSはFTPにTLSを組み合わせる別方式なので、名前が似ていても仕組みは違います。
ロロメディア編集部でも、SFTPで詰まるときは技術の難しさより、確認不足が原因でした。
今すぐ一つだけやるなら、「SFTPなのかFTPSなのか」を相手へ確認してください。そこが確定すると、接続設定の半分は終わったのと同じです。
