Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add considerations for strict host key checking #732

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
13 changes: 12 additions & 1 deletion docs/howto_router_migration.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,4 +53,15 @@ When using the GUI, a **Migrate** button is visible for Routers that are possibl
After the migration command is run, you will see a **Connected** state on the conductor showing the migration was successful. The router(s) will transition to running after a few minutes. If a router does not migrate successfully, an error message will be displayed and no action will be taken.

- Verify that the TCP ports 930, 4505 and 4506 on the conductor are enabled. The routers use these ports to communicate with the conductor.
- If there is a firewall in front of the conductor, these same TCP ports must be enabled.
- If there is a firewall in front of the conductor, these same TCP ports must be enabled.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.

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

On the router, each conductor key can be then be pre-provisioned by using the follow command:
`create system connectivity known-hosts node <node> <conductor address> ssh-rsa <key> <comment>`

where, `<node>` is the router node (should be added on each router node in an HA pair), `<conductor address>` is the conductor address (should be added for each conductor address of an HA conductor pair), `<key>` is the `Key` retrieved from the previous step and, optionally a comment `<comment>` to identify what this key is, for example `Production Conductor1`.
25 changes: 18 additions & 7 deletions docs/intro_otp_iso_install.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -24,11 +24,11 @@ Basic configuration parameters are encoded within an encrypted file. For each no

### Disk Cloning

Disk Cloning allows you to create a generic router platform image that can be used to perform multiple installations quickly and efficiently. After the initial ISO installation and power off, the platform is generic and can be cloned to a disk to create a copy of that platform.
Disk Cloning allows you to create a generic router platform image that can be used to perform multiple installations quickly and efficiently. After the initial ISO installation and power off, the platform is generic and can be cloned to a disk to create a copy of that platform.
:::note
When using cloned images, an identical hardware platform must be used. Create a new disk image for each hardware variation.
:::
The cloned platform disk is then used to install the filesystem and SSR software on any number of other identical hardware platforms.
The cloned platform disk is then used to install the filesystem and SSR software on any number of other identical hardware platforms.

The general process for disk cloning is as follows:

Expand Down Expand Up @@ -57,7 +57,7 @@ To install the Router using the OTP workflow, use the arrow keys to select the *
Not all hardware has video support. Booting to the serial console 115200 baud is the default, and is automatically selected after 30 seconds. When using the serial console, the terminal size is 80x25 - anything smaller may result in abnormal navigation behavior.

Selecting the wrong type of console (Serial or VGA) may result in garbled characters being displayed, and if left to continue will result in an incorrect installation. If the wrong console is selected, reboot the target system and select the correct line for the target hardware.
:::
:::

#### SSR System via Serial Console

Expand Down Expand Up @@ -147,14 +147,14 @@ Changing password for user t128
Changing password for t128
(current)UNIX password:
New password:
Retype new password:
Retype new password:
passwd: all authentication tokens updated successfully.
[t128@test-router ~]$ su -
[t128@test-router ~]$ su -
Password:
[root@test-router ~]# passwd
Changing password for user root.
New password:
Retype new password:
Retype new password:
passwd: all authentication tokens updated successfully.
[root@test-router ~]#
```
Expand All @@ -172,7 +172,7 @@ The scriptlets must have executable permissions to be executed properly.
Any stdout/stderr output generated from the scriptlets is logged in `/var/log/128T-bootstrap/<scriptlet-name>-scriptlet.log`.

### Bootstrapping Flow Chart
The diagram below shows the procedure the Bootstrap utility follows during the first bootup of the platform after the ISO installation completes.
The diagram below shows the procedure the Bootstrap utility follows during the first bootup of the platform after the ISO installation completes.

<Flowchart
chartCode={`
Expand Down Expand Up @@ -246,3 +246,14 @@ Or, if you want to test a specific url:
```
$ bootstrap128t rest-test -i <test-identifier> --url <a-fully-qualified-url>
```

### 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.


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

On the router PCLI, each conductor key can be then be provisioned by using the follow command:
`create system connectivity known-hosts node <node> <conductor address> ssh-rsa <key> <comment>`

where, `<node>` is the router node (should be added on each router node in an HA pair), `<conductor address>` is the conductor address (should be added for each conductor address of an HA conductor pair), `<key>` is the `Key` retrieved from the previous step and, optionally a comment `<comment>` to identify what this key is, for example `Conductor1`.
Loading