目次
- 目次
- はじめに
- AL2023がインストールされたサーバにSSHログインできない
- crondがデフォルトで入っていない
- journaldがデフォルトでrsyslogが入っていない
- その他気になったこと
- 終わりに
はじめに
CentOS 7はCentOS Projectから2024年6月でEOLとのアナウンスが出ており、CentOS 7からAmazon Linux 2023 (以降AL2023) に移行する機会がありました。
その中で、知っておきたいポイントがいくつかあったので、そちらについて記載します。
AL2023がインストールされたサーバにSSHログインできない
AL2023にWindows端末からSSHログインをしようとしていたユーザの方達からログインできないと、問い合わせを受けました。
状況
- AL2023に一般ユーザで公開鍵認証にてログインを実施します。
- SSHの設定は公開鍵認証のみ許可していた状態です。
- ユーザはSSHクライアントのTeratermを利用しています。
なぜログインできなかったか
今回の結論から記載すると、
- AL2023はCentOS 7では使用できたssh-rsa署名がデフォルトで無効になっている。
- Windows端末のTeratermが古いバージョンであった。
この2点になります。細かい部分を解説します。
AL2023では、セキュリティ強化のため、ssh-rsa署名がデフォルトで無効化されています。
このドキュメントのポイントとして、
If you have SSH clients from several years ago, you might see an error when you connect to an instance. If the error tells you there's no matching host key type found, update your SSH host key to troubleshoot this issue.
この点があります。ざっくり和訳すると、古いクライアント使っていると、接続できなくなる場合があるということです。
同様の説明は次のドキュメントにも記載があります。Amazon Linux 2からAL2023の変更点のドキュメントです。
AL2023は、rsa-sha2-256とrsa-sha2-512が使えるクライアントなら接続可能ですと記載があります。
Teratermは古いバージョンだとrsa-sha2-256とrsa-sha2-512に対応していないため、SSHログインをしようとしていたユーザの方達に、Teratermの最新版への更新をお願いしました。結果、接続することが可能になりました。
公式にクライアント側を更新できない場合の解決案も提示されていますので、そちらも記載します。
crondがデフォルトで入っていない
AL2023はデフォルトでcrondが入っていません。
systemdでもTimer設定を追加することで定期実行の設定はできますが、今回の移行元では、crondで特定のツールを定期実行していました。そのため今回はsystemdへの移行はせず、crondを追加で入れることを選択しました。
journaldがデフォルトでrsyslogが入っていない
AL2023は、デフォルトでsyslogやrsyslogが入っていません。
入っていないなら、これを機にjournaldにログ管理を移行するのも良いですが、構築後の保守を考えると、慣れていないjournaldとなると心配です。
たとえばですが、journaldでは以下のログが出力されません。
- /var/log/messages
- /var/log/maillog
- /var/log/cron
- /var/log/boot.log
- /var/log/secure
問題が起きた際ログの調査も、該当のログがjournaldだとどこにあるかから調べるため時間がかかってしまいます。 構築後の保守を考えると、今まで確認可能だったログが出力されていると移行もスムーズに済みます。 そういった考慮から、今回はrsyslogを追加で入れることを選択しました。
その他気になったこと
ここからは、個人的に気になったことを記載します。
時刻同期が最初からされている
あまりAmazonLinuxになじみがなかったので、今までの私の経験だと、構築するサーバの時刻同期の設定（古いものだとNTP新しいものだとchrony）の設定をしていました。
AL2023では、amazon-chrony-configというパッケージがデフォルトでインストールされおり、そのパッケージによって同期先がAmazon Time Sync Serviceに最初から設定されていました。これは地味に便利だと思いました。
メタデータのバージョンがデフォルトV2になっている
AWS EC2ではインスタンスメタデータサービスに対してcurlコマンドを実行することで、AWS EC2のさまざまな情報を取得する事ができます。
このインスタンスの情報はメタデータと呼ばれて以下にカテゴライズされています。
こちらの公式ページにも記載されておりますが、
AL2023では、このメタデータのバージョンがデフォルトV2になっています。
今回の移行元である移行元であるAWS EC2は、メタデータのバージョンはV1でした。
上記の公式サイトと自分自身で検証していたところ、V2ではV1にはなかった変更点があり、メトリクスの取得エラーになってしまう可能性が見えてきました。
メタデータV2ではV1になかった以下の考慮点が必要になります。
- Tokenの設定
- ホップ数制限
この2点は、セキュリティ強化策として用意されたものです。
今回は、移行元で実装されていたツールの関係もあり、メタデータV2のみへの移行はせずV1およびV2を採用していますが、機会があればメタデータV2のみを実装してみたいと思いました。
以下は、メタデータV2のみを使うにあたって私が調べたことになりますので、ご参考までに。
Tokenの設定
Tokenの設定は、AWS EC2の情報をAWS基盤と通信するにあたって、この通信はメタデータV2が発行した通信であることをAWS基盤に知らせる役割をもったものです。
このTokenが発行した情報を元に通信の安全性をメタデータV1より高める目的で実装されています。
ホップ数制限について
ホップ数とは、ネットワーク用語で通信元から通信先までに経由する（L3以上の）中継機器の数です。利用するネットワーク機器やネットワークプロトコルによっては自動で判断してくれる場合があります。
メタデータV2利用の場合は、設定できる値の範囲として2024年4月現在1から64の間の値を設定できます。
尚、コンテナの場合の推奨値は、2になっています。
この値は明示的にホップ数を制限することによって、意図していない通信先（たとえば、悪意を持った攻撃者）への情報の送信を防ぐ目的でホップ数が規定されています。
終わりに
CentOS 7からAmazonLinux2023に移行する時の知っておきたいポイントを記載しました。
変わりゆくOS事情やOSの変化をじかに体験できて、とても勉強になりました。
