SSH接続の仕組み徹底解説：sshとsshdの違い・どの鍵ファイルをどこに置くか・.ssh の権限と所有者【番外編】

新サーバの最初の作業：SSH 公開鍵認証を設定する の番外編です。

鍵認証の手順どおりにやったのに「なんか繋がらない」「鍵は作ったけど、どのファイルがどこで読まれているのか分からない」——SSH でつまずくときの原因は、ほぼ次の3つに集約されます。

1. ssh（クライアント）と sshd（サーバ）を混同している
2. 鍵ファイルを置く場所・読まれる仕組みを理解していない
3. ~/.ssh の権限と所有者が正しくない

この記事は手順書ではなく、**「仕組みを理解して、繋がらないときに自力で原因を切り分けられるようになる」**ことを目的にしています。

1. まず：ssh と sshd は別物

ここが一番の躓きポイントです。名前は似ていますが、役割も・動くマシンも・読むファイルも違います。

flowchart LR
    subgraph 手元PC["手元のPC（接続元）"]
        A["ssh コマンド<br/>~/.ssh/config<br/>秘密鍵 id_ed25519"]
    end
    subgraph サーバ["接続先サーバ"]
        B["sshd デーモン<br/>/etc/ssh/sshd_config<br/>公開鍵 ~/.ssh/authorized_keys"]
    end
    A -- "TCP 22番ポート" --> B

2. クライアント側（ssh）が読むファイル

手元で ssh user@host と打つと、ssh は次のファイルを順に見ます。すべて接続元PCの ~/.ssh/ にあります。

~/.ssh/                     # 手元PC側
├── config                 # 接続先ごとの設定（Host エイリアス）
├── id_ed25519             # 秘密鍵（絶対に外に出さない）
├── id_ed25519.pub         # 公開鍵（サーバに登録する元データ）
└── known_hosts            # 接続したサーバの指紋を記録

2-1. ~/.ssh/config — 接続先ごとの設定

毎回 -i や -p を打たなくて済むよう、接続先を名前で定義しておけます。

Host myserver
    HostName     192.168.1.10
    User         alice
    Port         22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

これで ssh myserver だけで繋がります。

2-2. どの秘密鍵が使われるのか

鍵を指定しないと、ssh は デフォルト名の鍵（id_ed25519 → id_ecdsa → id_rsa …）を順に試し、さらに ssh-agent に登録された鍵も総当たりします。

2-3. known_hosts — サーバの指紋

初回接続時に出る「The authenticity of host ... can't be established」で yes と答えると、サーバの公開鍵指紋が known_hosts に記録されます。サーバを再インストールすると指紋が変わり、次回 REMOTE HOST IDENTIFICATION HAS CHANGED! の警告が出ます。正当な再構築だと分かっている場合だけ、古い行を削除します。

ssh-keygen -R 192.168.1.10

3. サーバ側（sshd）が読むファイル

接続を受ける側の設定です。接続先サーバの /etc/ssh/ にあります。

/etc/ssh/
├── sshd_config            # サーバ本体の設定
└── sshd_config.d/         # 分割設定（*.conf を読み込む）
    └── 50-redhat.conf     # ディストリ既定（RHEL系）

3-1. sshd_config と分割ファイルの読み込み順

最近の Rocky / RHEL 系は、sshd_config の冒頭に次の一行があり、sshd_config.d/*.conf を先に読み込みます。

# 冒頭付近
Include /etc/ssh/sshd_config.d/*.conf

3-2. 実際に効いている設定を確認する（最重要コマンド）

ファイルを目で追うより、sshd が解釈した最終的な値を出すのが確実です。

sudo sshd -T | grep -Ei 'port|passwordauthentication|pubkeyauthentication|permitrootlogin|authorizedkeysfile|strictmodes'

port 22
permitrootlogin prohibit-password
pubkeyauthentication yes
passwordauthentication no
authorizedkeysfile .ssh/authorized_keys
strictmodes yes

3-3. AuthorizedKeysFile — サーバが公開鍵を探す場所

既定値 authorizedkeysfile .ssh/authorized_keys は、ログインしようとするユーザのホームディレクトリからの相対パスです。つまり alice でログインするなら：

/home/alice/.ssh/authorized_keys

このファイルに、手元の公開鍵（id_ed25519.pub の中身）が1行ずつ入っていて、接続時に手元の秘密鍵と照合されます。

4. 公開鍵認証は結局どう照合されるのか

「秘密鍵と公開鍵をどこに置けば、どのサービスがどう読むのか」を一枚にまとめると、こうなります。

sequenceDiagram
    participant C as ssh（手元PC）
    participant S as sshd（サーバ）
    C->>C: ~/.ssh/config を読み、使う秘密鍵を決定
    C->>S: 22番ポートへ接続、「この公開鍵で入りたい」と提示
    S->>S: /home/ユーザ/.ssh/authorized_keys に<br/>その公開鍵があるか探す
    S->>C: あった→「秘密鍵を持ってる証明をして」と乱数を送る
    C->>C: 手元の秘密鍵 id_ed25519 で署名
    C->>S: 署名を返す
    S->>S: authorized_keys の公開鍵で署名を検証
    S->>C: 検証OK → ログイン許可

ポイントは、秘密鍵はサーバに渡らないことです。サーバへ置くのは公開鍵だけ。秘密鍵は手元から一歩も出ず、「持っていることの証明（署名）」だけがやり取りされます。

5. 繋がらない原因の筆頭：~/.ssh の権限と所有者

ここが**「鍵は正しいのに弾かれる」の最頻出原因です。sshd は StrictModes yes（既定）のとき、.ssh や鍵ファイルの権限が緩い／所有者が違うと、認証情報を読まずに拒否**します。セキュリティ上わざとそうなっています。

5-1. 正しい権限・所有者の一覧

ユーザ alice の例（所有者は本人、グループ・その他には書き込ませない）。

/home/alice/                       # 700 または 750、所有者 alice
└── .ssh/                          # 700 (drwx------)  所有者 alice
    ├── authorized_keys            # 600 (-rw-------)  所有者 alice
    ├── id_ed25519                 # 600 (-rw-------)  所有者 alice（手元PC側）
    ├── id_ed25519.pub             # 644 (-rw-r--r--)
    └── known_hosts                # 644 (-rw-r--r--)

5-2. 所有者を正す

root で作業して .ssh を作ってしまった等で所有者がズレていると、これも拒否されます。本人所有に直します。

sudo chown -R alice:alice /home/alice/.ssh

5-3. まとめて正す定番コマンド

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/*.pub 2>/dev/null
chown -R "$(id -un):$(id -gn)" ~/.ssh

5-4. Rocky / RHEL 系は SELinux のラベルも

権限・所有者が完璧なのに繋がらない場合、SELinux のファイルラベルがずれている可能性があります（バックアップから .ssh を復元した・別の場所から mv した等で起きがち）。正しいラベルへ戻します。

restorecon -Rv ~/.ssh

6. 「なんか繋がらない」を切り分ける

仕組みが分かれば、ログを見て原因を特定できます。クライアント側とサーバ側、両方のログを見るのがコツです。

6-1. クライアント側：-v で詳細表示

ssh -v myserver

-v（さらに -vv -vvv）で、どの鍵を試したか・どの認証方式で蹴られたかが見えます。

6-2. サーバ側：sshd のログ

サーバ側では systemd ジャーナルに理由が出ます。

sudo journalctl -u sshd -n 50 --no-pager

Authentication refused: bad ownership or modes for directory /home/alice/.ssh

この bad ownership or modes がまさに 5章の権限・所有者問題のサインです。

6-3. 症状別の早見表

sudo sshd -t && sudo systemctl reload sshd

まとめ

「なんとなく鍵を作って authorized_keys にコピーしたら繋がった」で止めず、どのファイルを誰が読んでいるかを一度きちんと把握しておくと、繋がらないときの不安がぐっと減ります。

基本の設定手順は 新サーバの最初の作業：SSH 公開鍵認証を設定する を、初期化直後にうまく繋がらない Kagoya 特有の現象は Kagoyaでサーバを初期化するとSSHが繋がらない問題 もあわせてどうぞ。