WARNINGと併発？”failed to add the host to the list of known hosts” の全パターンと解決法

By /

はい、承知いたしました。「WARNINGと併発？”failed to add the host to the list of known hosts” の全パターンと解決法」についての詳細な記事を作成します。約5000字の要件を満たすよう、詳細な説明と具体的なコマンド例を含めて記述します。

WARNINGと併発？「failed to add the host to the list of known hosts」の全パターンと解決法を徹底解説

SSH接続を試みた際に、以下のような一見不可解なエラーメッセージに遭遇したことはありませんか？

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:5
remove with:
ssh-keygen -f "/home/user/.ssh/known_hosts" -R "hostname"
ECDSA host key for hostname has changed and you have requested strict checking.
Host key verification failed.

そして、この有名なWARNINGメッセージを解決しようと、指示通りにssh-keygen -Rコマンドを実行したのに、今度はこんなメッセージが出てきてしまった…。

$ ssh user@hostname
The authenticity of host 'hostname (xxx.xxx.xxx.xxx)' can't be established.
ECDSA key fingerprint is SHA256:yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'hostname' (ECDSA) to the list of known hosts.
Failed to add the host to the list of known hosts (/home/user/.ssh/known_hosts).

あるいは、WARNINGは出ずに、初回接続時からこのFailed to add...エラーに悩まされている方もいるでしょう。

この「Failed to add the host to the list of known hosts」というエラーは、多くの開発者やシステム管理者が一度は経験する、地味ながらも厄介な問題です。このエラーは、SSHのセキュリティ機構の根幹に関わるknown_hostsファイルへの書き込みに失敗したことを示しています。

本記事では、このエラーが発生する考えられる全ての原因（全パターン）を網羅的に解説し、それぞれの状況に応じた具体的な解決策をステップバイステップで詳述します。この記事を読めば、あなたはこのエラーを二度と恐れることはなくなるでしょう。

目次

  1. はじめに：SSHとknown_hostsファイルの役割

    • SSHホストキー認証の仕組み
    • known_hostsファイルとは何か？（場所、形式、目的）
    • なぜ「Failed to add…」エラーが起きるのか？

  2. エラー発生の全パターンと診断法

    • パターン1：【最頻出】パーミッション（権限）の問題
      • .sshディレクトリのパーミッションが不適切
      • known_hostsファイルのパーミッションが不適切
      • 親ディレクトリ（ホームディレクトリ）のパーミッションが不適切
      • 所有権（オーナー）が不適切
    • パターン2：ファイルまたはディレクトリの不存在
      • .sshディレクトリが存在しない
      • known_hostsファイルが存在しない（かつ、作成もできない）
    • パターン3：ファイルシステムの問題
      • ファイルシステムが読み取り専用（Read-only）になっている
      • ディスクの空き容量が不足している
      • ユーザーのディスククォータ（容量制限）を超過している
    • パターン4：実行環境や特殊なケース
      • sudoコマンド経由でSSHを実行している
      • コンテナ環境（Dockerなど）での実行
      • CI/CDパイプライン（Jenkins, GitLab CIなど）での実行
      • SELinuxやAppArmorなどのセキュリティモジュールによる制限

  3. パターン別・具体的な解決策

    • 解決策1：パーミッションと所有権の修正（パターン1, 2向け）
    • 解決策2：ファイルシステム問題の解決（パターン3向け）
    • 解決策3：実行環境に応じた適切な対応（パターン4向け）

  4. 【発展】より深い理解と高度なテクニック

    • 「REMOTE HOST IDENTIFICATION HAS CHANGED!」との違いを理解する
    • known_hostsファイルの手動管理 (ssh-keygen -R)
    • ホストキーの自動追加 (ssh-keyscan) とそのリスク
    • SSH設定ファイル (~/.ssh/config) による挙動の制御

  5. まとめ：トラブルシューティングの王道

1. はじめに：SSHとknown_hostsファイルの役割

このエラーを正しく理解するためには、まずSSHがどのようにして安全な接続を確立しているのか、そしてknown_hostsファイルがその中でどのような役割を果たしているのかを知る必要があります。

SSHホストキー認証の仕組み

