AIが作成したバックアップスクリプトで作成しておいたバックアップの .tar.gz ファイルを、一般ユーザーのホームディレクトリ配下で普通に解凍しました。
Bash
$ cd /home/username
$ sudo tar -xzf backup.tar.gz
「よし、解凍終わったな」と思って一度ログアウトし、後で再びSSHでログインしようとすると……。
「Permission denied (publickey).」
「えっ、さっきまで普通にログインできていたのに、鍵が弾かれる！？」と冷や汗を流すことになります。実はこのトラブル、OSのバグやネットワークの不調ではなく、先ほど実行した tar コマンドの挙動に原因があります。
顧客常駐はもう嫌だ！社内SEへ転職するなら【社内SE転職ナビ】
Cursor・Claude Code・Codex AIスキルを学ぶなら
環境構築不要！AIエージェント開発を非エンジニアでも即実践【AI Agent Camp】
🚨 原因：tar内に含まれていた「./」の仕業
結論から言うと、原因は「アーカイブ（tar.gz）作成時に ./ を含めてしまっていたこと」、構成によってはそれをsudo（root権限）で解凍してしまったことです。
恐怖のメカニズム
-
アーカイブ作成時のミス： 過去にバックアップを作成した際、対象のディレクトリ内で
tar -czf backup.tar.gz ./のように、「カレントディレクトリ（./）」を指定して固めてしまっていたとします。このとき、アーカイブ内には「その当時の./の所有者やパーミッション情報（例：root:root）」が丸ごと記録されます。 -
sudoをつけた解凍： このファイルを、新サーバーや別ユーザーのホームディレクトリ（/home/username）の中でsudo tar -xzfして展開します。sudo（root権限）で解凍を行うと、tarコマンドは「アーカイブ内に記録されている所有者やパーミッションを忠実に再現（上書き）」しようとします。 -
カレントディレクトリの権限が乗っ取られる： 展開先における「
./」とは、今まさに作業している/home/username自体を指します。 その結果、本来username:username（700または755）であるべきユーザーのホームディレクトリ権限が、tarの中にあった情報によってroot:root（700）などへ強制的に書き換えられてしまうのです。
なぜSSHログインができなくなるのか？
LinuxのOpenSSH（SSHデーモン）には、非常に厳格なセキュリティチェック機能が備わっています。 ユーザーのホームディレクトリ（/home/username）や、その中にある .ssh フォルダ、authorized_keys の所有者が本人以外（rootなど）になっていたり、権限が不適切に変更されたりしていると、安全性の観点からSSH側が鍵認証を完全に拒否するようになります。
これが、解凍した瞬間にサーバーから締め出されてしまう「ログイン不能トラブル」の正体です。
🛠️ 万が一、締め出されてしまった時の復旧方法
すでにログアウトしてしまい、完全に締め出されてしまった場合は、以下のいずれかの方法で権限の再修正を試みる必要があります。
1. まだセッション（接続）が残っている場合
もし別のターミナルなどでまだ接続が維持されているウィンドウがあれば、大至急以下のコマンドで所有者と権限を元に戻してください。
Bash
$ sudo chown -R username:username /home/username
$ sudo chmod 700 /home/username
2. 完全に締め出された場合
-
クラウド環境（AWSやGCPなど）の場合： 対象インスタンスを一度停止し、ルートボリューム（ディスク）を別の正常な作業用インスタンスにマウントして、外部から
/home/usernameの所有者（chown）と権限（chmod）を修正します。 -
物理サーバーや仮想化環境（VMware/Hyper-Vなど）の場合： コンソール（またはレスキューモード）からrootユーザーで直接ログインし、該当ユーザーのホームディレクトリ権限を修復します。
💡 二度とこの悲劇を起こさないための「予防策」
今後の運用で同じ罠に引っかからないために、以下の2つのルールを徹底しましょう。
対策1：tarを作るときは「パス直指定」か「フォルダごと」固める
アーカイブを作成する際は、./ を使うのをやめ、一つ上の階層からフォルダ名で指定するか、特定ファイルだけを指定するようにします。
Bash
# ❌ やりがちだけど危険（./ の情報が入る）
$ cd myapp && tar -czf backup.tar.gz ./
# ⭕ 安全（フォルダそのものを固める）
$ cd .. && tar -czf backup.tar.gz myapp/
対策2：解凍時に所有者情報を強制上書きさせない
もし素性の分からない（./ が入っているかもしれない）tar.gzファイルをroot権限で解凍せざるを得ない場合は、元のパーミッションや所有者を強制適用させないオプションを付与します。
Bash
$ sudo tar --no-same-owner -xzf backup.tar.gz
これをつけておけば、アーカイブ内の所有者情報を無視し、解凍を実行したユーザー（root）の権限でファイルが展開されるため、既存のホームディレクトリの所有権が上書きされるリスクを回避できます。
📝 まとめ
「カレントディレクトリを丸ごとバックアップしたくて ./ で固める」という行為は一見手軽ですが、復元時に展開先の作業場所（ホームディレクトリなど）の権限を破壊する地雷に変貌する危険を孕んでいます。
特に sudo や root ユーザーでのアーカイブ操作時は、中の「隠れた ./」の存在に十分注意を払い、安全なオプションや適切な階層での作業を心がけましょう！AIさんも事後調査でこのことに気づいてはくれたのですが、、、怖いですね。
