📚 連載：Ansibleが理解できない理由はLinuxにあった【OS編】第3回：AnsibleのSSH接続が失敗すると UNREACHABLE エラーになる。（Connection refused / Permission denied / Timeout など）

Linuxの仕組みからAnsibleを理解するシリーズです。

0️⃣ Ansibleの仕組み
1️⃣ Linuxの構造（Kernel / Shell / Filesystem）
2️⃣ command not foundの原因：PATH
3️⃣ SSH接続できない理由：鍵認証とポート
4️⃣ Permission deniedの原因：ユーザーと権限
5️⃣ サービスが起動しない理由：systemd
6️⃣ cronが動かない理由：PATH問題
7️⃣ ディスク満杯になる理由
8️⃣ サーバーが遅くなる理由

🗺️ 初めての方・シリーズの全体像を知りたい方はこちら

本記事は、OSの仕組みからAnsible設計までを繋ぐ連載シリーズの一部です。
「どこから読み始めればいいか」あるいは、「OS/Shell/Ansible編の関係性」 について把握されたい場合は、以下の統合ガイドで整理しています。

→ Ansibleが理解できない理由はLinuxにあった｜統合ガイド

📑 【OS編】全体のまとめはこちら

→ Ansibleが理解できない理由はLinuxにあった【OS編】まとめ

📑 連載の移動
前の記事：【OS編】第2回｜次の記事：【OS編】第4回

シリーズ全体構造（学習 × 問題解決）

本シリーズは
「理解（各記事）」と「問題解決（逆引き辞典）」を組み合わせて
スキルを身につける構成になっています。

この図は、どこから学び、どこに進めばよいかを示した“ロードマップ”です。

📍 現在の位置

現在はこの図の「OS編第3回」になります

📍 はじめに：この記事のスタンス

インフラ構築をしていると、こんな「矛盾」に遭遇することがありませんか？

「手動のSSHならログインできるのに、Ansibleだと失敗する…」
「鍵も設定も合っているはずなのに、なぜか UNREACHABLE になる」
「エラーメッセージが出ても、原因が全く分からない」あるいは「何を直せばいいのか分からず、調査が止まる」

⚠️ 注意事項

この記事は、SSHのプロトコルや公開鍵暗号の数学的仕組みを体系的に解説する「教科書」ではありません。

目的はただひとつです。

Ansibleで UNREACHABLEが出たとき、どこを見れば原因が分かるのかを理解することです。

「SSH単体なら繋がるのに、Ansibleだとダメになる理由」

この実務でハマるポイントに絞って、Linuxの仕組み（sshdや認証のルール）とAnsibleの挙動を紐解いていきます。

📍 Ansibleの通信トラブルは「4つの原因」に分解できる

AnsibleのUNREACHABLEは、次の4つのどこかで止まっています。

ネットワーク（到達していない）
SSHサービス（sshd / ポート）
認証（鍵・パスワード）
接続定義（inventory.iniの誤り）

この4つに分けて考えるだけで、原因は一気に絞れます

💡 ポイント

UNREACHABLEは「4つの原因」に必ず分類できる

この後の章では、この4つを順番に分解していきます。

📋 目次

前回の振り返り（第2回）
逆引き辞典との連動
SSHとは何か：リモート操作の「土台」
SSH接続の仕組み：待ち受ける「sshd」
UNREACHABLEの正体：まずログで4パターンに分類する（フレーム＋実行ログ＋判断設計）
ネットワーク：Timeout（応答なし）
SSHサービス：Connection refused（拒絶）
認証（Permission denied：本人確認失敗）
接続定義ミス（inventory.iniの誤り）
鍵認証の仕組みと権限管理（Permission denied の背景）
実務における典型的な接続エラーと対策
まとめ：原因の見え方が変わる「調査の原則」
次回予告：Permission deniedの正体
連載一覧：Ansibleが理解できない理由はLinuxにあった

1. 前回の振り返り（第2回）

前回の記事では command not found の原因（PATH）を解説しました。
Linuxコマンドが実行される裏側には、Shellによる「PATHの探索」というルールがありました。

また、Ansibleの処理は次のレイヤー構造で動いています。

Ansible
↓
SSH（← 今回のテーマ）
↓
Shell
↓
Linux

