サーバーを構築して脆弱性診断を受けた時に指摘されて対応した際の備忘録。
RHEL8のサーバーを構築した時に、sshdがデフォルトの設定だとsha-1とかの古い暗号化形式でも受け入れる設定が有効になっている。
古い暗号化形式を受け付けないようにするためにmozillaの公式情報を元にsshdの設定変更作業を行った。（個人的には外部に公開しているサーバーじゃないのでスルーしてもいいんじゃないかなと思いつつ）
んが、その情報が実はCentOS7用の設定だったため、半日くらいハマった。
mozilla様の記事でも違う時があるんかい！というか人の言うことを無条件に信じてはダメだ、という思いが強かったので次から間違えないようにメモ。
RHEL8,CentOS8のSSHの仕様
CentOS8かつOpenSSHでデフォルトの設定のままSSHを運用すると暗号化をダウングレードされてしまうという脆弱性？仕様？が存在。
厳密には古い暗号化形式でもアクセスできるよう緩い設定が施されているというのが正しいか。
何はともあれ以下mozillaの手順を参考に対応してみた。
脆弱性対応
Redhat8で対応したことだけど、CentOS8系でも同じ現象が起こるはず。
環境
RHEL8.X
OpenSSH8.X(rpmでインストール)
現象
sshクライアントからの接続時に、復号可能な強度の低い暗号化でも接続できてしまう。
強度の低い暗号化を具体的に示すと、diffie-hellman-group-exchange-sha1など*sha1関連を色々
確認方法
以下のコマンドで確認可能。
というよりも「どうやって脆弱性確認したのか教えてくださいな」と脆弱性診断の会社に聞いたら確認方法を教えてくださった。こちらの意図をくみ取ってくださって感謝。
手の内を教えてもらえたけれどええんかいな。
ssh -vv ユーザー名@サーバーのIPアドレスコマンド実行結果の中で「debug2: KEX algorithms:」の行で確認できるとのこと。
debug2: KEX algorithms:**********あかん例
sha1 ～って出るとダメなパターン。
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1対処方法（失敗編）
mozillaの情報を元に判断すると、デフォルトでは利用できるKEX algorithms、Ciphersなどが/etc/ssh/sshd_configに明示されておらず、この場合どの暗号化もウェルカムな状態になってしまう。
各項目に比較的新しい暗号化形式を明示することで指定以外の方法は利用できなくなるとのことなので以下の作業実施。
１．以下設定をsshd_configに追記。
# vi /etc/ssh/sshd_config追記内容：
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com２．sshdを再起動
# service sshd restart結果（失敗編）
設定反映後<ssh -vv ユーザー名@サーバーのIPアドレス>を試す！
んが結果に変化なし。
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1積んだ＼(^o^)／
対処方法（成功編）
色々もがいて最終的には成功。
結論から言うと、RHEL8以降は/etc/ssh/sshd_configに暗号化を明示するだけではなく、/etc/sysconfig/sshdの「# CRYPTO_POLICY=」のコメントアウトを外さなくてはいけない。
発見の経緯１：レッドハットの中の人のブログを発見
一緒に作業していた同僚と、ああでもない、こうでもないと悩んだ挙句、同僚がレッドハットの中の人のブログから解決方法を見つけてくれた。
以下解決手順。
以下設定をsshd_configに追記
結論から言うと、/etc/sysconfig/sshd の最終行の「# CRYPTO_POLICY=」をコメントアウトする作業を追加するだけ。
RHEL8系では暗号化方式全般を CRYPTO_POLICYってやつでコントロールしているからサービスの設定ファイルのSSH関連の設定は反映されないらしい。
ただし、「# CRYPTO_POLICY=」のコメントアウトを外すことでCRYPTO_POLICYのコントロールを外すことができるらしい。
なんというややこしく細かい仕様変更。
どうせならcrypto-policiesでsha-1自体を使えなくしてしまった方がいいのかもしれないですけどね。
CRYPTO_POLICY=詳細手順
以下で細かいやり方を書いていく
sshd_configに暗号化形式を明示
# vi /etc/ssh/sshd_config追記内容：
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com/etc/sysconfig/sshdのCRYPTO_POLICY=のコメントアウトを外す
# vi /etc/sysconfig/sshd
変更前：
# CRYPTO_POLICY=
変更後：
CRYPTO_POLICY=sshdを再起動
これでうまくいくはず。
# service sshd restart結果（成功編）
以下コマンドの実行結果から*sha1が消えたことを確認。
<ssh -vv ユーザー名@サーバーのIPアドレス>
実行結果
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256オワリ。
今日も勝ってしまった
解決したのは会社の先輩でしたが。がががが。
参考情報：
自分と同じことで悩んでいた方のブログも併せて以下に記載。
大変助かりました。
無事解決できてホッとした半面、タッチの差で自力解決できなかったことだけが少し残念。
とはいえ皆様ご協力ありがとうございました。
コメント
とても役に立ち実業務に活かすことができました。有難うございます。
気になった点があります。
#をつけるときは コメントアウト
#を外すときはコメントアウトを外すではなくアンコメント（コメントアウトの対義語でコメントインという人もいるようですが正確にはコメントアウト）というそうです。
細かくて申し訳ございませんm(_ _)m