EC2上のLinuxでSSHのパスワード認証を有効にしようとして、/etc/ssh/sshd_config の設定を変更しました。
PasswordAuthentication yesこれでパスワード認証ができると思ったのですが、うまくいきません。
設定ファイルを見直しても、確かにyesになっています。
「設定を変えたのになぜ？」
と調べてみると、sshd_config以外にもSSHの設定ファイルが存在していました。
今回は、実際にEC2を使っていて遭遇したこの問題と、確認した内容を記録しておきます。
PasswordAuthenticationはyesになっている
まず/etc/ssh/sshd_configを確認しました。
sudo grep "PasswordAuthentication" /etc/ssh/sshd_config設定は、
PasswordAuthentication yesとなっています。
それでもパスワード認証ができません。
そこで、/etc/ssh/以下に同じ設定が存在していないか調べてみました。
sshd_config.dも確認する
次のコマンドで、PasswordAuthenticationが記述されている場所をまとめて検索できます。
sudo grep -R "PasswordAuthentication" \
/etc/ssh/sshd_config \
/etc/ssh/sshd_config.d/今回の環境では、次のような結果になりました。
/etc/ssh/sshd_config:PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication nosshd_configではyesなのに、
/etc/ssh/sshd_config.d/50-cloud-init.confには、
PasswordAuthentication noという設定が存在しています。
つまり、sshd_configだけを見ていては、SSHに関係する設定をすべて確認できていませんでした。
実際に有効になっている設定を確認する
設定ファイルを一つずつ確認するだけでなく、sshdが最終的にどの設定を使用しているか確認する方法もあります。
sudo sshd -T | grep -i passwordauthenticationたとえば、
passwordauthentication noと表示されれば、現在のsshdではパスワード認証が無効として解釈されています。
設定ファイルを書き換えたのに思ったように動かない場合は、sshd -Tで有効な設定を確認すると原因を探しやすくなります。
sshd_configだけを見ない
今回のポイントは、
/etc/ssh/sshd_configだけではなく、
/etc/ssh/sshd_config.d/以下にも設定が存在する場合があることでした。
SSHの設定で想定した動作にならないときは、
sudo grep -R "PasswordAuthentication" \
/etc/ssh/sshd_config \
/etc/ssh/sshd_config.d/で設定箇所を探し、
sudo sshd -T | grep -i passwordauthenticationで実際に有効になっている値を確認する、という流れが使えそうです。
設定を変更したらsshdに反映する
`PasswordAuthentication` の設定を変更しただけでは、現在動いているsshdには設定変更が反映されません。
そこで、設定を変更したあとはsshdに設定を読み直してもらう必要があります。
ただし、いきなりsshdを再起動するのは少し怖いところです。SSHで接続して作業している場合、設定ファイルにミスがあると、新しくSSH接続できなくなる可能性があります。
まずは設定ファイルに問題がないか確認します。
“`bash
sudo sshd -t
何も表示されなければ、少なくともsshdが検出できる構文エラーはありません。
そのうえで設定を反映します。
今回の環境では、次のようにsshdを再起動しました。
sudo systemctl restart sshd状態も確認しておきます。
sudo systemctl status sshdrestartではなくreloadでもよい？
sshdの設定変更を反映する方法として、restartのほかにreloadもあります。
sudo systemctl reload sshdrestartはsshdのサービスをいったん停止して起動し直すのに対して、reloadはサービス自体を停止せずに設定を読み直します。
SSHでリモートサーバーを操作していることを考えると、設定変更の反映だけが目的ならreloadを使う方法もあります。
ただし、利用しているLinuxディストリビューションやサービス定義によって、サービス名やreloadへの対応が異なる場合があります。
そのため、
systemctl status sshdなどでサービスの状態を確認してから操作するのが確実です。
また、Ubuntuなどではサービス名がsshdではなくsshとなっている環境もあります。
sudo systemctl reload sshこのあたりも、EC2で使用するAMIによって違いがあるのか、今後実際に確認して追記していきたいところです。
SSH接続は残したまま確認する
SSHの設定変更では、現在接続しているターミナルをすぐに閉じないことも大切です。
設定を反映したあと、別のターミナルを開いて新しくSSH接続してみます。
新しい接続でも問題なくログインできることを確認してから、元のSSH接続を終了します。
今回のような作業なら、次の流れで確認すると安全です。
設定ファイルを編集
↓
sudo sshd -t
↓
sudo systemctl reload sshd
↓
sudo sshd -T で有効な設定を確認
↓
別のターミナルからSSH接続を確認このように、設定ファイルを書き換えてすぐに接続を切るのではなく、構文チェック、設定の反映、有効な設定の確認、新規接続の確認という順番で進めることで、設定変更によって自分自身をサーバーから締め出してしまうリスクを減らせます。
EC2ではAMIによる違いもありそう
今回この問題に遭遇して気になったのが、EC2で使用するAMIによってSSHの初期設定がどの程度違うのかということです。
EC2では、Ubuntu、Amazon Linux、Red Hat Enterprise Linuxなど、さまざまなAMIを利用できます。
実際に使っていると、SSH周辺の挙動にも違いがあるように感じます。
そこで今後、
- Ubuntu
- Amazon Linux
- Red Hat Enterprise Linux
などのEC2インスタンスを実際に立ち上げ、sshd_configやsshd_config.dの初期状態を比較してみようと思います。
確認できた内容は、この記事に追記していきます。
AITRetry Lab メモ
この記事は、実際に作業中につまずいたことを記録したものです。
AITRetry Labでは、最初から完璧な記事を作るのではなく、実際に試した結果をもとに記事そのものも更新していきます。
今回のSSH設定についても、別のAMIで検証した結果が分かり次第、追記する予定です。
コメント