次のようなWeb上のチュートリアルがあります: https://blog.oddbit.com/post/2019-02-24-docker-build-learns-about-secr/
これらは、SSHに依存する後続の自動化ステップが正常に完了できるように、自動化された方法でssh-keyscan
を実行するためのサンプルコードを示しています。例えば。そのチュートリアルからの抜粋:
# syntax=docker/dockerfile:1.0.0-experimental
FROM Alpine
RUN apk add --update git openssh
# This is necessary to prevent the "git clone" operation from failing
# with an "unknown Host key" error.
RUN mkdir -m 700 /root/.ssh; \
touch -m 600 /root/.ssh/known_hosts; \
ssh-keyscan github.com > /root/.ssh/known_hosts
# This command will have access to the forwarded agent (if one is
# available)
RUN --mount=type=ssh git clone [email protected]:moby/buildkit
それは良い考えですか? ssh-keyscanがスキャンするホストの正当性を自動的に検証する方法はありますか?そうでなければ、それはセキュリティシアターになり、SSHのknown_hosts
検証のポイントを無効にしませんか?
Ssh-keyscanがスキャンするホストの正当性を自動的に検証する方法はありますか?
いいえ。どうすればよいでしょうか。検証に使用されるbuildknown_hosts
ファイルに使用しています。
そうでない場合、それはセキュリティシアターになり、SSHのknown_hosts検証のポイントを無効にしませんか?
あなたが示した例では、確かにそうです。
問題はssh-keyscan
が使用されていることではなく、いつどのように使用されているかです。全体的に、それは通常の「Verify unknown Host」SSHプロンプトを取得し、指紋を見ずにyes
を盲目的に入力することと何の違いもありません。
一度それを行って、結果のknown_hosts
ファイルをそのままにしておけば、SSHで期待されているのと同じように、最初の使用時と同じ動作が得られます。ただし、以前の実行に対する検証を行わずに毎回known_hosts
を破棄して再生成すると、ssh-keyscan
を使用するかどうかに関係なく問題が発生します。
つまり、静的known_hosts
ファイルをデプロイする方がはるかに安全です。GitHubのSSHホストキーは頻繁に変更されないので、毎回キースキャンする必要はありません。