あなたがssh user@hostnameとコマンドを打つと、クライアント（あなたのPC）とサーバーの間で以下のようなやり取りが舞台裏で行われます。

  1. 接続要求: クライアントがサーバーに接続を要求します。
  2. ホストキーの提示: サーバーは「私は本物のhostnameですよ」という証明書として、自身のホスト公開鍵（Host Public Key）をクライアントに送ります。
  3. クライアント側の検証: クライアントは受け取ったホスト公開鍵を、手元にある「信頼できるサーバーの公開鍵リスト」と照合します。
    • 初回接続の場合: リストに該当する鍵がないため、「このサーバーは初めて接続する相手だけど、信頼していいか？ (Are you sure you want to continue connecting?)」とユーザーに尋ねます。
    • 2回目以降の接続の場合: リストにある鍵と、今回送られてきた鍵が一致するかどうかを確認します。
  4. 検証結果に応じた処理:
    • 初回接続で “yes” と応答: クライアントはサーバーの公開鍵を「信頼できるリスト」に追加します。
    • 2回目以降で鍵が一致: 何も表示せず、スムーズに認証プロセス（パスワード入力や公開鍵認証）に進みます。
    • 2回目以降で鍵が不一致: 「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」という警告を表示し、接続を中断します。これは中間者攻撃（Man-in-the-Middle Attack）の可能性があるためです。

この「信頼できるサーバーの公開鍵リスト」こそが、known_hostsファイルなのです。

known_hostsファイルとは何か？

  • 目的: 過去に接続したことがあるSSHサーバーのホスト公開鍵を保存し、次回以降の接続時にサーバーがなりすまされていないか（中間者攻撃を受けていないか）を検証するために使用されます。
  • 場所: 通常、ユーザーのホームディレクトリ配下の.sshディレクトリに置かれています。フルパスで示すと/home/あなたのユーザー名/.ssh/known_hosts（macOSやLinuxの場合）となります。
  • 形式: 1行に1サーバーの情報が記録されます。基本的な形式は以下の通りです。
    ホスト名,IPアドレス 暗号化アルゴリズム 公開鍵データ
    例：
    github.com,140.82.121.4 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
    セキュリティ向上のため、最近のSSHクライアントはデフォルトでホスト名部分をハッシュ化して保存することが多いです（HashKnownHosts yes）。その場合、ファイルの中身は一見してどのホストかわからないようになっています。

なぜ「Failed to add…」エラーが起きるのか？

このエラーメッセージを直訳すると「ホストをknown hostsのリストに追加するのに失敗しました」となります。

つまり、前述のSSHホストキー認証のステップにおいて、初回接続時にユーザーが “yes” と応答し、クライアントがサーバーの公開鍵をknown_hostsファイルに書き込もうとした瞬間に、何らかの理由で書き込みができなかった、という状況を示しています。

このエラーは、サーバー側の問題ではなく、100%クライアント側の問題です。具体的には、SSHクライアントプロセスが~/.ssh/known_hostsファイルに対して書き込み操作（ファイルの新規作成または追記）を行う権限がない場合に発生します。

2. エラー発生の全パターンと診断法

では、なぜ書き込みができないのでしょうか？その原因を体系的に分類し、それぞれの診断方法を見ていきましょう。

パターン1：【最頻出】パーミッション（権限）の問題

これが最も一般的で、エラー原因の9割以上を占めると言っても過言ではありません。Linux/macOSのファイルシステムには、ファイルやディレクトリごとに「誰が何をできるか」を定めたパーミッションが存在します。これが不適切だと、SSHクライアントはファイルを書き込めません。

SSHはセキュリティを重視するプログラムであるため、関連ファイルのパーミッションには特に厳しい要件を課しています。

診断方法:
ls -laコマンドを使って、ホームディレクトリ、.sshディレクトリ、known_hostsファイルの3つのパーミッションと所有権を一度に確認します。

“`bash

まずホームディレクトリに移動

cd ~

ホームディレクトリ配下の.sshディレクトリとその中身を詳しく表示

ls -la .ssh
“`

正しい状態の出力例:

$ ls -la .ssh
total 24
drwx------ 2 user group 4096 Mar 20 10:00 .
drwxr-xr-x 45 user group 4096 Mar 20 09:55 ..
-rw-r--r-- 1 user group 1766 Jan 15 11:30 id_rsa
-rw-r--r-- 1 user group 400 Jan 15 11:30 id_rsa.pub
-rw-r--r-- 1 user group 8192 Mar 19 17:30 known_hosts

チェックポイント:

  1. .sshディレクトリ (.で表示される行):

    • パーミッション: drwx------ となっているか？ dはディレクトリ、rwxは所有者（自分）が読み・書き・実行可能、続く------は他のユーザーには一切の権限がないことを意味します。8進数表記で700です。ここがdrwxrwxr-xのようになっていると、SSHは「安全でない」と判断し、動作を拒否することがあります。
    • 所有者: user groupの部分が、現在ログインしている自分のユーザー名になっているか？

  2. known_hostsファイル:

    • パーミッション: -rw------- または -rw-r--r-- となっているか？ rwは所有者（自分）が読み・書き可能であることを意味します。8進数表記で600または644です。書き込み権限wが所有者にないと、当然追記はできません。
    • 所有者: user groupの部分が、現在ログインしている自分のユーザー名になっているか？

  3. 親ディレクトリ (..で表示される行):

    • これはホームディレクトリを指します。ここのパーミッションが極端に厳しく設定されている（例えば、所有者ですら書き込み権限がないなど）場合も問題になりえますが、通常はdrwxr-xr-xのようになっています。

もし、これらのいずれかが期待される状態と異なっていれば、それがエラーの直接的な原因です。

パターン2：ファイルまたはディレクトリの不存在

SSHを初めて使う環境や、誤ってファイルを削除してしまった場合に発生します。

診断方法:
パターン1と同様にls -la .sshを実行します。

  • ls: cannot access '.ssh': No such file or directory と表示された場合
    → .sshディレクトリが存在しません。
  • .sshディレクトリは存在するが、中にknown_hostsファイルが見当たらない場合
    → known_hostsファイルが存在しません。

ファイルが存在しないだけなら、SSHクライアントが自動で作成してくれるはずです。しかし、パターン1のパーミッション問題が複合していると（例：.sshディレクトリに書き込み権限がない）、ファイルを作成できずにエラーとなります。

パターン3：ファイルシステムの問題

これは比較的稀なケースですが、より根本的な問題が原因である可能性も考慮すべきです。

診断方法:

  • 読み取り専用ファイルシステムの確認:
    mountコマンドで、ホームディレクトリが含まれるファイルシステムがro (read-only) でマウントされていないか確認します。
    bash
    mount | grep " on / " # ルートファイルシステムの場合
    mount | grep " on /home " # /homeが別パーティションの場合
    出力に (ro, ...) のような記述があれば、読み取り専用になっています。これは、システムの起動時エラーなどで安全のためにOSが自動的に設定することがあります。

  • ディスク空き容量の確認:
    df -hコマンドで、ディスクの使用率を確認します。
    bash
    df -h
    Use%が100%になっているパーティションにホームディレクトリがある場合、新しいファイルを作成したり追記したりすることはできません。

  • ディスククォータの確認:
    大学や企業の共有サーバーなどで、ユーザーごとに使用できるディスク容量やファイル数が制限されている（クォータ）場合があります。
    quota -sコマンドで確認できます。
    bash
    quota -s
    blocks (容量) や inodes (ファイル数) が上限に達していると、書き込みは失敗します。

パターン4：実行環境や特殊なケース

コマンドの実行方法や環境が原因で、意図しない場所のknown_hostsファイルにアクセスしようとしているケースです。

