Add considerations for strict host key checking #732

ecarson · 2024-06-14T02:17:09Z

Added considerations for onboarding and conductor migration workflows when strict host key checking is enabled.

ecarson · 2024-06-14T13:14:17Z

This hit what looks like an unrelated transient faillure:

FILE: docs/config_domain-based_web_filter.md
[✓] config_app_ident.md → Status: 200
[✓] ../static/img/dbwf_appl_seen.png → Status: 200
[✖] http://www.google.com/doodles/doodle-champion-island-games-september-05 → Status: 500
[✖] http://www.google.com/doodles/ → Status: 500
[✓] http://www.google.com/ → Status: 200
[✓] http://www.bing.com/ → Status: 200
[✓] #domain-categories → Status: 200

7 links checked.

ERROR: 2 dead links found!
[✖] http://www.google.com/doodles/doodle-champion-island-games-september-05 → Status: 500
[✖] http://www.google.com/doodles/ → Status: 500

https://github.com/128technology/docs/actions/runs/9509604151/job/26212795734

MichaelBaj · 2024-06-14T13:22:31Z

docs/howto_router_migration.md

+### Additional Considerations When Strict Host Key Checking Is Enabled
+
+If the router is configured for strict `inter-router` host key checking (`host-key-checking` is `yes`), there are some additional considerations when performing a migration to the new conductor. It will be necessary to manually provision the new conductor key **prior** to migrating the router. This will require the administrator to retrieve the host key of each node of the new conductor and configure this in the router prior to migration.


Isn't this only relevant for deployments that are running pre-6.3 software?
If so, that should be indicated here.

The strict host key checking will be relevant for all releases running Strict host key checking. We were planning to roll this back to the earlier support releases.

Note that it is optionally enabled in config. We will need to encourage people to enable it though because it is important for blocking a MitM attack from router to conductor.

When it is enabled it requires explicit key sharing to be made by the administrator. We proposed an enhancement where this would be included in the quickstarter bundle and Teron seemed to think this was OK for CC.

MichaelBaj · 2024-06-14T13:23:11Z

docs/intro_otp_iso_install.mdx

+
+### Additional Considerations When Strict Host Key Checking Is Enabled
+
+If the router is configured for strict `inter-router` host key checking (`host-key-checking` is `yes`), there are some additional considerations when onboarding to the conductor. It will be necessary to manually provision the new conductor key **prior** to successful communication to the conductor. This will require the administrator to retrieve the host key of each node of the new conductor and configure this in the router.


Same as above.

…tions

MichaelBaj · 2024-06-24T17:16:50Z

docs/cc_fips_otp_router_install.md

@@ -108,6 +108,53 @@ When you modify the GRUB kernel behavior by editing the GRUB menu at boot time,

 This installation process is an automated workflow which does not require user interaction after selecting and initiating the OTP menu option. The system will power off after installation.

+### Enable Strict Host Key Checking
+
+Enabling strict `host-key-checking` provides secure communication between the conductor and a configured router. 


What does the term "configured router" mean in this sentence. Typically it would simply be a "router" or a "managed router". Is this a distinction with a difference? If so, what? If not, then "a router" is sufficient.

MichaelBaj · 2024-06-24T17:19:10Z

docs/cc_fips_otp_router_install.md