つまりAnsibleは、SSHを経由してリモートホスト上でShellを実行する仕組みです。

ただし、UNREACHABLEは必ずしも「SSH接続の中」だけで発生するわけではありません。

ネットワーク・SSHサービス・認証・接続定義（inventory.ini）など、
SSHに至るまでのどこかの段階で問題が発生すると、Playbookの実行はそこで停止します。

今回は、この「どの段階で失敗しているのか」を切り分けるための考え方を解説します。

↑ 目次に戻る

2. 逆引き辞典との連動

具体的なエラー名から原因を特定したい場合は、以下の逆引き辞典を活用してください。

Ansibleが理解できない理由はLinuxにあった：【保存版】Ansibleトラブル逆引き辞典｜エラー別の原因と解決フローまとめ

まず「逆引き辞典」で該当ステップを特定する
次に「本編（各連載記事）」で仕組みを理解する

↑ 目次に戻る

3. SSHとは何か：リモート操作の「土台」

SSH（Secure Shell）は、ネットワーク越しにLinuxサーバーを操作するための仕組みです。

Ansibleは、このSSHを使ってリモートホスト上でコマンドを実行しています。

ローカルPC
↓
SSH通信
↓
リモートサーバー
↓
Shellを起動してコマンド実行

ここで重要なのは、
AnsibleはSSH経由でコマンドを実行しているという点です。

つまり、SSHが失敗すればAnsibleも失敗します。
このあと解説するUNREACHABLEは、
この通信のどの段階で失敗しているかによって4つに分類できます。

↑ 目次に戻る

4. SSH接続の仕組み：待ち受ける「sshd」

SSH接続では、サーバー側で sshd（SSH Daemon）が接続を待ち受けています。

sshd：外部からのSSH接続を受け付けるプロセス

ここで押さえるポイントは一つです。
sshdが動いていなければ、SSHは接続できません。

その結果として発生するのが、次のエラーです。

Connection refused

これは、

ネットワーク → OK
sshd → NG（起動していない or ポート違い）

という状態です。

このエラー（Connection refused）は、第5章の分類の中の1つです。
具体的な調査方法は、第7章で詳しく解説します。

↑ 目次に戻る

5. UNREACHABLEの正体：まずログで4パターンに分類する（フレーム＋実行ログ＋判断設計）

Ansibleで UNREACHABLE が発生した場合、
設定ファイルをすぐ修正するのは非効率です。

最初にやることはシンプルです。

まず、ログを確認します。

そして「どの段階で失敗しているか」を切り分けます。

🔍 UNREACHABLEの全体構造（判断フロー）

① Ansible実行ログ（最優先）

コマンド実行時の出力が最も重要です。

ansible -i inventory.ini all -m ping -vvvv

まずはここで原因の大枠を判断します。

💡 なぜこのコマンドを使うのか

ここで使っている ping は、ネットワークの ping コマンドではありません。

Ansibleの ping モジュールは、次の確認をまとめて行うためのものです。

SSHで接続できるか

認証が通るか

リモートでPythonが実行できるか

つまり、

「Ansibleがそのホストで処理を実行できる状態か」を一発で確認するコマンドです。

そのため、単なる疎通確認ではなく、
Ansible実行の前提条件をまとめてチェックする用途で使います。

このコマンドで確認するのは、「どの種類のエラーか」です。

ログの結果は、次の4つに分類できます。

ログの特徴	分類
Timeout	ネットワーク問題（応答なし）
Connection refused	SSHサービス未起動・ポート不一致
Permission denied	認証失敗（鍵・パスワード）
host設定ミス	`inventory.ini`ファイルの接続定義ミス（ユーザー・鍵・ポートなど）

※ このケースは「SSH以前の設定ミス」であることが多い

② Ansibleログファイル（設定時のみ）

Ansibleはデフォルトではログを出力しません。
必要な場合のみ設定します。

設定は ansible.cfg で行います。

[defaults]
log_path = /var/log/ansible.log

ログの出力先は、環境によって次のような場所になります。

/var/log/ansible.log
./logs/ansible.log

※ 環境によっては存在しない場合があります

③ サーバー側ログ（SSH認証）

接続先サーバーで確認します。