診断方法:

  • sudoコマンド経由での実行:
    sudo ssh user@hostnameのように実行していませんか？
    sudoはコマンドをrootユーザーとして実行します。そのため、SSHクライアントはrootのホームディレクトリ、つまり/root/.ssh/known_hostsに書き込もうとします。もし/root/.sshディレクトリが存在しないか、パーミッションが不適切であれば、このエラーが発生します。
    「自分のホームディレクトリのパーミッションは完璧なはずなのに…」と思っている場合、このケースを疑ってください。

  • コンテナ環境（Dockerなど）での実行:
    Dockerコンテナ内でsshコマンドを実行している場合、そのコンテナ内のファイルシステムに書き込もうとします。
    bash
    docker exec -it my-container ssh user@hostname
    この場合、コンテナ内の/root/.ssh/（rootで実行している場合）や/home/user/.ssh/（一般ユーザーで実行している場合）のパーミッションが問題になります。また、ホストマシンの.sshディレクトリをボリュームマウントしていない限り、コンテナを再作成するとknown_hostsの情報は失われます。

  • CI/CDパイプライン（Jenkins, GitLab CIなど）での実行:
    CI/CDのジョブ内でデプロイなどのためにSSH接続を行う場合、ジョブはjenkinsやgitlab-runnerといった専用のユーザーで実行されます。これらのユーザーのホームディレクトリは特殊な場所にあったり、書き込みが制限されていたりすることが多く、known_hostsの書き込みに失敗しがちです。

  • SELinuxやAppArmorによる制限:
    Red Hat系のLinuxディストリビューション（CentOS, RHELなど）ではSELinux、UbuntuなどではAppArmorという、より強力なセキュリティモジュールが有効になっていることがあります。これらは、通常のファイルパーミッションが許可していても、プロセスの挙動を監視し、ポリシーに反するファイルアクセスをブロックすることがあります。
    ls -Z .sshコマンドで、ファイルのセキュリティコンテキストを確認できます。
    bash
    # SELinuxが有効な環境で実行
    $ ls -Z ~/.ssh/known_hosts
    -rw-r--r--. user group unconfined_u:object_r:ssh_home_t:s0 /home/user/.ssh/known_hosts
    ここのコンテキスト (ssh_home_t) が不適切になっていると、アクセスが拒否されることがあります。また、ausearchや/var/log/audit/audit.logに拒否されたログが記録されているか確認するのも有効です。

3. パターン別・具体的な解決策

原因の特定ができたら、次はいよいよ解決です。各パターンに応じた具体的なコマンドと手順を解説します。

解決策1：パーミッションと所有権の修正（パターン1, 2向け）

これが最も効果的な解決策です。以下のコマンドをクライアントマシン（SSHを実行する側）のターミナルで実行してください。

  1. .sshディレクトリが存在しない場合、作成する:
    -pオプションは、親ディレクトリが存在しない場合にそれも一緒に作成する便利なオプションですが、この場合はホームディレクトリは存在するので不要ですが、癖として付けておくと良いでしょう。
    bash
    mkdir -p ~/.ssh

  2. .sshディレクトリのパーミッションを700に設定する:
    700は、所有者（自分）だけが読み・書き・実行でき、他のユーザーは一切アクセスできないことを意味します。これはSSHのセキュリティ要件です。
    bash
    chmod 700 ~/.ssh

  3. known_hostsファイルが存在しない場合、空のファイルを作成する:
    bash
    touch ~/.ssh/known_hosts

  4. known_hostsファイルのパーミッションを600または644に設定する:

    • 600: 所有者だけが読み・書き可能。よりセキュア。
    • 644: 所有者は読み・書き可能、グループとその他のユーザーは読み取りのみ可能。
      どちらでもSSHは動作しますが、一般的には600が推奨されます。
      bash
      chmod 600 ~/.ssh/known_hosts

  5. 【重要】.sshディレクトリ以下の所有権を自分自身に設定する:
    何らかの操作（特にsudoを使った操作）で、ファイルの所有者がrootに変わってしまっていることがあります。-Rオプションでディレクトリ配下のファイルも再帰的に所有権を変更します。$(whoami)は現在ログインしているユーザー名に自動で置き換わります。
    bash
    sudo chown -R $(whoami):$(whoami) ~/.ssh
    （sudoが必要なのは、所有者がrootになっているファイルを一般ユーザーの権限で変更できないためです）

これらのコマンドを実行した後、再度SSH接続を試みてください。ほとんどの場合、これで解決するはずです。

“`bash

再度SSH接続

ssh user@hostname
The authenticity of host ‘…’ can’t be established.
…
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added ‘hostname’ (ECDSA) to the list of known hosts.

ここで “Failed to add…” が出なければ成功！

“`

