MENU
癒しと創作をまぜこぜに
  1. ホーム
  2. PC系
  3. sshd_configを変更しても反映されない原因と確認方法｜sshd -Tで実効設定を見る・Includeの順番・Matchの範囲・reload忘れ・PasswordAuthentication noでも残るkeyboard-interactive

sshd_configを変更しても反映されない原因と確認方法｜sshd -Tで実効設定を見る・Includeの順番・Matchの範囲・reload忘れ・PasswordAuthentication noでも残るkeyboard-interactive

PC系

こんにちは、おうどんです🍜

おうどん

ななみさん、sshd_config の一番下に PasswordAuthentication no と書いたよ。これで安心

ななみ

sshd -T の結果は見ましたか

おうどん

見たら yes だった。sshd が反抗期かもしれない

ななみ

反抗期ではなく、最初に聞いた話しか聞かない方なんです

（会話は説明用に作ったものです。設定の結果は今回の検証で実行したものです）

最初に聞いた話しか聞かない。
これが、sshd（SSH のサーバー）の設定でいちばん大事な性格です。

たとえるなら、sshd は頑固なうどん屋の店主です。

sshd「最初に『ネギ抜き』と聞いた。あとから『ネギ多め』と言われても知らん」

しかもこの店主、壁のメニューを貼り替えても、頭の中の注文は肩をたたくまで変わりません。
お客さんとしては、なかなか手ごわいお店です。

この記事では、sshd_config を変更しても反映されないときに、どこを見ればいいかを順番にまとめます。

検証は、今回の検証環境（Windows の Git Bash に入っている OpenSSH 9.7p1 の sshd）で行いました。自分で作った設定ファイルとホスト鍵を使い、待ち受けは 127.0.0.1 だけにしています。systemctl など Linux にしかない手順は、未実行と書いています。

まず覚えるのは、この3つだけです

  • 設定を読んだ結果は、ファイルを眺めずに sudo sshd -T で見る
  • 同じ項目は、先に書いたほうが勝つ（一番下に足しても効かないことがある）
  • ファイルを直しただけでは、動いている sshd は変わらない。sudo sshd -t で確かめてから reload する
目次

反映されないときは、4か所を上から見る

慌ててファイルを開き直す前に、見る場所を決めましょう。
店主に怒鳴り込む前に、まず伝票を確認するのと同じです。怒鳴り込むと出禁になります。サーバーの出禁は、本当に入れなくなるので笑えません。

症状ありがちな原因見るもの
sshd -T の値が書いた値と違う先に別の値が書いてある（sshd_config.d の中など）sshd -T、grep
特定のユーザーだけ違う、一部の人だけ効かないMatch の範囲に入っているsshd -T -C ...
sshd -T は正しいのに動きが変わらないreload していない、起動オプションが違うログ、接続して確かめる
パスワードを止めたのに、まだ聞かれるkeyboard-interactive が残っているssh で認証方式を聞く

最初に打つコマンドは、この2つです。どちらも確認用で、設定は変わりません。

sudo sshd -t                                        # 文法の確認。問題がなければ何も出ない
sudo sshd -T | grep -i '^passwordauthentication'    # 読んだ結果の確認

（sudo つきのこの2行は、Linux のサーバーで打つときの形で、今回は未実行です。パスが通っていなければ /usr/sbin/sshd と書きます）

sshd のマニュアルによると、-t は設定ファイルの妥当性と鍵を確認するテストモード、-T はそれに加えて、読み込んだ結果を表示するモードです。

今回の 9.7p1 では、-T の出力の項目名は小文字でした。設定ファイルと同じ PasswordAuthentication の表記で探すと見つからないため、ここでは grep -i を付けています。
見つからないからといって、sshd に無視されたわけではないです。無視されるのは、これからの話です。

おうどん

ファイルは3回読み直したよ。ちゃんと書いてある

書いてあることと、読まれたことは別です。この記事の話は、ほぼこの一言で終わります。

先に書いた値が勝つ：一番下に書いても効かない理由

店主の性格そのものです。
sshd_config のマニュアルには、「特に断りがなければ、項目ごとに最初に得られた値を使う」とあります。