/var/log/secure
/var/log/auth.log

主に確認する内容：

SSH認証失敗
鍵の拒否
sshdの状態

🔧 inventory.ini（接続設定の前提）

[localhost]
# localhost ansible_connection=local

[test_servers]
192.168.1.21 ansible_user=ansibleuser ansible_ssh_pass="xxxxxxxxxx" ansible_become=true

このファイルは単なる設定ではなく、次の役割を持ちます。

SSH接続の前提条件
認証情報の供給源
接続先定義そのもの

SSHエラーに見えても、実際はここが原因のケースが多いです。

🎯 判断の前提（ここが重要）

UNREACHABLEは、最終的に次の2つに整理できます。

SSHに到達できていない
SSH認証で失敗している

🔍 調査の基本フロー

ansible -vvvv のログを見る
エラー種別を分類する
SSH手動確認で切り分ける
inventory.iniを確認する
原因を確定する

🎯 第5章の位置づけ

ここでは「原因の特定方法」を整理しました。

次の第6章以降では、実際のエラーごとに
具体的な切り分けと対処方法を解説します。

↑ 目次に戻る

6. ネットワーク：Timeout（応答なし）

症状

UNREACHABLE! => Timeout

SSH以前の段階で通信が成立していない状態です。
基本的にはネットワーク到達性の問題として扱います。

※Timeoutは「SSH未到達」だけでなく「接続後の待機」で発生することもあります

実際のAnsibleログ

fatal: [192.168.1.21]: UNREACHABLE! => {
    "changed": false,
    "msg": "Timeout (12s) waiting for privilege escalation prompt: ",
    "unreachable": true
}

状態の意味

SSH接続そのもの、または接続直後の応答処理で止まっています。

切り分けの考え方（Ansible視点）

まずはAnsible側で「どの段階で失敗しているか」を確認します。

SSH接続前で止まっているのか
接続後の処理で止まっているのか

補助確認（OS視点）

必要に応じて、OSからもネットワーク疎通を確認します。

ping <host>

これはAnsibleのコマンドではなく、
対象ホストにネットワーク的に到達できるかを確認するためのものです。

ポート確認

SSHポートが開いているかを確認します。

nc -zv <host> 22

よくある原因

状況としては次のように整理できます。

応答なし → FW / セキュリティグループ
No route → ルーティング問題
到達不可 → IPアドレスまたはDNS設定ミス

SSH以前で止まっている場合は、原因はネットワーク側にあると考えます。

↑ 目次に戻る

7. SSHサービス：Connection refused（拒絶）

症状

UNREACHABLE! => Connection refused

サーバー自体には到達できていますが、SSHが接続を受け付けていない状態です。

実際のAnsibleログ

fatal: [192.168.1.21]: UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: Connection refused",
    "unreachable": true
}

まず確認すること

ここで見るべきポイントはシンプルです。

sshd（SSHサービス）は起動しているか
22番ポートは待ち受け状態か

サーバー側での確認コマンド

systemctl status sshd

ss -tlnp | grep 22

状態の見方

active (running) でない → sshdが動いていない
LISTEN がない → ポート設定やバインドの問題
LISTENしているのに拒否される → firewallや制御設定の可能性

このエラーの本質

TCPレベルでは到達していますが、SSHプロセスが接続を受けていません。

つまり、

ネットワーク到達はOK
SSHサービス側で拒否

という状態です。

↑ 目次に戻る

8. 認証（Permission denied：本人確認失敗）

SSH接続自体は成立していますが、認証の段階で拒否されている状態です。

8-1. 鍵認証の失敗（publickey）

Permission denied (publickey)

実際のAnsibleログ：


[root@localhost workspace]# ansible 192.168.1.21 -m ping

192.168.1.21 | UNREACHABLE! => {
    "changed": false,
    "msg": "Permission denied (publickey).",
    "unreachable": true
}

原因：

サーバー側に登録されている公開鍵と、クライアントが提示している秘密鍵が一致していません。また、秘密鍵の場所をAnsibleが正しく認識していない場合にも発生します。

対策：

ansible.cfg または inventory.ini で private_key_file が正しく指定されているか確認。

デフォルト（id_rsa）以外の鍵（ed25519 等）を使用している場合は、明示的な指定が必須です。

8-2. パスワード認証の失敗

Invalid/incorrect password

実際のAnsibleログ：

[root@localhost workspace]# ansible 192.168.1.21 -m ping

[WARNING]: Unhandled error in Python interpreter discovery for host 192.168.1.21: Invalid/incorrect password: Permission denied, please try again.
192.168.1.21 | UNREACHABLE! => {
    "changed": false,
    "msg": "Invalid/incorrect password: Permission denied, please try again.",
    "unreachable": true
}

原因：

パスワードの不一致、またはユーザーのロックアウト。
sshpassの不在：Ansibleでパスワード認証（-k）を行うには、実行側に sshpass パッケージが必要です。

自動入力の拒否：ターゲット側のSSH設定（sshd_config）により、非対話的なパスワード入力が制限されている場合があります。

認証失敗の共通構造

この段階では、ネットワークやSSHサービス自体は問題ありません。

ネットワーク → OK
sshd → OK
認証 → NG（ここで停止）

切り分け方法

Ansibleを介さず、SSHコマンド単体で接続を確認します。

鍵認証の場合：

ssh -i ~/.ssh/id_ed25519 user@host
# または
ssh -i ~/.ssh/id_rsa user@host

パスワード認証の場合：

ssh user@host

このエラーの本質

Permission denied は「接続不能」ではなく、「本人確認の失敗」です。

鍵が違う（未登録・別鍵）
パスワード不一致
ユーザー自体の問題（ロックや権限）

8-3. 認証試行回数の制限（MaxAuthTries）

現象：

正しいパスワードや鍵を使用しても、連続して失敗した直後に拒否され続ける状態。

原因：

SSHサーバーの MaxAuthTries（デフォルトは通常6回）により、短時間に多数の認証試行を行うと、攻撃とみなされ一時的に接続が遮断されます。Ansibleは内部で複数の接続を試みるため、この制限に抵触しやすい特性があります。

対策：

ターゲット側のSSHサービスを再起動（systemctl restart sshd）して試行カウントをリセットする。
認証方式を鍵認証に一本化し、無駄な認証試行を排除する。

↑ 目次に戻る

9. 接続定義ミス（inventory.iniの誤り）

SSH接続を試行する前段階の「接続に必要な前提情報」が誤っている場合、AnsibleはUNREACHABLEとなります。このケースはネットワーク障害やSSH認証の不備ではなく、Ansible側の接続パラメータの不整合が主な原因です。

症状（エラーパターンの例）

インベントリの設定ミスは単一のエラーメッセージに限定されず、状況によって表示が異なります。

UNREACHABLE! => No route to host
UNREACHABLE! => Host unreachable
UNREACHABLE! => Connection timed out
UNREACHABLE! => host unreachable / connection failure

これらはネットワーク層のエラーに見える場合もありますが、指定したパラメータ（IPアドレスやポート番号等）が実環境と乖離している際に発生します。

実際のAnsibleログ

fatal: [192.168.1.99]: UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: No route to host",
    "unreachable": true
}

よくある原因

インベントリに起因する問題は、「SSHプロトコルによる通信が確立される前の設定不備」です。

IPアドレスの誤記：ターゲットホストのIPアドレスが実際のものと異なる。
接続ユーザー（ansible_user）の誤り：対象OSに存在しない、またはSSH許可されていないユーザーを指定している。
ポート番号（ansible_port）の誤設定：sshdが待機しているポート（デフォルト22）と異なる番号を指定している。
秘密鍵パスの不整合：ansible_ssh_private_key_file で指定したパスに鍵ファイルが存在しない。
Host Key Checkingによる停止：初回接続時のホスト鍵検証（yes/no）の対話が発生し、自動処理が停止している。

inventory.ini（接続定義）

[test_servers]
192.168.1.21 ansible_user=ansibleuser ansible_ssh_pass="xxxxxxxxxxx" ansible_become=true

接続の切り分けと確認手順

Ansibleの設定に問題があるかを確認するため、以下の手順で疎通テストを行います。

1. ネットワークポートの確認
指定したIPとポートに対して、TCPレベルで応答があるか確認します。

nc -zv <host> 22