解決策2：ファイルシステム問題の解決（パターン3向け）

  • 読み取り専用ファイルシステムの場合:
    システムを再起動することで正常に戻ることが多いです。それでも解決しない場合は、fsckコマンドによるファイルシステムチェックが必要になるかもしれません。これはシステムの深刻な問題の兆候である可能性があるため、システム管理者に相談するか、慎重な対応が必要です。
    書き込み可能に再マウントするコマンド例:
    bash
    sudo mount -o remount,rw /

  • ディスク空き容量不足の場合:
    不要なファイルを削除して容量を確保してください。du -sh *やncduコマンドで、どのディレクトリが容量を圧迫しているか調査すると良いでしょう。
    bash
    # ホームディレクトリで実行
    du -sh * .[^.]* | sort -hr | head -n 10

  • ディスククォータ超過の場合:
    これも不要なファイルを削除するのが基本的な解決策です。もし正当な理由で容量がさらに必要な場合は、サーバーの管理者にクォータの緩和を依頼してください。

解決策3：実行環境に応じた適切な対応（パターン4向け）

  • sudo経由で実行している場合:

    • 方法A（非推奨）: rootユーザーの.sshディレクトリとknown_hostsを作成・権限設定する。しかし、これは根本的な解決とは言えません。
    • 方法B（推奨）: なぜsudoでSSHを実行する必要があるのかを考え直します。もし、リモートサーバーでroot権限の操作が必要なのであれば、一般ユーザーでSSHログインした後、サーバー側でsudoを使うのが定石です。
    • 方法C（次善策）: どうしてもsudoで実行する必要がある場合、sshコマンドに-oオプションを付けて、使用するknown_hostsファイルを明示的に指定します。
      bash
      sudo ssh -o UserKnownHostsFile=/home/あなたのユーザー名/.ssh/known_hosts user@hostname

  • コンテナ環境（Dockerなど）の場合:
    ホストマシンの.sshディレクトリをコンテナにボリュームマウントするのが最も永続的で便利な方法です。
    “`bash
    # docker run 時に -v でマウントする
    docker run -it -v ~/.ssh:/root/.ssh my-image /bin/bash

    docker-compose.yml の場合

    services:
    myapp:
    image: my-image
    volumes:
    – ~/.ssh:/root/.ssh
    ``
    これにより、コンテナはホストの    known_hosts`や秘密鍵を直接利用できるようになります。

  • CI/CDパイプラインの場合:
    CI/CD環境では、対話的にyesと入力することができません。また、ジョブごとに環境がクリーンアップされるため、known_hostsを永続化するのは困難です。
    この場合、ssh-keyscan を使うのが一般的です。これは、指定したホストの公開鍵を取得して標準出力に表示するコマンドです。
    パイプラインのスクリプトの冒頭で、接続先ホストの鍵をあらかじめknown_hostsに追記しておきます。
    “`yaml
    # GitLab CI (.gitlab-ci.yml) の例
    before_script:

    • mkdir -p ~/.ssh
    • chmod 700 ~/.ssh
    • ssh-keyscan -H your.server.com >> ~/.ssh/known_hosts
    • chmod 600 ~/.ssh/known_hosts

    deploy_job:
    script:
    – ssh [email protected] “deploy script”
    ``
    **注意:**    ssh-keyscan`は初回接続時の「本当にこのサーバーは本物か？」という検証をスキップするため、理論的には中間者攻撃のリスクが残ります。信頼できるネットワーク内のCI/CDランナーから実行するなど、リスクを理解した上で使用してください。

  • SELinux/AppArmorによる制限の場合:
    これは高度なトピックですが、もしSELinuxが原因であると疑われる場合は、restoreconコマンドでファイルのセキュリティコンテキストをデフォルトに復元してみるのが第一歩です。
    bash
    # .sshディレクトリ以下のコンテキストを再帰的に復元
    restorecon -Rv ~/.ssh
    それでも解決しない場合は、/var/log/audit/audit.logを調査し、audit2allowなどのツールでカスタムポリシーを作成する必要があるかもしれません。専門的な知識が必要なため、ディストリビューションのドキュメントや専門家への相談を推奨します。

4. 【発展】より深い理解と高度なテクニック

エラーは解決しましたが、関連する知識を深めることで、今後のSSH利用がよりスムーズになります。

「REMOTE HOST IDENTIFICATION HAS CHANGED!」との違いを理解する

