このブログの最初の方で書いていた、業務サーバー構築ログの続きです。
前回の、Xserver VPS 初期構築ログ|Ubuntu 24.04 LTSで最初にやった設定 では、
- 一般ユーザー作成
- SSH の基本設定
- root ログイン制限
- 最低限のセキュリティ対策
までをまとめました。
今回はその流れで、「ファイル転送をどうするか」という、実運用では避けて通れない部分について書きます。
VPS を立てたあと、必ず発生するのが、
- ファイルアップロード
- データ移行
- バックアップの受け渡し
といった作業です。
最初は何となく FTP(vsftpd)を入れたのですが、実運用を考えると違和感が積み重なり、最終的に SFTP(SSH)一本化 に切り替えました。
その経緯と判断理由を、実体験ベースで整理しておきます。
FTP と SFTP の違いを整理する
FTP が今あまり使われない理由
FTP(File Transfer Protocol)は昔からある仕組みですが、
- 通信が暗号化されない
- ID / パスワードが平文で流れる
- ポート管理が煩雑
といった問題があります。
FTPS にすれば暗号化はできますが、
- 証明書管理
- Passive モード用ポート設計
- FW 側の穴あけ
- クライアント設定の説明
など、運用負荷が一気に上がります。
インターネット直結の VPS では、正直 積極的に選ぶ理由があまりありません。
SFTP は SSH の機能の一部
SFTP は、
- SSH 上で動作
- 通信はすべて暗号化
- 追加の FTP サーバー不要
という構成です。
Ubuntu 24.04 では OpenSSH が標準で入っているため、
SSH が使える = SFTP も使える
というシンプルさがあります。
構成が単純になる、というのは、ひとり情シス環境ではかなり大きなメリットです。
なぜ vsftpd をやめたのか(実体験)
一度は vsftpd を構築した
今回の環境でも、最初は
- vsftpd のインストール
- chroot 設定
- ユーザー制限
- Active / Passive モード調整
まで一通りやりました。
検証レベルでは問題なく動きます。
ただ、実運用をイメージしたときに、引っかかる点がいくつも出てきました。
実運用で感じた違和感
特に大きかったのはこのあたりです。
- パッシブモード用ポート設計が面倒
- 社内ルーター側の設定が必要
- 設定ミス時の影響範囲が大きい
Active モードは逆セッションになるため、社内ネットワークとの相性が悪く、現実的ではありません。
結果として、
「FTPのためだけにネットワーク設計を歪めるのは違うな」
と感じるようになりました。
結論:SFTP(OpenSSH)だけで十分
最終的に、
- ポートは 22 のみ
- 設定ファイルは sshd_config だけ
- セキュリティ設計がシンプル
という理由から、vsftpd は完全に廃止し、SFTP 一本化 にしました。
構成が単純になることで、
- トラブル要因が減る
- 運用説明が楽
- 保守が軽くなる
というメリットも一気に得られました。
SFTP はどのように動いているのか
SFTP は、以下の仕組みで動いています。
- sshd(SSH デーモン)
- Subsystem sftp
- internal-sftp
設定はすべて /etc/ssh/sshd_config に集約されます。
FTP サーバーのように、別デーモンを立てる必要がありません。
SFTP 用ユーザー設計の考え方
避けたい危険な構成
初心者がやりがちですが、以下はおすすめしません。
- root で SFTP ログイン
- サーバー全体が見える
- SSH シェルも利用可能
事故が起きた際の影響が非常に大きくなります。
今回採用した設計方針
- SFTP 専用ユーザーを作成
- 操作できるディレクトリを限定
- SSH シェルは使わせない
という構成にしています。
SFTP ユーザー作成とディレクトリ準備
例として、一般的な名前で説明します。
adduser sftpuser
アップロード用ディレクトリを作成します。
mkdir -p /data/sftp
chown root:root /data
chmod 755 /data
chmod 755 /data/sftp
注意点ChrootDirectory に指定するディレクトリは
root 所有かつ書き込み不可 が必須条件です。
ここを間違えると、ログインできずにハマります。
sshd_config の設定(SFTP の核心)
vi /etc/ssh/sshd_config
末尾に追記します。
# SFTP を internal-sftp で動かす
Subsystem sftp internal-sftp
# 移行・検証フェーズ向け設定
# ※ IP 制限と併用する前提
PasswordAuthentication yes
# SFTP 専用ユーザー設定
Match User sftpuser
ForceCommand internal-sftp
ChrootDirectory /data
AllowTcpForwarding no
X11Forwarding no
反映します。
systemctl restart ssh
なぜ PasswordAuthentication yes にしているのか
前回の記事では、
PasswordAuthentication no
を推奨しました。
これは インターネット公開サーバーでは鍵認証のみが原則 だからです。
では、なぜ今回は yes にしているのか。
理由は 構築・移行フェーズを重視しているため です。
- 初期構築直後
- ファイル移行・検証作業が中心
- FileZilla など GUI クライアント利用
- IP 制限と併用
という前提では、パスワード認証を許可した方が、作業効率が圧倒的に上がります。
本番運用では、
- 接続元 IP を固定
- VPS 側 FW 制限
- 鍵認証のみ
など、段階的にセキュリティを引き上げています。
本番運用時の選択肢(環境に応じて)
運用が安定してきた段階では、以下の選択肢があります。
- SSH 鍵認証のみ
- VPN 経由限定 + パスワード認証
- 固定 IP 制限 + 強固なパスワード運用
どれが正解というわけではなく、
運用環境・管理人数・リスク許容度で決める
というのが、実務的な判断基準だと思っています。
よくあるハマりポイント
- ChrootDirectory の所有者が root 以外
- パーミッションが緩すぎる
- sshd_config の書式ミス
この3点は、ほぼ確実に一度は踏みます。
自分も踏みました。
VPS 選定について(少しだけ)
今回の構成は Xserver VPS を使って検証・運用しています。
SSH のレスポンスが安定しており、初期状態がシンプルなので、
- 構築 → 検証 → 本番移行
- IP 制限前提の段階運用
- 社内20人程度の SFTP 利用
といった流れでも、特に詰まることなく運用できています。
SFTP / SSH 運用を前提に VPS を選ぶなら、CPU とメモリ、ディスク容量に余裕を持たせた構成が楽、というのが実感です。
自分が使っている環境も、そういう観点で Xserver VPS を選びました。
まとめ
今回の結論をまとめると、
- FTP は使わなくていい
- SFTP は SSH の延長
- vsftpd は構成が複雑になりがち
- PasswordAuthentication yes は「限定的・意図的」
- OpenSSH だけで安全に運用可能
という判断になりました。
「慣れているから」「今までそうしていたから」で構成を決めると、
ひとり情シス環境では、あとから運用負荷として跳ね返ってきます。
構成を減らすことが、最大の安定化策。
今回の SFTP 切り替えは、その象徴的な判断でした。
この環境の全体構成まとめ

次の記事