同じ項目を2回書いて、試してみます。

HostKey ./hostkey
PasswordAuthentication yes
PasswordAuthentication no
sshd -T -f ./sshd_config | grep -i '^passwordauthentication'
passwordauthentication yes

後ろの no は、エラーにもならず、黙って無視されました。
後ろの値が勝つ設定ファイルに慣れていると、ここで転びます。

sshd「最初に yes と聞いた」

おうどん

すぐ下に no って書いてあるよ

sshd「読んだ。聞いてはいない」

読んだのに聞いていない。会議で一番やってはいけないやつです。

もう1つ、よくある見落としがコメントです。

HostKey ./hostkey
#PasswordAuthentication no
passwordauthentication yes

先頭の # を消し忘れると、ただのコメントなので既定値の yes のままです。
メニューに鉛筆で書いたメモは、店主には見えていません。

sshd_config.d のほうが先に読まれる：別冊が本体に勝つ

ここが、一番下に書いても効かない最大の原因です。

Debian や Ubuntu の sshd_config は、先頭で Include /etc/ssh/sshd_config.d/*.conf を読み込みます。Debian のマニュアルには、このファイル群は設定ファイルの最初で読み込まれるので、本体の値より優先されるとはっきり書いてあります。

つまり、メニューの表紙の裏に別冊が綴じてあって、店主はそちらを先に読みます。

Include は OpenSSH 8.2 で 追加された項目です。再現してみましょう。

Include /path/to/lab/conf.d/*.conf
HostKey ./hostkey
PasswordAuthentication no

conf.d/50-cloud-init.conf の中身です。

PasswordAuthentication yes
passwordauthentication yes

（Include のパスの一部を伏せています。読み込むフォルダは、サーバーの /etc/ssh/sshd_config.d/ にあたります）

本体の no が負けました。
これが、冒頭のおうどんに起きていたことです。別冊の存在を知らずに本体だけ直していたわけで、店主は悪くありません。おうどんが悪い。

実際のサーバーでは、grep で書かれている場所を全部出します。

sudo grep -rin '^[[:space:]]*passwordauthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

別の場所に検証用のフォルダを作って同じ形で実行すると、次のように出ます。

etc/ssh/sshd_config:3:PasswordAuthentication no
etc/ssh/sshd_config.d/50-cloud-init.conf:1:PasswordAuthentication yes

ただし、この順番は grep の順番で、sshd の読む順番ではありません。読む順番は、本体の Include の位置で決まります。

別冊を足すなら、ファイル名の順番にも注意します。複数のファイルは文字の順番（lexical order）で処理され、先に読まれたほうが勝ちます。50-cloud-init.conf に yes がある状態で、no を書いた自分のファイルの名前を変えて試しました。

自分のファイルの名前sshd -T の結果なぜ
10-my.confno1 は 5 より前
99-my.confyes9 は 5 より後ろ
9-my.confyes1文字目の 9 で比べるので、50 より後ろ
09-my.confno1文字目の 0 で比べるので、50 より前
新人

大事な設定だから 99 番にしておきました！

大きい番号がエースだと思う気持ちは分かります。でもこの店では、後ろの背番号は補欠です。

ファイルと動いている sshd は別物：reload するまで変わらない

ここまでの sshd -T は、ファイルを読んだ結果です。動いている sshd に聞いているわけではありません。

壁のメニューと、店主の頭の中は別物。
これを実際に見ます。PasswordAuthentication yes で sshd を起動し、外から認証方式を聞きました。-o PreferredAuthentications=none は、認証を試さずにサーバーの返事だけもらう書き方です。

ssh -p 22024 -o BatchMode=yes -o PreferredAuthentications=none \
    -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=ERROR \
    labuser@127.0.0.1 true
labuser@127.0.0.1: Permission denied (publickey,password,keyboard-interactive).

かっこの中が、今この sshd が受け付ける認証方式です。password があります。
次に、ファイルを no に書き換えて、reload せずに同じことをします。

labuser@127.0.0.1: Permission denied (publickey,password,keyboard-interactive).

sshd -T では、もう no です。

passwordauthentication no
kbdinteractiveauthentication yes

ファイルは no、動いている sshd は password を受け付ける。どちらも嘘をついていません。
ここで SIGHUP（設定の読み直しを頼むシグナル）を送ります。sshd のマニュアルによると、sshd は SIGHUP を受けると、自分を実行し直して設定を読み直します。

kill -HUP "$PID"
labuser@127.0.0.1: Permission denied (publickey,keyboard-interactive).

password が消えました。
店主の肩をたたいて、やっとメニューを読み直してもらえたわけです。そのとき、ログには次の行が残っていました。

Received SIGHUP; restarting.
Server listening on 127.0.0.1 port 22024.

Linux のサーバーでは、ふつう kill ではなく systemctl で読み直します。サービス名は Debian・Ubuntu が ssh、RHEL 系が sshd です（未実行）。

sudo sshd -t && sudo systemctl reload ssh     # Debian・Ubuntu
sudo sshd -t && sudo systemctl reload sshd    # RHEL 系

reload と restart の違いや、reload の中身は OS の設定しだいなので、systemctl cat ssh で確かめておくと安心です。

ところで、上の確認方法は、-p と宛先を変えれば本物のサーバーにも使えます。その場合、認証の失敗としてサーバーのログに1回残ることと、Match がある場合は結果がユーザーで変わることだけ気をつけてください。

おうどん

つまり、ファイルを保存して満足していた

ななみ

はい。メニューを貼り替えて、店主に言わずに帰った状態です

帰宅したあとで注文が通らない店。困るのはお客さんです。

🔰 ここまで読めば今日から困らない

  • sudo sshd -T | grep -i '^項目名' で、読んだ結果を見る
  • 違っていたら、sshd_config と sshd_config.d を grep で探す。先に読まれた値が勝つ
  • 直したら sudo sshd -t で確かめてから reload する
  • -T はファイルの結果。動いている sshd の確認は、接続して確かめる
おうどん

よし、今日はここで帰っていい？

帰って大丈夫です。出口はあちらです。ただ、店の奥には予約席があります。

よくある原因の多くは、ここまでで見つかります。
ここから先は中級者向けです。読み飛ばしてもOKです。Match、パスワードが消えない話、安全な変更手順に進みます。

中級：Match のあとに書き足すと、予約席に吸い込まれる

一番下に足すのが危ない理由が、もう1つあります。

Match は、条件に合う接続だけ設定を変える項目です。マニュアルによると、その効き目は「次の Match か、ファイルの終わりまで」続きます。

つまり、Match は予約席の札です。札を置いたあとに並べた席は、全部予約席になります。
ファイルの最後に Match があるところへ1行足すと、こうなります。

HostKey ./hostkey
Match User deploy
    X11Forwarding yes
ClientAliveInterval 300

最後の1行は字下げされていません。でも字下げは飾りです。

sshd -T -f ./sshd_config | grep -i -E '^clientaliveinterval|^x11forwarding'
sshd -T -f ./sshd_config -C user=deploy,host=client.example,addr=192.0.2.10 | grep -i -E '^clientaliveinterval|^x11forwarding'
sshd -T -f ./sshd_config -C user=udon,host=client.example,addr=192.0.2.10 | grep -i -E '^clientaliveinterval|^x11forwarding'
clientaliveinterval 0
x11forwarding no
clientaliveinterval 300
x11forwarding yes
clientaliveinterval 0
x11forwarding no

全員に効かせたつもりの ClientAliveInterval 300 が、deploy だけに効いています。
sshd -t は文法だけ見るので、これを通します（終了コード 0）。文法は合っています。注文の取り方が間違っているだけで。

対処は、全員向けの設定を最初の Match より上に書くことです。今回の検証では、途中に Match all を書いても、その下が全員に効きました。

HostKey ./hostkey
Match User deploy
    X11Forwarding yes
Match all
ClientAliveInterval 300
clientaliveinterval 300

（-C user=udon,host=client.example,addr=192.0.2.10 を付けて実行した結果です）

Port のように Match の中で使えない項目なら、エラーで教えてくれます。

./sshd_config line 4: Directive 'Port' is not allowed within a Match block

こちらは親切です。黙って予約席に座らせるより、「そこは座れません」と言ってくれる店員のほうが、ずっと助かります。

-C の条件が足りないと、Match が黙って外れる

Match の確認には -C を使いますが、条件の渡し忘れに注意です。アドレスで分ける設定を作りました。

HostKey ./hostkey
Match Address 192.0.2.0/24
    PasswordAuthentication no
Match User deploy
    PasswordAuthentication yes
-C の指定結果
user=deploy,host=client.example,addr=192.0.2.10no（最初の Match に合う）
user=deploy,host=client.example,addr=198.51.100.10yes（2番目の Match に合う）
user=deploy（addr なし）yes

3行目が落とし穴です。addr を渡していないので Match Address が外れ、エラーも出ません。今回の OpenSSH 9.7p1 では、Match User がある設定に addr だけを渡したときも同じくエラーは出ませんでした。
そして -C を付けないと、Match の中身は結果に入りません。

確認するときは、user・host・addr をそろえて渡す。これを習慣にしましょう。
テスト用の伝票に席番号を書き忘れると、店主は「なら予約席じゃないな」で通します。融通がきくのか、きかないのか。

複数の Match に合うときは、マニュアルのとおり最初のものが使われます。上の1行目も、同じ PasswordAuthentication で先に合ったほうの no になっています。

中級：PasswordAuthentication no なのに、パスワードらしきものを聞かれる

これも、設定が効いていないように見える定番です。
さきほどの実験をもう一度見てください。PasswordAuthentication no のあとの返事はこうでした。

labuser@127.0.0.1: Permission denied (publickey,keyboard-interactive).

password は消えましたが、keyboard-interactive が残っています。
これはサーバーがキーボードから入力を求める別の方式で、KbdInteractiveAuthentication という別の項目で決まります。マニュアルの既定値は yes です。

同じページの UsePAM の説明によると、PAM（Linux の認証を部品にした仕組み）を有効にすると、keyboard-interactive と password の両方で PAM の認証が動きます。キーボード対話の認証がパスワードと同じ役目をすることも多いので、片方を無効にするよう案内されています。

玄関を閉めたのに、勝手口が開いていた、というやつです。

おうどん

玄関に『閉店』と書いたのに、まだお客さんが入ってくる

sshd「勝手口は別の担当です」

担当を分けないでほしい。

なお、Debian のパッケージは KbdInteractiveAuthentication no を標準の設定に入れています（同じページの記載）。また、cloud-init の Set Passwords のドキュメントには、PAM を使うイメージでは PasswordAuthentication no だけでは足りないことがあるとして、sshd_config.d に KbdInteractiveAuthentication no を書く例が載っています。

パスワードを止めたいなら、両方の値を見ます。

sudo sshd -T | grep -i -E '^(passwordauthentication|kbdinteractiveauthentication)'

中級：別冊に書いて、確かめて、読み直す手順

ここまでをまとめて、変更の手順にします。例は、パスワードの入口を止める変更です。Ubuntu のサーバーを想定した形で、今回は未実行です。

  • 前提：公開鍵でログインできることを、別の端末で確認済み。sshd_config.d が読み込まれている（本体の Include を確認済み）
  • 影響範囲：これから接続する人全員。パスワードで入っている運用の人は入れなくなる
  • 反映時期：reload したとき。接続中の人はそのまま
  • 作業中：今のログインを閉じない。確認が終わるまで残しておく

今のログインは命綱です。終わった気になって先に閉じるのは、命綱を外してから足場を確かめる順番です。

# 1. 今の結果を控える
sudo sshd -T > /tmp/sshd-before.txt

# 2. 既存のファイルより前に読まれる名前で書く
sudo tee /etc/ssh/sshd_config.d/10-no-password.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF

# 3. 文法を確かめ、変わった項目だけ見る
sudo sshd -t
sudo sshd -T > /tmp/sshd-after.txt
diff /tmp/sshd-before.txt /tmp/sshd-after.txt

# 4. 読み直す
sudo systemctl reload ssh

変更後の確認は、今のログインを残したまま、別の端末から新しく接続します。

ssh -o BatchMode=yes -o PreferredAuthentications=none ユーザー名@サーバー true

かっこの中から password と keyboard-interactive が消えていて、公開鍵でも入れれば完了です。

戻すときは、追加したファイルを消して、また sudo sshd -t と reload をします。

diff の部分は、検証環境でも -f を付けて試しました。別冊に PasswordAuthentication yes を足す前後の比較です。

26c26
< passwordauthentication no
---
> passwordauthentication yes

変わった1行だけが出ます。85 行の結果を目で比べなくて済むので、人間にやさしい。
OS やパッケージの更新の前後に同じ比較をしておくと、「更新で何か変わった？」にもすぐ答えられます。

新人

まとめて全部いっぺんに直して、最後に確認すればいいですね

丼に全部入れてから味見する方式です。しょっぱかったとき、どれが原因か分かりません。

中級：書かれている場所を読む順に並べるスクリプト

新人

grep に出た順に読むんじゃないんですか

grep は受付の名簿係で、店主の読む順は知りません。

そこで、Include をたどって読む順に並べるスクリプトを作りました。

#!/usr/bin/env bash
# sshd_where.sh: キーワードが書かれた場所を、sshd が読む順に並べる
# 使い方: ./sshd_where.sh PasswordAuthentication [設定ファイル]
set -u
key="${1:?キーワードを指定してください}"
conf="${2:-/etc/ssh/sshd_config}"
export LC_ALL=C    # ファイル名の並びを文字コード順にそろえる
in_match=no

walk() {
  local file="$1" no=0 line word rest pat f saved="$in_match"
  while IFS= read -r line || [ -n "$line" ]; do
    no=$((no + 1))
    read -r word rest <<< "$line"
    case "${word,,}" in
      ''|'#'*) continue ;;
      match) in_match=yes ;;
      include)
        for pat in $rest; do     # ワイルドカードを広げたいのでクォートしない
          case "$pat" in /*) ;; *) pat="/etc/ssh/$pat" ;; esac
          for f in $pat; do
            [ -f "$f" ] && walk "$f"
          done
        done
        ;;
      "${key,,}")
        if [ "$in_match" = yes ]; then
          printf '%s:%s: [Match内] %s\n' "$file" "$no" "$line"
        else
          printf '%s:%s: %s\n' "$file" "$no" "$line"
        fi
        ;;
    esac
  done < "$file"
  in_match="$saved"  # 読み込まれた側の Match は、そのファイルの終わりで閉じる
}

walk "$conf"

検証用に、50-cloud-init.conf（yes）、Match 入りの 60-deploy.conf、Match 入りの本体を用意して実行しました。

bash ./sshd_where.sh PasswordAuthentication ./sshd_config
sshd_config.d/50-cloud-init.conf:1: PasswordAuthentication yes
sshd_config.d/60-deploy.conf:2: [Match内]     PasswordAuthentication no
./sshd_config:4: PasswordAuthentication no
./sshd_config:7: [Match内]     PasswordAuthentication no

（ファイルのパスの一部を削って表示しています）

[Match内] の付いていない最初の行が、全員に効く値です。sshd -T の結果も passwordauthentication yes で、一致しました。
本体の4行目が負けている理由が、1画面で分かります。

これは場所を探す道具で、答えを決めるのは sshd -T です。キーワード=値 の書き方や、クォートした Include のパスには対応していません。本物の店主の代わりは務まらない、見習いの出前持ちくらいに思ってください。

ここから先は上級者向け。読み飛ばしてもOKです。壊れた設定で reload したとき、OS ごとの設定経路、Include の細かい動きを見ます。

上級：壊れた設定で reload すると、待ち受けが消える

sshd -t を飛ばして SIGHUP を送ると、どうなるか。動いている sshd に、打ち間違いを入れた設定を読ませました。-D で手動起動した sshd を、Git Bash の kill -HUP で読み直しています。

事前に、別の接続を1本つないだまま残しておきます。

-- sshd -t
<lab>/sshd_config: line 8: Bad configuration option: PasswordAuthentcation
<lab>/sshd_config: terminating, 1 bad configuration options
t-exit=255
-- new connection
connect failed: ConnectionRefusedError
listener-alive=1
--- held connection
SSH-2.0-OpenSSH_9.7 kitsune-v3
held connection: received 1072 bytes after listener change

（<lab> はパスを置き換えたものです。listener-alive=1 は待ち受けのプロセスがいなくなったことを示す検証用の表示です）

新しい接続は拒否され、待ち受けのプロセスは終了しました。一方、つないでいた接続は生きていて、続きのデータを受け取れています。
ログには、次の3行が続いていました。

Received SIGHUP; restarting.
<lab>/sshd_config: line 8: Bad configuration option: PasswordAuthentcation
<lab>/sshd_config: terminating, 1 bad configuration options

理由は sshd の作りにあります。マニュアルによると、待ち受けの sshd は接続ごとに新しいプロセスを fork（分身を作る）し、鍵交換や認証などはその子プロセスが担当します。SIGHUP は自分を実行し直すので、読めない設定だと親だけが終わり、接続中の子は残ります。

店主が新しいメニューを読もうとして倒れた。でも、席のお客さんはそのまま食べ続けている。
ただし次のお客さんは入れません。ここで今のログインまで閉じると、遠隔のサーバーなら歩いて行く羽目になります。うどんを持って。

これが、sshd -t と「今のログインを閉じない」が大事な理由です。

今回は systemd の下で動かしていないので、Restart= の設定や、ユニットの ExecReload に sshd -t が入っている場合の動きは確かめていません。実際のサーバーでの動きは systemctl cat で確認してください。

同じ実験で、正しい設定の SIGHUP も確かめています。Port を変えて SIGHUP を送ると、古いポートは拒否され、新しいポートで待ち受けました。接続中だった接続は、SIGHUP のあとも切れず、古いバナー（接続時に出る名乗り）のまま続きました。

上級：Ubuntu の Port は sshd だけの話ではない

Ubuntu 22.10 以降は、ssh がソケットアクティベーションで動くようになりました。接続が来てから sshd を起動する方式で、待ち受けるのは systemd の ssh.socket です。店の前で、呼び込みの人が代わりに立っている状態ですね。

24.04 LTS では、ポートとアドレスの設定は systemd の generator（設定を生成する小さなプログラム）が sshd の設定から取り込む、と説明されています。

そのため、Ubuntu の不具合報告にあるとおり、24.04 で Port を変えて ssh.service を再起動しても、22 番で待ち受けたままになります。報告の回答にある手順はこちらです（未実行）。

sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

対象は Port、AddressFamily、ListenAddress です。この修正で、既定の sshd_config にコメントが足されました。挙動そのものは変わっていません。

呼び込みの人に「店の場所が変わった」と言わないと、呼び込みは元の場所で立ち続けます。律儀な人です。

Ubuntu では、もう1つ 50-cloud-init.conf にも注意です。Ubuntu の不具合報告によると、ISO からインストールした Ubuntu Server 24.04 で、このファイルの PasswordAuthentication yes が本体を上書きする例が報告されています。cloud-init 側の説明は、ssh の明示的な設定を sshd_config.d に書くというものです。

上級：更新で置き換わるもの、自分で持つもの

「更新で設定が変わるのでは」という心配は、どのファイルを誰が持っているかで整理できます。
持ち主が別にいるファイルへ手で書き足すのは、隣の店のメニューに落書きするようなものです。翌朝、きれいに貼り替えられています。

ファイル持ち主手を入れるなら
/etc/ssh/sshd_configパッケージ更新時に差分の確認を求められることがある（Debian・Ubuntu の場合）
50-cloud-init.conf などcloud-init などの生成元生成元の設定（ssh_pwauth など）も見る
/etc/crypto-policies/back-ends/opensshserver.configupdate-crypto-policies（RHEL 系）直接編集しない
自分で足した 10-*.conf自分名前と中身を記録しておく

cloud-init の ssh_pwauthは、true で有効、false で無効、未設定なら今の値を変えません。

RHEL 9 の暗号ポリシーと 50-redhat.conf の関係は、RSA 鍵で接続できない話の記事に書きました。先に読まれたほうが勝つので、暗号の設定を書くなら読む順番が問題になります。Fedora の不具合報告では、この順番の難しさが議論され、Fedora 39 のパッケージでファイルが分けられました。同じ構成が RHEL の版にあるとは限らないので、実機の sshd_config.d を見てください。

弱いアルゴリズムを許す設定を別冊に足せば動くこともありますが、それを恒久対策の第一候補にはしないでください。うどんが伸びたからといって、賞味期限のラベルを貼り替える話になってしまいます。

上級：Include と複数値の細かい動き

今回の OpenSSH 9.7p1 で確かめた、細かい動きをまとめます。

試したこと結果
Include のパスを打ち間違えた（ワイルドカードあり）エラーなし、sshd -t の終了コード 0
存在しないファイルを Include した（ワイルドカードなし）同じくエラーなし、終了コード 0
Include を本体の一番下に書いた本体の値が勝つ
Include を Match の中に書いた合う接続だけ、読み込んだ値が効く
読み込んだファイルの中の Matchそのファイルの終わりで閉じ、本体の次の行は全員に効く
PasswordAuthentication No（大文字の値）受け付けた（マニュアルは「値は大文字小文字を区別」と説明）
PasswordAuthentcation no（打ち間違い）エラー、終了コード 255
-T の起動オプションに -o PasswordAuthentication=no設定ファイルより優先

いちばん怖いのは1行目です。別冊のフォルダ名を間違えても、sshd は何も言いません。
Include の打ち間違いだけ黙っているのは、見なかったことにする店主の優しさでしょうか。おかげで、こちらは静かに困ります。

また、相対パスの Include は /etc/ssh からの相対として扱われます。

「最初の値が勝つ」には例外があります。マニュアルに「特に断りがなければ」と書いてあるとおりです。次の設定で試しました。

HostKey ./hostkey
Port 2222
Port 2223
AllowUsers udon
AllowUsers nanami
AcceptEnv LANG
AcceptEnv TZ
MaxAuthTries 3
MaxAuthTries 6
port 2222
port 2223
maxauthtries 3
allowusers udon
allowusers nanami
acceptenv LANG
acceptenv TZ

MaxAuthTries は最初の値だけ、Port・AllowUsers・AcceptEnv は足されていきました。項目によって性格が違います。同じ店主でも、トッピングは全部聞いてくれるらしい。

もう1つ、sshd -T にも限界があります。マニュアルのとおり、コマンドラインの指定は設定ファイルより優先されます。サービスが -f や -o 付きで起動しているなら、確認にも同じ指定が必要です。

版による違いも1つ。OpenSSH 9.8 で、接続ごとの処理は sshd-session という別のプログラムに分かれ、10.0 では認証の部分が sshd-auth に分かれました（リリースノート）。ログの名前が変わることがあるので、sshd だけで探していると見落とします。

冒頭の店に戻ると

冒頭のおうどんは、一番下に1行足して安心していました。
今なら、やることは決まっています。

ななみ

別冊を調べて、読む順を確かめて、肩をたたく。ちゃんとできましたね

おうどん

えらい？

ななみ

えらいです。今回は、今のログインも閉じていませんでしたから

書いた場所ではなく、読んだ結果を確かめる。
sshd の設定で迷ったら、これだけ覚えて帰ってください。

頑固な店主も、順番さえ分かれば、ちゃんと美味しいうどんを出してくれます🍜

参考資料

2026年11月時点の内容です。

PC系
cloud-init Include KbdInteractiveAuthentication Match OpenSSH PasswordAuthentication SSH ssh.socket sshd sshd -T sshd_config インフラ
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

おうどんのアバター おうどん

おうどん｜癒しと創作をたのしむ雑食クリエイター
写経アプリやクレイセラピー、優しい和風デザインがすき。
ZARDと刀剣と文字に癒されて、今はアプリ作ってます。

関連記事

コメント

コメントする

目次