記事の冒頭で触れたこのWARNINGは、今回の「Failed to add…」とは意味が全く異なります。

  • Failed to add...: known_hostsファイルに書き込めない（クライアント側のパーミッション等の問題）。
  • REMOTE HOST IDENTIFICATION HAS CHANGED!: known_hostsに記録されている鍵と、サーバーが提示してきた鍵が一致しない（サーバー側の変更 or 中間者攻撃の可能性）。

後者の原因は、サーバーのOSを再インストールした、IPアドレスが同じ別のサーバーに変わった、などが一般的です。この警告が出た場合は、まずサーバー管理者にホストキーが変更されたかを確認し、問題なければ警告メッセージの指示通りssh-keygen -Rで古い鍵情報を削除してから再接続します。

known_hostsファイルの手動管理 (ssh-keygen -R)

ssh-keygen -f "/path/to/known_hosts" -R "hostname" コマンドは、指定したホストのエントリをknown_hostsファイルから削除します。ホストキーが正当な理由で変更された場合に非常に便利です。

ホストキーの自動追加 (ssh-keyscan) とそのリスク

前述の通り、ssh-keyscanはスクリプトなどでホストキーを非対話的に追加するのに使えます。
ssh-keyscan -H hostname >> ~/.ssh/known_hosts
StrictHostKeyCheckingオプションと組み合わせることで、様々な自動化シナリオに対応できますが、セキュリティリスクは常に念頭に置いてください。

SSH設定ファイル (~/.ssh/config) による挙動の制御

~/.ssh/configファイルを作成・編集することで、ホストごとにSSHクライアントの挙動を細かく制御できます。

  • StrictHostKeyChecking: ホストキーの検証をどう扱うかを設定します。

    • StrictHostKeyChecking ask (デフォルト): 初回接続時に尋ね、known_hostsにない場合は接続を許可しません。
    • StrictHostKeyChecking yes: known_hostsにホストキーがない、または変更されている場合、接続を拒否します。最も安全です。
    • StrictHostKeyChecking no: known_hostsにないホストキーを自動的に追加し、変更されていても警告のみで接続を試みます。セキュリティリスクが高いため、信頼できる内部ネットワークや一時的なテスト環境でのみ使用すべきです。
    • StrictHostKeyChecking accept-new: known_hostsにないホストキーを自動的に追加しますが、変更されている場合は接続を拒否します。askとnoの中間的な挙動です。

  • UserKnownHostsFile: known_hostsファイルの場所を指定します。

    • UserKnownHostsFile /dev/null: known_hostsを一切読み書きしないというハックです。全ての接続でホストキー検証を無視することになり、非常に危険なため、極めて特殊な状況以外では絶対に使用しないでください。この設定を行うと、「Failed to add…」エラーは出なくなりますが、問題の根本解決にはなっていません。

設定例 (~/.ssh/config):
“`

開発用の一時的なサーバーには甘めの設定

Host dev-server-*.example.com
StrictHostKeyChecking no
UserKnownHostsFile /dev/null

本番用の重要なサーバーには厳格な設定

Host production.example.com
StrictHostKeyChecking yes
“`

5. まとめ：トラブルシューティングの王道

「Failed to add the host to the list of known hosts」というエラーに遭遇した際のトラブルシューティング手順をまとめます。

  1. まず自分を疑う: このエラーはクライアント側の問題です。
  2. パーミッションを確認する: ls -la ~/.ssh を実行し、.sshディレクトリ (700)、known_hostsファイル (600 or 644)、そして所有者が自分自身になっているかを確認します。ほとんどの問題はここで解決します。
  3. コマンドを再確認する: sudoでSSHを実行していないか？ もしそうなら、それは意図した挙動か？
  4. 環境を疑う: コンテナやCI/CD環境か？ その環境特有のファイルシステムやユーザーの制約を考慮します。
  5. ファイルシステムを疑う: ディスクは満杯でないか？ 読み取り専用になっていないか？

このエラーは、SSHがセキュリティを維持するために、いかにファイルパーミッションを厳格にチェックしているかを示す良い例です。その背景を理解すれば、一見不可解なエラーも、実は論理的でシンプルな原因に基づいていることがわかります。

この記事が、あなたのSSHに関する悩みを解消し、より快適な開発・運用ライフの一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール