何年もスクリプトで動いていた scp コマンドが、現在のクライアントではトンネルとは無関係なパスエラーで失敗することがあります。VPN はバイトを運びましたが、クライアントはサーバーが解決できない名前を要求しました。現在の OpenSSH の scp は既定で SFTP 経由で転送し、SFTP は旧プロトコルのようなシェル形式の展開を行いません。コマンドを自分のアカウントから外側へたどると、パスが実際にどこで解釈されるかが見えてきます。

アカウントから始め、次に書き込めるディレクトリを確認する

コロンは二つの名前空間を分けており、左側だけが入力中のマシンに属します。それ以降はすべてサーバーが、認証したアカウントの下で、そのアカウントが持つファイルシステムの見え方の内側で解決します。コマンドを組み立てる前に両方を確認してください。管理者にとって正しいパスが、転送ユーザーにとっても自動的に正しいとは限りません。この違いが、ネットワーク障害に見える権限エラーのほとんどの原因です。

サーバー自身の見え方を尋ねます: ssh [email protected] pwd と ssh [email protected] ls -ld /srv/archive。二番目のコマンドが権限拒否を報告するなら、トンネルは正常で、そのアカウントにはそのパスを使えません。転送を進めるために権限を広げるのではなく、所有権を直すか別の宛先を選んでください。

制限された SFTP 設定では、chroot をファイルシステムのルートとして見せることがあります。その見え方の内側では、絶対パスは chroot 内での絶対パスであり、管理者がホスト上で見る場所とは同じではありません。

コロンの両側を明示的に指定する

アップロードでは、ローカルのベース名が相手側で受け入れられると仮定せず、リモートのファイル名を指定すべきです。

scp q3-invoice.csv [email protected]:/home/transfer/drop/q3-invoice.csv

ダウンロードでも、まったく同じ理由でローカルの宛先を指定すべきです。二つの名前空間は独立しており、一致すると仮定するスクリプトは、リモートのツリーが別の配置を使った最初の時点で壊れます。

scp [email protected]:/srv/archive/2026-q3.csv ./2026-q3.csv

保守しているスクリプトでは ~otheruser を避けてください。他のアカウントのホームディレクトリを展開するのはリモートシェルの機能であり、SFTP サーバーがそれを模倣する拡張を実装していない場合があります。アカウントが実際に開ける絶対パスを書き、空白を含むローカルパスは、サーバー上のシェル向けに書かれた引用符の層をコピーするのではなく、引用符で囲んでください。

自分の scp が実際に使うプロトコルを知る

OpenSSH 9.0 以降、クライアントは既定で SFTP を使い、ディストリビューションはそれぞれの予定でその動作を採用したりバックポートしたりします。バージョン文字列はクライアントの意図を示しますが、ベンダーのビルドは上流と異なることがあるため、実際に実行しているクライアントを確認してください: ssh -V。

二つのプロトコルは名前の解決方法が異なります。旧 SCP はリモートのユーザーシェルにパスの展開を頼むため、ワイルドカードやチルダはそのシェルが独自の規則で処理します。SFTP は代わりにファイル転送操作を発行するため、ワイルドカードはクライアントが展開するか、まったく展開されないかのどちらかです。どちらも SSH の内側で同じマシンへ向かうので、同じホストでも二つのクライアントで挙動が変わります。

scp -v は要求するサブシステムを出力し、sftp のサブシステム行があれば現代的なパスが使われていると確認できます。scp -O は対応していて本当に必要な場面で旧プロトコルを強制し、独自の引用規則も一緒に持ち込みます。VPN のオプションではなく、サーバー上で何かを有効にする方法でもなく、ホスト鍵の確認を緩める理由にもなりません。

スクリプトが依存する前にパスを試す

パスの問題は最悪のタイミング、つまり誰も見ていない夜間の自動処理で表面化します。まず小さなファイルと、その処理が使う正確なアカウントで宛先を証明し、そのテストコマンドを処理の定義のそばに置いてください。テストに別のアカウントや別のディレクトリが必要なら、処理にも必要になります。

サーバー側も確認してください。grep -i subsystem /etc/ssh/sshd_config は SFTP サブシステムが設定されているかを示し、sftp -b /dev/null [email protected] はそのサブシステムが応答したときだけ成功して終了します。SSH ログインは受け付けるがサブシステムがないホストは、ログインテストでは完全に健全に見えても、現代的な転送はすべて失敗します。

クライアントのバージョン、使用中のプロトコル、絶対リモートパスを処理のメモに記録してください。次のアップグレードが既定値を変えたとき、そのメモが五分の修正と午後いっぱいの推測の差になります。

関連記事