2. SSH単体での接続確認
Ansibleの変数を介さず、OS標準のSSHコマンドで接続を試行します。

パスワード認証の場合：

ssh user@host

鍵認証の場合：

ssh -i ~/.ssh/id_rsa user@host

3. 判断基準

SSH単体で成功する場合：
原因は inventory.ini または ansible.cfg 上のパラメータ設定ミスにあります。
SSH単体でも失敗する場合：
原因はネットワーク経路、ターゲット側のSSHサービス設定、またはOS側のアクセス制限にあります。

AnsibleとSSHの対応関係

SSHの接続要素	Ansible設定項目（変数）
接続ユーザー	ansible_user
ポート番号	ansible_port
秘密鍵	ansible_ssh_private_key_file

重要な原則

Ansibleで UNREACHABLE が発生した際は、まず「手動でのSSH接続が可能か」を最優先で確認してください。これにより、調査対象を以下のいずれかに明確に切り分けることが可能になります。

1. Ansible固有の設定問題（パラメータの定義ミス）

2. ネットワークインフラの問題（経路・フィルタリング）

3. ターゲットホストの問題（サービス停止・OS設定）

↑ 目次に戻る

10. 鍵認証の仕組みと権限管理（Permission denied の背景）

Permission denied は、SSHサーバー側で鍵の照合が正常に完了しなかった状態を指します。
SSH鍵認証を成立させるには、サーバー側の ~/.ssh/authorized_keys に適切な公開鍵が登録されている必要があります。

10-1. 鍵認証のプロセス

SSH認証は以下の流れで行われます。

署名の作成
クライアント（Ansible実行環境）が秘密鍵で署名を作成しサーバへ送信
公開鍵の照合
サーバ側が authorized_keys 内の公開鍵で署名を検証
認証の成否
一致すればログイン許可、不一致または鍵なしなら拒否

10-2. 認証失敗の主な要因

鍵認証が失敗する典型原因は以下です。

公開鍵の未登録
authorized_keys に該当公開鍵が存在しない
秘密鍵の指定ミス（Ansible）
デフォルト鍵（id_rsaなど）が使用されている
OS権限の問題
パーミッションが緩い場合、SSHはセキュリティ上の理由で鍵を無視する

推奨パーミッション

chmod 755 ~  # または 700。グループや他人の「書き込み」権限があるとNG
chmod 600 ~/.ssh/authorized_keys

SSHは所有者以外の書き込みが可能な状態を強く拒否します。

10-3. 実務での切り分け（Ansible利用時）

秘密鍵の明示指定

ansible.cfg

[defaults]
private_key_file = ~/.ssh/id_ed25519

inventory.ini

192.168.1.21 ansible_ssh_private_key_file=~/.ssh/id_ed25519

公開鍵の正しい登録

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

ユーザー不一致の確認

SSH接続ユーザーが異なると認証は失敗します。

例として以下はすべて別ユーザーです。

ubuntu
ec2-user
root
centos

authorized_keys はユーザーごとに別管理です。

10-4. 見落としやすい追加原因

ホームディレクトリの権限

.ssh だけでなく親ディレクトリも影響します。

chmod 755 ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

sshd_config の設定

サーバ側設定が無効化している場合があります。

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

ssh-agent の影響

意図しない鍵が使われている場合があります。

ssh-add -l

Ansibleのユーザー指定

ansible_user=ubuntu

または

192.168.1.21 ansible_user=ubuntu ansible_ssh_private_key_file=~/.ssh/id_ed25519

authorized_keys のフォーマット問題

改行崩れ
余計なスペース
Windows改行（CRLF）

10-5. デバッグ方法

SSH詳細ログ

ssh -vvv user@host

Ansible詳細ログ

ansible -i inventory.ini all -m ping -vvv

重要な原則

鍵認証はパスワード認証より安全で自動化に適した方式ですが、環境差分による失敗が起きやすい仕組みです。

Permission denied が発生した場合は以下を総合的に確認する必要があります。

鍵の種類と一致
権限設定
SSHサーバ設定
Ansible設定
接続ユーザー
ssh-agentの状態

単一原因ではなく複合原因であることが多い点が重要です。

↑ 目次に戻る

11. 実務における典型的な接続エラーと対策

Ansibleを利用した自動化において、SSH接続の仕様に起因する代表的なエラー事例と回避策を整理します。

11-1. ホスト鍵検証による処理の停止（Host Key Checking）

現象：

新規サーバーへの初回接続時、SSHプロンプト（Are you sure you want to continue connecting (yes/no/[fingerprint])?）が表示され、Ansibleの処理が応答待ちのまま停止、またはタイムアウトする。

原因：

Ansibleは非対話的な実行を前提としているため、ユーザーによる手動の「yes」入力を待機できず接続に失敗します。

対策：

ansible.cfg にてホスト鍵の検証を無効化することで、初回接続を自動化できます。

[defaults]
host_key_checking = False

11-2. 秘密鍵パスの指定不備（相対パスの依存）

現象：

コマンド実行場所（カレントディレクトリ）を変更すると、秘密鍵の読み込みに失敗し、Permission denied が発生する。

原因：

秘密鍵のパスを相対パス（例：./id_ed25519）で指定している場合、実行環境のディレクトリ構造に依存するため、パスの解決ができなくなります。

対策：

インベントリや設定ファイルにおける秘密鍵の指定は、必ず絶対パス（フルパス）で行うことが鉄則です。

ansible_ssh_private_key_file = /home/user/.ssh/id_ed25519

11-3. 暗黙の接続ユーザー指定による不整合

現象：

ターゲットサーバー上に存在しない、または意図しないユーザー名で接続を試行し、認証が拒否される。

原因：

Ansibleは接続ユーザー（ansible_user）の指定がない場合、実行環境のログインユーザー名をデフォルトの接続ユーザーとして使用します。管理対象OSの構成と実行ユーザー名が一致しない場合に発生します。

対策：

ターゲット環境に合わせた接続ユーザーをインベントリ等で明示的に定義します。

[test_servers]
192.168.1.21 ansible_user=rocky

まとめ：接続トラブルを回避するためのチェックリスト

実務においてSSH接続の問題が発生した際は、以下の3点をまず確認してください。

非対話実行が可能か（ホスト鍵検証の設定）
パス指定は絶対パスか（鍵ファイルの参照）
ユーザー定義は適切か（接続ユーザーの明示）

これらの設定を共通化・固定化することで、環境の変化に左右されない堅牢な自動化基盤を構築できます。

↑ 目次に戻る

12. まとめ：原因の見え方が変わる「調査の原則」

UNREACHABLE は単なるエラー名称ではなく、「どのスタック（層）で処理が停止しているか」 を示す指標です。これまでに解説したエラー事象は、以下の3つの階層に整理して考えることで、迅速な原因特定が可能になります。

12-1. 接続フェーズによる階層分離

分類（階層）	主なエラーメッセージ	優先確認項目
ネットワーク	Connection timed out / No route to host	ルーティング、Firewall、Security Group
サービス層	Connection refused	ターゲット側の sshd 稼働状態、待機ポート番号
認証層	Permission denied	authorized_keys、秘密鍵の指定、パーミッション

12-2. 実務における調査フロー

UNREACHABLE が発生した際は、上位（ネットワーク）から下位（認証）へ向かって、以下の順序で切り分けを行います。

1. ネットワーク疎通の確認 (Timeout / No route)

そもそもパケットがターゲットに到達しているかを確認。

2. サービス応答の確認 (Refused)

ターゲットが接続を「拒否」しているか（サービスが起動しているか）を確認。

3. 認証プロセスの確認 (Permission denied)

本人確認に失敗しているかを確認。

12-3. 原因を特定するための3つの視点

トラブルに直面した際、以下の3点を自問することで、解決までの最短ルートが見えてきます。

1. 「どの層」で停止しているか（メッセージの正確な読み取り）

2. その層に影響を与える「設定」は何か（原因の仮説立て）

3. その設定が「期待値」通りか（実環境と定義の照合）

インフラの自動化において、この「階層的な思考」を習慣化することは、技術的な課題を解決するだけでなく、現場におけるエンジニアの信頼性を担保するための重要なサバイバル戦略となります。

↑ 目次に戻る

13. 次回予告：Permission deniedの正体

SSH接続の問題を越えてログインできるようになっても、Ansibleの実行はそこで終わりではありません。

次に出てくるのは、Playbookの実行時に発生する「権限」に関するエラーです。

FAILED! => msg: Permission denied

ログイン自体は成功しているのに、なぜ処理の途中で失敗するのか
Ansibleが内部で行っている become（sudo）の仕組みはどうなっているのか
ls -l で表示される所有者・グループ・その他の判定はどのように効いているのか

次回は、これらの疑問を整理しながら、Linuxの権限チェックの仕組みとAnsibleの実行フローの関係を解説します。

📚 次の記事
→ 第4回:【Permission denied】権限エラーの原因とbecomeの仕組み（ls -l / sudo / become）

↑ 目次に戻る

回	内容
第0回	Ansibleの仕組み
第1回	Linuxの構造（Kernel / Shell / Filesystem）
第2回	command not foundの原因：PATH
第3回	SSH
第4回	Permission deniedの原因
第5回	systemd
第6回	cron
第7回	ディスク容量
第8回	サーバーが遅い原因

📑 連載の移動
前の記事：【OS編】第2回｜次の記事：【OS編】第4回

📑 【OS編】全体のまとめはこちら

→ Ansibleが理解できない理由はLinuxにあった【OS編】まとめ

🗺️ 初めての方・シリーズの全体像を知りたい方はこちら

本記事は、OSの仕組みからAnsible設計までを繋ぐ連載シリーズの一部です。
「どこから読み始めればいいか」あるいは、「OS/Shell/Ansible編の関係性」 について把握されたい場合は、以下の統合ガイドで整理しています。

→ Ansibleが理解できない理由はLinuxにあった｜統合ガイド

14. 連載一覧：Ansibleが理解できない理由はLinuxにあった

回数とタイトル	内容（概要）
Ansibleが理解できない理由はLinuxにあった【OS編】：【保存版】Ansibleトラブル逆引き辞典（Linux / SSH / Shellエラー対応	Ansibleで発生するエラー（UNREACHABLE / Permission denied / command not found など）を「エラーから逆引き」で調べられる実務向け記事。各回の内容と対応しており、トラブル時の入口として使える。
第0回：【なぜAnsibleは理解できないのか】仕組みを分解してみる	Ansibleは「Linux操作の自動化」ツール。Ansible → SSH → Shell → Linux の構造を理解し、シリーズ全体の土台を作る。
第1回：【なぜLinuxが分からないと詰むのか】Kernel / Shell / Filesystemの全体像	Linuxの基本構造を理解することで、Ansibleが内部で何をしているのか（Shell実行・プロセス・ファイル操作）を把握できるようになる。
第2回：【Ansibleでハマる】command not foundの原因はPATHだった（環境変数の正体）	Ansible実行時に発生する「command not found」の原因はPATHにある。環境変数の仕組みを理解しないとエラーを解決できない。
第3回：AnsibleのSSH接続が失敗すると UNREACHABLE エラーになる。（Connection refused / Permission denied / Timeout など）	AnsibleのSSH接続が失敗すると UNREACHABLE エラーになる。SSH（鍵認証・ポート・Firewall）を理解することで原因を特定できる。
第4回：【Permission deniedの正体】Linuxユーザーと権限の仕組み	Ansibleのbecome（sudo）で発生する Permission denied の原因はLinux権限にある。ユーザー・グループ・権限の仕組みを理解する。
第5回：【サービスが起動しない理由】systemdの仕組みを理解する	Ansibleのservice / systemdタスクが失敗する原因はLinux側にある。systemdの仕組みを理解することで原因を特定できる。
第6回：【cronが動かない理由】手動では動くのに失敗する原因	Ansibleで設定したcronが動かない原因は環境差分（PATHなど）にある。cron特有の実行環境を理解することで解決できる。
第7回：【No space left on device】ディスク容量不足の原因と調査方法（df / du / log）	Ansible実行時のディスク不足エラーはLinuxのログ肥大化や容量管理が原因。df / duを使った調査方法を解説する。
第8回：【サーバーが遅い】原因の見つけ方（CPU / メモリ / プロセス）	Ansible実行が遅い・失敗する原因はサーバー負荷の可能性がある。CPU・メモリ・プロセスの見方を理解して原因を特定する。

↑ 目次に戻る