6

There are tutorials on the web, such as this one: https://blog.oddbit.com/post/2019-02-24-docker-build-learns-about-secr/

They show you sample code to run ssh-keyscan in an automated manner so that subsequent automation steps that depend on SSH can complete successfully. E.g. excerpt from that tutorial:

# 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 git@github.com:moby/buildkit

Is that a good idea? Is there any way for ssh-keyscan to automatically verify the legitimacy of the host it scans? If not, doesn't it become security theatre and defeats the point of SSH's known_hosts verification?

Kal
  • 247
  • 1
  • 6
  • 1
    This is an example of "trust on first use" Opinions on TOFU vary - it allows easy setup while protecting future uses - but does have the weakness you mention. For this reason I prefer SSH CA – paj28 Nov 21 '19 at 08:16

2 Answers2

5

Is there any way for ssh-keyscan to automatically verify the legitimacy of the host it scans?

No. How could it? You are using it to build the known_hosts file that would be used for verification.

If not, doesn't it become security theatre and defeats the point of SSH's known_hosts verification?

In the example you've shown, it indeed does.

Although the problem isn't that ssh-keyscan is being used, but rather when and how it is used. Overall, it isn't any different from getting the regular "Verify unknown host" SSH prompt and blindly typing yes without looking at the fingerprint.

If you do it once and keep the resulting known_hosts file around, then you still get the same Trust-on-first-use behavior that we all expect from SSH. But if you throw away and regenerate known_hosts every time, with no verification against previous runs, then it's going to be a problem whether you use ssh-keyscan or not.

In short, deploying a static known_hosts file would be much more secure – GitHub's SSH hostkeys certainly don't change often, so there is really no need to re-keyscan them every time.

chicks
  • 145
  • 1
  • 6
user1686
  • 1,041
  • 8
  • 17
0

The accepted answer is technically correct, but there is another way if you know the public fingerprint of the host key. Github publishes their fingerprint:

SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8

Therefore, you can compare the ssh-keyscan output and verify the host key is valid before adding to the known_hosts file.

$ ssh-keyscan -t rsa github.com | ssh-keygen -lf - | cut -d' ' -f2
SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8

That said, like in the answer above, do it once and deploy the static file.

EChu
  • 1