先に要点
- FTP は「ファイル転送専用」ではなく、LIST / CWD / DELE / RNFR などのコマンドを持つファイル管理プロトコル。FTPソフトでサーバのファイル一覧を歩いたり、削除・リネーム・ダウンロードができるのは、これらのコマンドが用意されているから。
- SSH は遠隔シェルアクセス(任意コマンド実行)の土台で、SFTP や SCP は SSH の上に乗ったファイル転送機能。「ファイル管理 + 転送」の射程では FTP と重なるが、SSH はその先にサーバ上のあらゆる操作(grep / systemctl / 任意スクリプト)を含む。
- 違いの核は シェルアクセス(任意コマンド実行)の有無。FTP は「ファイル管理に特化したリモートファイラー」、SSH は「シェルそのものをリモートで触る」。FTPソフトと SFTPソフトの UI が似て見えるのは、クライアント側が両プロトコルを同じファイラー UI で扱うため。
- 歴史的には FTP(ファイル管理)と Telnet(シェル)が分業していた時代があり、1995 年の SSH 登場でシェルもファイル転送もトンネルも 1 プロトコルに統合された。FTP と Telnet が同時に置き換えられた、というのが本当の関係。
- FTP はパスワードも本文も平文で流れる古い設計で、現代の本番運用では基本使わない。新規導入は SFTP / SCP / クラウドストレージ(S3 / R2)。FTP は「古いレンタルサーバ」「取引先との EDI が FTP 固定」など、後ろ向きの理由で残るのが現状。
「サーバにファイルを上げるとき FTP と SSH のどっちで入ればいいんですか?」「FTPソフトでサーバの中のファイル一覧が見えるけど、これって SSH の ls と同じなの?」 ── ファイル転送系の話は名前が似ているプロトコルが多くて、最初は誰でも混乱します。
実は FTP は単純なファイル転送プロトコルではなく、リモートのファイル一覧を取得したり、ディレクトリ移動・削除・リネームができる「ファイル管理プロトコル」 です。FTPソフトでサーバのフォルダツリーを歩けるのはそのため。一方 SSH は「サーバにログインして任意のコマンドを実行する」遠隔シェルの土台で、SFTP や SCP は SSH の上に乗ったファイル転送機能です。
つまり 「ファイル管理 + 転送」という用途では FTP と SSH(SFTP)は射程が重なる、一方 「サーバを実際に操作する(コマンドを実行する)」という意味では SSH のほうが射程が広い、というのが正しい関係です。
この記事では、FTP と SSH の役割の違い、SFTP・SCP との関係、FTPソフトと SFTPソフトが「ほぼ同じに見える理由」、現代の運用でどう使い分けるかを整理します。「ftp と sftp の違い」「FTPソフトで ls みたいに使えるのはなぜ?」「FTP のシェル版はないの?」 系の疑問にまとめて答える形で書きました。
まず大前提 — FTP と SSH の関係を整理する
FTP と SSH を比べる前に、「そもそも何のためのプロトコルか」 を揃えておきます。「完全に別物」ではなく「重なる部分と重ならない部分がある」 のがポイントです。
| プロトコル | 主な目的 | 位置づけ |
|---|---|---|
| FTP (File Transfer Protocol) | ファイル管理 + 転送 | 一覧・移動・削除・リネーム・転送が揃った古い管理プロトコル(シェルなし) |
| Telnet | 遠隔シェルアクセス | FTP と同時代の平文シェルプロトコル(現代では非推奨) |
| SSH (Secure Shell) | 遠隔シェル + ファイル転送 + トンネル | Telnet と FTP の両方を置き換える統合プロトコル(暗号化必須) |
| SFTP (SSH File Transfer Protocol) | ファイル管理 + 転送 | SSH の上で動く、FTP 相当のファイル操作機能 |
| SCP (Secure Copy) | ファイルコピー | SSH の上で動くシンプルなコピーコマンド |
| FTPS (FTP over SSL/TLS) | ファイル管理 + 転送 | FTP に SSL/TLS の暗号化を後付けしたもの(SFTP とは別物) |
ここで SFTP と FTPS は名前は似ているがまったく別物、というのが最初の落とし穴です。
- SFTP は SSH の機能の一部。ポート 22 番、SSH の認証と暗号化をそのまま使う。
- FTPS は FTP に SSL/TLS を被せたもの。ポート 21 番か 990 番、証明書ベースの暗号化。
実務では SFTP のほうがほぼデファクトで、「SSH 化されたファイル転送」 という意味では SFTP / SCP を指すと考えて大きく外しません。
FTP は「ファイル管理プロトコル」 — どんなコマンドを持つか
FTP を「単なるファイル転送」と捉えると、FTPソフトでサーバのフォルダツリーが歩ける現象がうまく説明できません。実際の FTP プロトコルには、UNIX 系の ls / cd / mv / rm に相当するコマンドが標準で揃っています。
| FTP コマンド | 動き | シェルでの相当 |
|---|---|---|
| LIST | ファイル一覧(詳細表示) | ls -l |
| NLST | ファイル名だけ一覧 | ls |
| CWD | ディレクトリ移動 | cd |
| PWD | 現在地表示 | pwd |
| MKD | フォルダ作成 | mkdir |
| RMD | フォルダ削除 | rmdir |
| DELE | ファイル削除 | rm |
| RNFR + RNTO | リネーム | mv |
| STOR | アップロード | cp local remote |
| RETR | ダウンロード | cp remote local |
| SIZE / MDTM | サイズ・更新日時取得 | stat |
つまり FTP の射程は「リモートファイルシステムを覗いて、フォルダ移動して、ファイル操作して、転送する」までを含んでいる。これが「FTP = ファイル管理プロトコル」と言える根拠です。
FTPソフトでファイラーのように見える理由
FileZilla / WinSCP / Cyberduck のような FTPソフトでサーバのフォルダツリーがブラウザのように見えるのは、上のコマンド群を裏で叩いた結果を UI に並べているからです。
UI の中身
フォルダを開く操作は内部で CWD + LIST、削除は DELE、名前変更は RNFR + RNTO を送っている。ユーザーから見るとファイラーの操作だが、プロトコル上は普通の FTP コマンド。
SFTP モードでも見え方は同じ
SFTP に切り替えても UI はほぼ変わらない。SSH のサブシステムに opendir / readdir 相当を投げてツリー表示するため、操作感は FTP と同じ。裏のプロトコルが違うだけで、ユーザー体験はほぼ同一。
SSH の ls との違い
SSH でログインして ls を叩くと、サーバ側のシェルが ls コマンドを実行して結果を返す。FTP の LIST はサーバ側の FTP デーモンが一覧データを返す。仕組みは違うが、見える結果は近い。
決定的な違い
FTP では ls や cd 相当はできるが、grep や tar や systemctl restart のような任意コマンドは実行できない。「ファイル管理」までで止まる。SSH は「シェル」を提供するので、その先のサーバ操作全部が射程に入る。
つまり 「FTPソフトで ls / cd 感覚にファイル一覧が見える」のは錯覚ではなく、プロトコルの設計どおりです。違いはその先で、SSH は任意コマンドが叩けて、FTP は叩けない。
違いの核 — シェルアクセスの有無
ここまでをまとめると、FTP と SSH の決定的な違いは 「シェル(任意コマンド実行)の有無」 に集約されます。
| 操作 | FTP | SSH |
|---|---|---|
| ファイル一覧・ディレクトリ移動 | ○(LIST / CWD) | ○(ls / cd) |
| 削除・リネーム | ○(DELE / RNFR + RNTO) | ○(rm / mv) |
| アップロード・ダウンロード | ○(STOR / RETR) | ○(SFTP / SCP) |
| ファイルの中身を表示 | △(RETR で落として開くだけ) | ○(cat / less) |
ログ検索(grep 等) | × | ○ |
パッケージ管理(npm / apt) | × | ○ |
サービス再起動(systemctl restart) | × | ○ |
| シェルスクリプト実行 | × | ○ |
| ポートフォワード / トンネリング | × | ○ |
FTP は「ファイル管理に特化したリモートファイラー」、SSH は「シェルそのものをリモートで触る」 という関係。ファイル管理だけ見ると重なりますが、SSH はその先にサーバ上のすべての操作が含まれる、というのが射程の広さの違いです。
歴史 — FTP と Telnet、そして SSH に統合された流れ
「FTP のシェル版はないの?」 という疑問はとても自然で、答えは 「FTP プロトコル自体にシェル機能はないが、同時代に Telnet という対になる平文シェルプロトコルがあった」です。
| 時代 | シェルアクセス | ファイル管理・転送 | 暗号化 |
|---|---|---|---|
| 1970s 〜 1990s 前半 | Telnet / rsh / rlogin | FTP / rcp | なし(全部平文) |
| 1995 年 〜 現在 | SSH | SFTP / SCP(= SSH の機能) | あり(SSH に統合) |
つまり昔は 「シェルは Telnet、ファイル管理は FTP」 と役割を分けていた。FTP に意図的にシェル機能を持たせなかったのは、当時 Telnet という別プロトコルが既にあったからです。
1995 年に SSH が登場し、「シェル + ファイル転送 + トンネリング」を 1 プロトコル・1 ポート・1 認証に統合しました。これによって Telnet と FTP は同時に置き換えられた、というのが歴史の本筋です。
Telnet の今
平文でパスワードもコマンドも丸見えのため、現代の本番ではほぼ使われない。ネットワーク機器の初期設定でわずかに残るくらい。FTP と運命を共にした。
rsh / rlogin / rcp
BSD UNIX 系の平文シェル + ファイルコピー群。これも SSH の ssh / scp に置き換えられた。「r系」コマンドを使う案件は現代ではほぼない。
SSH が画期的だった点
「シェル + 転送 + トンネル」を 1 プロトコルに統合し、しかも すべて暗号化が必須 にした。それまで 4 種類のプロトコルを使い分けていたのが 1 本に集約された。
FTP だけ残った理由
Telnet は完全に使われなくなったが、FTP は「ファイル受け渡し用」として古い案件で生き残った。シェルが要らない用途では暗号化なしでも何とか回せた、という事情。それでも現代では SFTP に置き換えるのが正解。
「FTP のシェル版」を歴史的に探すなら Telnet がその答え。そしてその両方を SSH 1 本が飲み込んだ、というのが現代に至る流れです。
FTP の中身 — 古い設計の何が問題か
FTP は 1971 年に設計されたプロトコルで、インターネットの黎明期から使われています。シンプルで分かりやすい反面、現代の本番運用では使われなくなった理由がはっきりしています。
平文通信
FTP はパスワードもファイル本文もそのまま平文で流れる。同じネットワーク上で Wireshark のようなツールを動かせば、認証情報もファイル中身も丸見え。「内部ネットワークだけだから」 のような言い訳が通じない時代になった。
2 本のコネクション
FTP は制御用 (ポート 21) とデータ用 (ポート 20) で別々のコネクションを張る。「コマンドを送る回線」 と 「実ファイルを流す回線」 を分けている設計。これがファイアウォール・NAT 越えを難しくする最大の原因。
アクティブとパッシブ
「 アクティブモード」 はサーバ側からクライアントへデータ用の接続を張りに行く方式で、家庭の NAT 越しでは破綻する。「パッシブモード」 はクライアントからサーバへ追加接続する方式で、こちらが現代の事実上の標準。ただし 「パッシブで使うランダムポート群」 をファイアウォールで開ける必要がある。
認証は ID とパスワード
標準では 「USER と PASS コマンド」 を平文で送るだけ。鍵認証のような仕組みはなく、「サーバごとに違うパスワードを管理する」 が前提になる。漏れたときに被害が大きくなりやすい。
「平文 + 接続が複雑 + 鍵認証なし」 という3点で、FTP は現代のセキュリティ・運用要件と合わなくなった、というのが歴史的な経緯です。
FTP の典型的なフロー
理解の助けに、ざっくりした流れだけ整理します。
「制御とデータで別々のコネクションを張る」 という、現代の Web プロトコルでは滅多に見ない設計が FTP のクセです。
SSH の中身 — 何を解決したか
SSH は 1995 年に設計されたプロトコルで、「Telnet や rsh のように平文で遠隔ログインするのをやめよう」 というのが出発点でした。
通信全体を暗号化
クライアントとサーバの間でセッション開始時に鍵交換を行い、以降の通信を共通鍵で暗号化する。途中経路で盗聴されても、パスワードもコマンドも見えない。
公開鍵認証が主流
ID とパスワードでもログインできるが、本番運用では公開鍵認証がほぼ前提。手元の秘密鍵 (例: ~/.ssh/id_ed25519) と、サーバ側に置いた公開鍵 (~/.ssh/authorized_keys) のペアで認証する。鍵が漏れない限りパスワード総当たり攻撃が効かない。
トンネリング機能
SSH にはポートフォワーディング (トンネリング) の機能がある。「手元の 5432 番をサーバの 5432 番にトンネルする」 ような使い方で、DB クライアントを直接外に出せない環境でも安全に接続できる。EC2 Instance Connect など、クラウド側もこの仕組みに依存している。
SSH は遠隔ログイン + 暗号化 + ファイル転送 + トンネリングを 1 本のプロトコルで束ねている、現代インフラ運用の基礎部品です。
SSH の典型的なログインフロー
「セッションが暗号化された状態でファイル転送や遠隔操作ができる」 のが SSH の世界です。
SFTP と SCP — SSH ベースのファイル転送
SSH 上でファイルをやり取りする方法として、SFTP と SCP の 2 つがよく使われます。
| 項目 | SFTP | SCP |
|---|---|---|
| ベース | SSH (ポート 22) | SSH (ポート 22) |
| 機能 | FTP に近い操作 (ディレクトリ閲覧、再開、リネーム、削除) | シンプルなコピーのみ |
| クライアント例 | WinSCP / FileZilla (SFTP モード) / Cyberduck / VS Code Remote-SSH | コマンドの scp |
| 転送の中断と再開 | 対応 (クライアントによる) | 基本非対応 |
| 大容量・大量ファイル | 得意 (転送制御がある) | シンプルな分、機能不足 |
| 近年の推奨度 | 高 (実質デファクト) | 残ってはいるが、SFTP か rsync over ssh 推奨 |
OpenSSH は近年、「scp は古い仕組みで安全面の懸念もあるため、内部的に SFTP プロトコルを使う実装に切り替えた」 という経緯があります。コマンドとしての 「scp」 は今も使えますが、新規で覚えるなら SFTP か rsync over SSH を中心に学ぶのが現代的です。
よく使うコマンド例
# SFTP でログインしてインタラクティブにファイル操作
sftp user@example.com
# SFTP で 1 コマンドだけ実行 (アップロード)
sftp user@example.com <<< "put deploy.zip /var/www/"
# scp でローカルからサーバへコピー
scp deploy.zip user@example.com:/var/www/
# rsync over SSH で差分同期 (推奨)
rsync -avz --delete ./dist/ user@example.com:/var/www/site/
「rsync over SSH」 は変更のあるファイルだけ送る + 圧縮 + 進捗表示が標準で揃っていて、デプロイ用途では SFTP より便利な場面も多いです。
FTPS との違い — 名前で迷わないために
「FTP の暗号化版」 として、もう 1 つ FTPS という選択肢があります。SFTP とは別物なので、ここで切り分けておきます。
古い FTP にSSL/TLS の層を被せて暗号化したもの。プロトコル本体は FTP のままで、ポート 21 番か 990 番を使う。「制御接続とデータ接続が別」 という FTP のクセはそのまま残る。
SFTP は SSH の機能
SFTP はSSH のサブシステムとして動く別系統のプロトコル。FTP とは中身がまったく違う。ポート 22 番 1 本で済むので、ファイアウォール越えも楽。
名前が紛らわしい理由
「 SFTP = Secure FTP」 と読んでしまうと、「FTP の暗号化版」 のように見える。実際は名前が偶然似ているだけで、土台のプロトコルは別。「SFTP は SSH ベース」 と覚えるのが安全。
どう選ぶか
新規導入なら原則 SFTP。FTPS は 「既存システムが FTPS でしかつながらない」 ような後ろ向きの理由で残る場面が中心。両方を提供しているサーバなら、SFTP を選ぶほうがクライアント側の運用も楽。
「SFTP と FTPS は名前は似ているが別物」 を押さえておけば、現場で混乱することは大きく減ります。
なぜ FTP は使われなくなったか
FTP が現代の本番運用から退場した理由を、技術と運用の両面で整理します。
クラウドが平文を許容しない
AWS / GCP / Azure などのクラウド事業者は、本番経路の暗号化を強く前提にしている。「平文の認証情報を流す前提のプロトコル」 を業務利用するのが、ガバナンス上もそもそも難しい。
代替が完璧に揃った
SFTP / SCP / rsync over SSH に加えて、S3 / R2 / GCS のようなオブジェクトストレージや、CI/CD パイプライン経由のデプロイなど、FTP よりずっと安全で運用しやすい仕組みが揃った。「わざわざ FTP を残す理由」 がほぼなくなった。
FTP のパッシブモードでも 「データ用のランダムポート群を開ける必要がある」 のは変わらず、「22 番 1 本だけ通せば済む SFTP」 と比べると、ネットワーク設計の手間が大きい。
監査・ロギングの弱さ
FTP のサーバ実装はログが薄く、「誰がいつ何を書き換えたか」 を追いにくい。SSH 系はセッションログや syslog 連携が整っているので、コンプライアンス対応でも有利。
ただし、現実には古いレンタルサーバの管理画面でしか提供されていないとか、取引先との EDI が FTP 固定のように、「捨てたくても捨てられない FTP」 はまだ残っています。次の節で、その辺の運用上の判断を整理します。
実務での使い分け
「現場で FTP / SSH / SFTP / SCP のどれを使うか」 を、シチュエーション別に整理します。
| 状況 | 推奨 | 備考 |
|---|---|---|
| 個人開発のレンタルサーバ | SFTP | 主要レンタルサーバはほぼ SFTP 対応。FTP しかないところは乗り換え候補。 |
| クラウド VM (EC2 / Lightsail / さくらの VPS) | SSH + SFTP / rsync | 初期セットアップで FTP サーバを立てる理由はない。22 番だけ開ければ済む。 |
| 静的サイト / SPA のデプロイ | CI/CD + S3 / R2 / Pages | FTP も SFTP も使わない。Git push → CI が公開ストレージに転送する設計。 |
| 取引先との EDI | SFTP (FTPS) の指定があればそれに従う | 新規構築では SFTP を優先。古い案件で FTPS や FTP しか受け付けない先もある。 |
| 社内サーバの保守 | SSH (鍵認証) + SFTP | パスワード認証は無効化し、鍵 + sudo の運用に揃える。「Bastion (踏み台) 経由」 が望ましい。 |
| 非エンジニアが触る納品ファイル置き場 | クラウドストレージ (Google Drive / OneDrive / S3 + 署名 URL) | FTP / SFTP のクライアント設定をしてもらうより、ブラウザベースの方が事故が少ない。 |
「 開発者同士の連携」 と 「非エンジニアを含む業務連携」 は、必要なツールが違うことが多いです。前者は SSH 系で揃えるのが筋、後者はそもそも FTP / SFTP のクライアントを使わせない仕組みを考えるのが現代的です。
自分でサーバを建てるならどう設定するか
新規にサーバを立てる場合の、最低限のセキュリティ設定をまとめておきます。
「SSH を鍵認証で運用、FTP は触らない」 が、現代の標準的なスタートラインです。
AI 時代の運用観
近年は Claude Code のような AI コーディング環境を使って、「サーバに直接 SSH でログインしてコマンドを叩く」 場面が増えています。FTP との関係でも見方を整理しておきます。
AI が SFTP / SSH を前提にする
AI に手順を聞くと、ほぼ確実に SFTP / SSH ベースの回答が返ってくる。FTP を前提にした手順を AI に求めようとしても、「SFTP の方が安全なのでこちらを推奨」 と返されることが多い。
AI に鍵を直接渡さない
「 AI に SSH 秘密鍵をそのまま渡してデプロイさせる」 のは事故の元。秘密鍵は手元の OS のキーチェーンに置き、AI にはコマンドの実行結果や標準出力だけを見せる運用にする。Mini Shai-Hulud 系のサプライチェーン攻撃で 「秘密鍵が盗まれる」 リスクと地続き。
SSH トンネルの活用
AI 補助の開発でも、「本番 DB を直接外に出せないから手元から SSH トンネル経由で見る」 ような場面は多い。「ssh -L 5432:localhost:5432」 のようなトンネルコマンドを AI に書かせる時、「どの環境のどのポートにつなぐか」 を明示してレビューする習慣を持つと事故が減る。
Bastion とゼロトラスト
近年は 「直接 SSH を許す踏み台サーバ」 の代わりに、AWS Systems Manager Session Manager や Tailscale SSH のようなクラウド ID と統合された経路が選ばれることも増えている。「誰が、いつ、どのサーバへ」 がログとして残るので、AI 補助の運用とも相性が良い。
「AI が便利になるほど、根っこのプロトコル理解と鍵管理が大事になる」 のが、SSH まわりを学んでおく実利でもあります。
よくある誤解
最後に、「現場でよく聞く誤解」 をまとめて整理します。
SFTP は FTP の暗号化版だと思っている
名前は似ているが別物。SFTP は SSH の機能の一部で、ポート 22 番 1 本で動く。「FTP + SSL/TLS」 にしたのは FTPS の方。
FTP をパッシブにすれば安全と思っている
パッシブモードはあくまでネットワーク的に通しやすくする工夫であって、平文通信であることは変わらない。盗聴・改ざんの観点では何も改善されない。
SSH = サーバを触る玄人の道具と思っている
レンタルサーバや個人開発でも、「FileZilla / WinSCP / Cyberduck」 のような GUI クライアントで SFTP を使えば、「FTP と同じ操作感で安全に」 をすぐ実現できる。「SSH コマンドを覚えないと使えない」 ものではない。
22 番を変えれば安全と思っている
ポート変更はノイズを減らす効果はあるが、「攻撃が来なくなる」 訳ではない。本質は鍵認証必須 + 強いパスフレーズ + 認証ログ監視。ポート変更だけで満足しない。
「名前が似ているプロトコルが多い領域」 ほど、上のような誤解が広がりやすいので、自分のチームで使うときは言葉の定義を一度揃えるのが安全です。
FTP と SSH の違いに関するよくある質問
Q. FTP のシェル版(任意コマンドを実行できる版)はないんですか?
A. FTP プロトコル自体にシェル機能はありません。ただし歴史的には、FTP と同時代に Telnet という平文の遠隔シェルプロトコルがあり、「シェルは Telnet、ファイル管理は FTP」と役割を分担していました。1995 年に SSH が登場してシェルもファイル転送もトンネルも 1 プロトコルに統合したことで、Telnet と FTP は同時に役目を終えていきました。FTP の拡張に SITE という独自コマンド枠もありますが、これは「サーバが許可した特定の管理操作」だけで、任意コマンド実行はできません。
Q. FTPソフトでサーバの中身が一覧で見えるのは、SSH の ls と同じ仕組みなんですか?
A. 仕組みは違いますが、見える結果はかなり近いです。SSH の ls はサーバ側のシェルが ls コマンドを実行した結果を返すのに対し、FTP の LIST はサーバ側の FTP デーモンが一覧データを返します。クライアント側がそれをツリー UI に整形するので、ユーザー体験としてはほぼ同じに見えるという仕組みです。違いはその先で、FTP では grep や systemctl のような任意コマンドが叩けない、というのが決定的なポイントです。
Q. FTP と SFTP はまったく別のプロトコルですか?
A. はい、別物です。FTP は 1971 年に設計されたファイル管理 + 転送プロトコル、SFTP は 1990 年代後半に SSH のサブシステムとして設計されたプロトコルで、土台がまったく違います。「SFTP は FTP の暗号化版」 という説明は結果としては近い印象を与えますが、技術的には正しくありません。ただし「ファイル管理 + 転送」という用途では両者の射程はほぼ重なっているので、ユーザーが感じる違いは小さい、というのが実情です。
Q. SCP と SFTP のどちらを使えばいいですか?
A. 新規に覚えるなら SFTP か rsync over SSH をお勧めします。SCP は古い設計で、近年 OpenSSH も内部的に SFTP プロトコルを使う実装に切り替えました。コマンドとしての 「scp」 は今も使えますが、差分転送や再開のような実務で欲しい機能は SFTP / rsync の方が充実しています。
Q. FTP を今すぐ捨てられないのですが、暫定で安全にする方法はありますか?
A. FTPS (FTP + SSL/TLS) に切り替える、もしくは社内 VPN や IP 制限の内側でのみ FTP を使う、といった暫定策はあります。ただし、これらは 「平文の認証情報を見られない」 ようにする対症療法で、根本的には SFTP への移行が望ましいです。新規システムで FTP を採用するのは避けるのが現代の流儀です。
Q. SSH に詳しくないのですが、FileZilla で SFTP に切り替えても同じ感覚で使えますか?
A. ほぼ同じ感覚で使えます。FileZilla の接続設定で 「プロトコル」 を 「SFTP - SSH File Transfer Protocol」 に変えるだけで、UI 上の操作は FTP のときとほとんど変わりません。ポート番号がデフォルトで 22 に変わる点と、初回接続でホスト鍵の確認ダイアログが出る点だけ覚えておけば、ユーザー体験はほぼ FTP と同じです。
Q. 公開鍵認証とパスワード認証、どちらを使うべきですか?
A. 本番運用では公開鍵認証を推奨します。パスワードは総当たり攻撃で破られるリスクがあり、サーバごとに違うパスワードを管理する負担も大きい。公開鍵認証ならサーバ側に置くのは公開鍵だけで、秘密鍵は手元のキーチェーンや 1Password などに保管できます。「fail2ban で守るからパスワードでいい」 という判断もありますが、現代では鍵認証を基本にする方が運用も楽です。
Q. SSH で繋いだ後にファイル転送だけしたい場合は?
A. その場合は SFTP か SCP、もしくは rsync over SSH を使います。SSH でログインした状態で対話的にファイルを動かす場合は 「mv」 や 「cp」 でサーバ内のファイルを動かす、「cat > file」 で短いファイルを書く、「curl」 や 「wget」 で URL から取ってくる、なども選択肢です。手元の PC のファイルをサーバへ送るなら SFTP / SCP / rsync が中心になります。
Q. AI コーディング環境から SSH 接続を任せる時の注意点は?
A. 秘密鍵を直接 AI に渡さないこと、「どのサーバの何を変更するのか」 をプロンプト側で明示すること、本番環境ではドライランや確認プロンプトを挟む設計にすることが重要です。AI が即座にコマンドを実行できる環境ほど、「間違ったホストに rm -rf を撃つ」 のような事故のリスクが高くなります。エラーコードの読み方 や IAM の最小権限設計 と合わせて、安全策をいくつも重ねるのが現実的です。