+ config authority router RTR_EAST_COMBO node combo-east-2 ssh-settings inter-router host-key-checking yes
+ ```
+
+- **`inter-node host-key-checking`** controls host key verification between redundant HA nodes. When set to `yes`, strict host key checking is enabled between the router and the conductor **between each node**. However, the host keys must be manually provisioned on each router. 


Shouldn't this sentence read:

"strict host key checking is enabled between each node of a HA router."?
The sentence is confusing.

MichaelBaj · 2024-06-24T17:22:55Z

docs/cc_fips_otp_router_install.md

+
+#### Manual Provisioning of the Conductor Key
+
+If a router is configured for strict `inter-router host-key-checking` (set to `yes`), but **does not** have `accepts-new` configured, it will be necessary to manually provision the new conductor key **prior** to onboarding the router to the conductor. This will require the administrator to retrieve the host key of each node of the new conductor and configure this in the router.


The last sentence states "of the new conductor".
Perhaps this paragraph was originally used for a migration doc. Does "new" conductor matter here? i.e., if this were a migration use case or a use case where a customer is turning on struck-host-key checking for the first time, a new or old conductor shouldn't matter, right?
recommend changing to "This will require the administrator to retrieve the host key of each node of the conductor and configure this in the router."

MichaelBaj · 2024-06-24T17:24:31Z

docs/cc_fips_otp_router_install.md

+
+If a router is configured for strict `inter-router host-key-checking` (set to `yes`), but **does not** have `accepts-new` configured, it will be necessary to manually provision the new conductor key **prior** to onboarding the router to the conductor. This will require the administrator to retrieve the host key of each node of the new conductor and configure this in the router.
+
+On the new conductor, identify the `key` for each node using the command `show system connectivity host-keys node all`.


Same comment as above regarding the "new" conductor.

MichaelBaj · 2024-06-24T17:26:48Z

docs/howto_router_migration.md


-If the router is configured for strict `inter-router` host key checking (`host-key-checking` is `yes`), there are some additional considerations when performing a migration to the new conductor. It will be necessary to manually provision the new conductor key **prior** to migrating the router. This will require the administrator to retrieve the host key of each node of the new conductor and configure this in the router prior to migration.
+If a router is configured for strict `inter-router host-key-checking` (set to `yes`), but **does not** have `accepts-new` configured, it will be necessary to manually provision the new conductor key **prior** to migrating the router to the conductor. This will require the administrator to retrieve the host key of each node of the new conductor and configure this in the router.


Here it is clear that this is coming from the migration doc, hence the use of the term "new conductor"

…st-key-checking-considerations' of github.com:128technology/docs into ecarson/strict-host-key-checking-considerations

Add considerations for strict host key checking

66bd462

ecarson requested review from MichaelBaj and Chr1st0ph3rTurn3r as code owners June 14, 2024 02:17

MichaelBaj reviewed Jun 14, 2024

View reviewed changes

MichaelBaj self-requested a review June 14, 2024 13:42

Filter unreachable example links

a095e47

MichaelBaj previously approved these changes Jun 14, 2024

View reviewed changes

Chr1st0ph3rTurn3r added 3 commits June 21, 2024 10:24

adding info to CC docs

93011f2

adding clearer config steps for strict host key checking

c4bd318

final polish on strict host key checking.

252a464

Chr1st0ph3rTurn3r dismissed MichaelBaj’s stale review via 252a464 June 21, 2024 21:03

Chr1st0ph3rTurn3r requested a review from MichaelBaj June 21, 2024 21:19

Merge branch 'master' into ecarson/strict-host-key-checking-considera…

090f10b

…tions

MichaelBaj requested changes Jun 24, 2024

View reviewed changes

Chr1st0ph3rTurn3r added 2 commits June 24, 2024 14:45

Added Mike's review input

5a62ed4

merging content updated from master. Merge branch 'ecarson/strict-ho…

7e59d6b

…st-key-checking-considerations' of github.com:128technology/docs into ecarson/strict-host-key-checking-considerations

Chr1st0ph3rTurn3r requested a review from MichaelBaj June 24, 2024 18:48

MichaelBaj approved these changes Jun 24, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add considerations for strict host key checking #732

Add considerations for strict host key checking #732

ecarson commented Jun 14, 2024

ecarson commented Jun 14, 2024

MichaelBaj Jun 14, 2024

ecarson Jun 14, 2024

MichaelBaj Jun 14, 2024

MichaelBaj Jun 24, 2024

MichaelBaj Jun 24, 2024

MichaelBaj Jun 24, 2024

MichaelBaj Jun 24, 2024

MichaelBaj Jun 24, 2024

		### Additional Considerations When Strict Host Key Checking Is Enabled

		If the router is configured for strict `inter-router` host key checking (`host-key-checking` is `yes`), there are some additional considerations when performing a migration to the new conductor. It will be necessary to manually provision the new conductor key prior to migrating the router. This will require the administrator to retrieve the host key of each node of the new conductor and configure this in the router prior to migration.


		#### Manual Provisioning of the Conductor Key

		If a router is configured for strict `inter-router host-key-checking` (set to `yes`), but does not have `accepts-new` configured, it will be necessary to manually provision the new conductor key prior to onboarding the router to the conductor. This will require the administrator to retrieve the host key of each node of the new conductor and configure this in the router.


		If a router is configured for strict `inter-router host-key-checking` (set to `yes`), but does not have `accepts-new` configured, it will be necessary to manually provision the new conductor key prior to onboarding the router to the conductor. This will require the administrator to retrieve the host key of each node of the new conductor and configure this in the router.

		On the new conductor, identify the `key` for each node using the command `show system connectivity host-keys node all`.

Add considerations for strict host key checking #732

Are you sure you want to change the base?

Add considerations for strict host key checking #732

Conversation

ecarson commented Jun 14, 2024

ecarson commented Jun 14, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment