Windows PC上のファイルをLinuxサーバーへ一時的に転送するなら、Tera TermでSSH接続した後、「ファイル > SSH SCP」から送信できます。画面操作は簡単ですが、接続先の取り違え、SSHホスト鍵警告の無視、rootでの直接配置、既存ファイルの上書き、文字化けを放置したままの本番反映は危険です。本記事では、Tera Term 5の公式マニュアルに沿ったSCP送信手順に、送信前のパス・容量・権限確認、SHA-256照合、文字コード、トラブル対応、最小権限の本番反映を加えて解説します。
Tera Termは公式配布の現行安定版を使う
Tera Termは端末エミュレーターで、TTSSHモジュールを含む構成ではSSH接続とSSH SCPによるファイル転送を利用できます。入手する場合はTeraTerm Projectの公式ホームページから安定版のリリースページへ進み、組織のソフトウェア配布・署名確認・脆弱性管理に従います。検索広告や非公式の再配布サイトから実行ファイルを取得しません。既に管理配布されている場合は勝手に別版へ置き換えず、サポート担当へ確認します。
SCP転送には、Linux側でSSH接続が許可され、対象ユーザーがログインでき、送信先ディレクトリへ書き込み権限を持つことが必要です。ファイルを送る権限と、本番設定・実行ファイルを配置する権限は分けます。rootのSSHログインや共有管理者アカウントを使わず、個人を識別できる最小権限アカウントと専用のステージングディレクトリを使います。転送対象、接続先、変更申請、所有者、保持期限を事前に記録します。
送信前にファイルの出所・内容・SHA-256を記録する
ローカルPCでは、承認された正しい版のファイルか、秘密鍵、パスワード、トークン、個人情報、不要なデバッグ情報が混入していないかを確認し、組織のマルウェアスキャンを通します。ファイル名には版やチケット番号を含めると取り違えを減らせますが、空白、制御文字、シェルで特別な意味を持つ記号は避け、英数字・ハイフン・アンダースコアを基本にします。Linuxでは大文字と小文字が区別される点にも注意します。
送信前のSHA-256をPowerShellのGet-FileHashで記録します。-LiteralPathは角括弧などをワイルドカードとして解釈せず、入力したパスをそのまま扱います。MD5やSHA-1ではなくSHA-256を明示し、ファイル名、サイズ、更新日時、ハッシュ、承認者を変更記録へ残します。ハッシュは完全性を確認しますが、ファイル自体が安全・正規であることを証明するデジタル署名の代替ではありません。
Get-FileHash -LiteralPath 'C:\Users\user1\Documents\Upload_Test_File.txt' -Algorithm SHA256Linux側はステージング先・空き容量・権限を先に確認する
SSHログイン後にid、pwdでユーザーと現在位置を確認し、送信先は/home/uploaduser/incomingのような明示的なステージングディレクトリにします。ls -ldで所有者と権限、df -hで対象ファイルシステムの空き容量を確認します。FSRMのようなWindows機能ではなくLinux側のクォータがある環境では、ファイルシステム全体に空きがあってもユーザー上限で失敗するため、運用担当へ確認します。
/etc、/usr/local/bin、Web公開ディレクトリ、アプリケーションの本番設定パスへTera Termから直接送らないでください。直接配置すると、転送途中のファイルをサービスが読み込んだり、既存版を上書きしたり、所有者が不適切になったりします。書き込み可能なステージングへ一意な仮名で送り、ハッシュ・内容・所有者を確認した後、サーバー担当者が承認済みのデプロイ手順で本番へ昇格します。
id
pwd
ls -ld -- /home/uploaduser/incoming
df -h -- /home/uploaduser/incomingSSH接続時はホスト名とホスト鍵指紋を照合する
Tera Termを起動し、承認されたFQDNまたはホスト名、ポート、SSHを選んで接続します。IPアドレスを手入力すると更改や負荷分散で別サーバーを指す可能性があるため、運用台帳の接続名を使います。認証は組織の方式に従い、可能ならパスフレーズ付き公開鍵または管理された認証エージェントを使います。パスワード、秘密鍵、パスフレーズをマクロ、ショートカット引数、ログへ保存しません。
初回接続またはサーバー鍵の変更時にSecurity Warningが出たら、画面の指紋をサーバー管理者が別の信頼できる経路で提示した指紋と比較します。Tera Term公式マニュアルも、警告時は信頼済み指紋と照合するよう求めています。再構築や鍵更新の予定がないのに不一致なら、なりすまし、DNS誤り、接続先取り違えの可能性があるため中止します。「今後表示しない」ためだけに未知の鍵を登録しません。
ファイルメニューのSSH SCPからSendを実行する
LinuxへSSHログインできた状態で、Tera Termのメニューから「ファイル」を開き、「SSH SCP」を選択します。通常の「ファイル送信」は端末へ内容を流す別機能なので、SCP転送では必ずSSH SCPを選びます。ダイアログのSend欄で、FromにWindows上の送信元ファイルを選択し、TOにLinux側の送信先パスを入力します。ファイル名、サイズ、接続先ウィンドウのタイトル、ログインユーザーをもう一度照合してからSendを押します。
TOには/home/uploaduser/incoming/Upload_Test_File.20260715.txtのような絶対パスとファイル名を明示すると、現在ディレクトリの誤解を減らせます。Tera Term公式マニュアルでは、TOが空ならホームディレクトリとして扱われ、リモートOSやシェルによっては~が使えない場合があると説明しています。空欄や~/へ依存せず、実在と権限を確認した絶対パスを使います。
同名ファイルがある場合は送信前に止まって確認する
送信先に同名ファイルが存在するか、ls -lやstatで先に確認します。送信側UIが必ず安全な上書き確認を出すと期待せず、同名があればデータ所有者と配置手順を確認します。既存ファイルを端末上で直接編集・置換せず、チケット番号やタイムスタンプを付けた新しいステージング名へ送ります。本番へ昇格する時は、アプリ停止、設定検証、バックアップ、原子的な切り替え、ロールバックなど製品ごとの手順に従います。
転送が途中で切れた場合、送信先に不完全なファイルが残る可能性を前提にします。同じ本番名で何度も再送せず、ステージング上のサイズとハッシュを確認し、未完了ファイルを本番処理が読まない名前で管理します。削除権限がない利用者が無理に消そうとせず、サーバー担当者へ対象の完全パスと送信時刻を伝えます。ワイルドカードでステージング全体を削除する対応は避けます。
Linux側でもサイズとSHA-256を照合する
送信完了表示だけで成功とせず、Linux側でstatによりサイズ、所有者、グループ、権限を確認し、sha256sumでSHA-256を計算します。WindowsのGet-FileHash結果と大文字小文字を無視して同じ値なら、転送前後のバイト列が一致します。GNU Coreutilsのsha256sumはSHA-256チェックサムを計算・検証するコマンドです。結果をチケットへ記録し、照合前のファイルを実行・展開・サービスへ読み込ませません。
ハッシュが異なる場合は、誤った送信元、古い同名ファイル、転送中断、送信後の変更を疑います。異なる値を「文字コードの違いだろう」と無視しません。Windows側の同じファイルを再計算し、Linuxの完全パスとサイズを再確認し、別の一意なステージング名へ再送して比較します。機密ファイルの中身をチャットや公開チケットへ貼り付けず、ハッシュと最小限のメタデータで調査します。
stat --format='%n %s bytes owner=%U group=%G mode=%a' -- /home/uploaduser/incoming/Upload_Test_File.20260715.txt
sha256sum -- /home/uploaduser/incoming/Upload_Test_File.20260715.txt内容確認は読み取り専用で、秘密情報を画面へ出さない
テキストの内容を確認する時に、旧記事のように最初からviで開くと、誤操作で変更・保存する可能性があります。機密でないテストファイルならheadやlessで読み取り、構成ファイルなら製品固有の構文チェックをステージング上で実行します。バイナリやアーカイブは、対応する署名、一覧表示、テストモードを使い、展開や実行は承認後に隔離された場所で行います。
秘密鍵、証明書の秘密部分、トークン、顧客データはターミナル画面や操作ログへ表示しません。Tera Termのログを有効にする場合は、ホスト、コマンド、パス、表示内容が保存されることを踏まえ、暗号化された管理領域と保持期限を設けます。SSHのデバッグダンプを常時有効にせず、必要な障害調査だけで一時利用し、終了後に保護・削除方針へ従います。
head -n 20 -- /home/uploaduser/incoming/Upload_Test_File.20260715.txt日本語の文字化けはSCPではなく表示・文字コードを調べる
SCPはファイルのバイト列を転送し、通常はテキストの文字コードや改行コードを自動変換しません。SHA-256が一致しているのに日本語が文字化けするなら、転送破損ではなく、元ファイルがShift_JIS／UTF-8／UTF-16のどれか、BOMの有無、Linux側のロケール、表示ツールの解釈を確認します。旧記事の「文字化けしたがアップロード成功」で終わらせず、利用するアプリケーションが要求する形式まで検証します。
WindowsのCRLFとLinuxのLFも、シェルスクリプトや設定パーサーの動作へ影響します。変換が必要なら元ファイルのバックアップを保持し、ステージング上のコピーへ承認済みツールで変換し、変換後はハッシュが変わることを記録して構文テストをやり直します。文字化けを直すために、サーバーのシステムロケールや全体設定をその場で変更しません。
Permission deniedなどのエラーを権限緩和でごまかさない
Permission deniedなら、ログインユーザー、TOの完全パス、親ディレクトリの実行権限と書き込み権限、読み取り専用マウント、ディスククォータ、SELinux／AppArmorの監査ログを確認します。解決のためにchmod 777、rootログイン、SELinux無効化、所有者の一括変更を行いません。ステージングディレクトリの所有者とグループをサーバー担当者が最小権限で設計します。
No such file or directoryなら、Linuxの大文字小文字、親ディレクトリの存在、絶対パス、Tera Termで~を使っていないかを確認します。容量エラーならdf -hとクォータ、接続切断ならSSHログ、ネットワーク、サーバー負荷を調べます。ホスト鍵不一致を接続エラーとして登録し直すのではなく、鍵変更の正当性を別経路で確認します。
実行権限と本番配置は転送後の別工程にする
SCPで送っただけでは、ファイルの所有者、グループ、モード、SELinuxコンテキスト、サービスからの参照可否が本番要件を満たすとは限りません。スクリプトに実行権限が必要でも、内容・署名・所有者を確認する前に付与しません。サーバー担当者が製品手順に従い、最小の所有者・グループ・モードを設定します。既存構成を置き換える場合は、構文テスト、差分レビュー、バックアップ、ロールバック、サービスのヘルスチェックを行います。
転送用アカウントには本番ディレクトリへの直接書き込み権限を与えず、ステージングからの昇格を承認者または構成管理ツールに限定すると、誤操作と不正変更を減らせます。転送完了、ハッシュ一致、レビュー、昇格、稼働確認、ステージングの期限付き整理を別の状態として記録します。「Tera Termの進捗が100%」だけで変更チケットを完了にしません。
大量・定期転送はGUI操作から管理された自動化へ切り替える
Tera TermのSSH SCP画面は、管理者が単一または少数ファイルを対話的に転送する用途に向きます。大量のディレクトリ、定期バッチ、再開が必要な大容量ファイル、複数サーバー展開では、SFTP、OpenSSH、rsync、構成管理、CI/CDなど組織で承認された仕組みを選び、ホスト鍵検証、秘密管理、チェックサム、再試行、帯域制御、監査、ロールバックを自動化します。
Tera Termマクロへユーザー名・パスワード・秘密鍵パスを埋め込んで自動化しません。自動化では非対話だからこそ、未知または変更されたホスト鍵を拒否し、対象ホストとパスを許可リスト化し、同時実行数と失敗停止条件を設定します。LinuxからWindowsへ逆方向に取得する一回限りの操作は、Tera TermでLinuxのファイルをローカルへダウンロードする方法も参照できます。
確認チェックリスト
- Tera Termを公式配布の管理された版から利用した
- 接続先FQDN、ユーザー、SSHホスト鍵指紋を信頼済み情報と照合した
- 送信前にファイルの出所、機密情報、マルウェア、SHA-256を確認した
- TOへ実在するステージングの絶対パスと一意なファイル名を指定した
- 既存同名ファイル、空き容量、クォータ、所有者・権限を送信前に確認した
- Linux側のサイズとsha256sumをWindowsのGet-FileHashと照合した
- 文字化けを放置せず、文字コード・改行・アプリ構文を検証した
- root、chmod 777、SELinux無効化、秘密情報入りマクロを使わなかった
- 本番昇格、ヘルスチェック、ロールバック、ステージング整理を別工程にした
Tera Termでのアップロードは、SSH接続後に「ファイル > SSH SCP」を開き、SendのFromへWindowsファイル、TOへLinuxの明示的な絶対パスを指定します。TOが空ならホーム扱いとなり、~は環境によって使えないため、専用ステージングの完全パスを使うのが確実です。送信前に接続先とホスト鍵、容量、権限、既存ファイル、Windows側SHA-256を確認し、送信後はLinuxのstatとsha256sumで一致を証明します。文字化けは転送成功と別問題です。文字コード・改行・構文を検証し、最小権限の承認済み手順で本番へ昇格してください。
コメント