Update docs for Nebula v1.9.0

docs/config/firewall.mdx

@@ -65,8 +65,20 @@ The possible fields of a firewall rule are:
   unsafe_routes, the rule allows. If unset, the rule will allow access to the specified ports on both the node itself as
   well as any IP addresses it routes to.
 
-Logical evaluation is roughly: port AND proto AND (ca_sha OR ca_name) AND (host OR group OR groups OR cidr OR
-local_cidr).
+:::note
+
+Logical evaluation of these rules changed in Nebula v1.9.0. Previously, a match on `local_cidr` meant that a rule did
+not need to also pass `host`, `group`, `groups`, or `cidr` checks. This is almost never what uers want - `local_cidr`
+generally refers to a specific segment of an [unsafe_routes](/docs/config/tun/#tununsafe_routes) configuration that is
+being accessed, while the latter options relate to the connecting host's identity.
+
+:::
+
+Since Nebula v1.9.0, rules are evaluated as:
+`port AND proto AND (ca_sha OR ca_name) AND (host OR group OR groups OR cidr) AND local_cidr`.
+
+Prior to Nebula v1.9.0, rules were evaluated as:
+`port AND proto AND (ca_sha OR ca_name) AND (host OR group OR groups OR cidr OR local_cidr)`.
 
 ```yml
 # Nebula security group configuration
@@ -75,6 +87,8 @@ firewall:
   outbound_action: drop
   inbound_action: drop
 
+  default_local_cidr_any: false # false will become the default in Nebula v1.10.0+
+
   conntrack:
     tcp_timeout: 12m
     udp_timeout: 3m
@@ -118,6 +132,21 @@ outbound:
 At a minimum, it is recommended to enable ICMP so that `ping` can be used to verify connectivity. Additionally, if
 enabling the built-in Nebula SSH server, you may wish to grant access over the Nebula network via firewall rules.
 
+## firewall.default_local_cidr_any
+
+<Pill className="mb-24">Default: True</Pill>
+
+This setting was introduced in Nebula v1.9.0 for backwards compatibility purposes. The default will be changed to
+`false` in Nebula v1.10.0 and the config option will be deprecated.
+
+When set to `true`, any firewall rules which do not explicitly set `local_cidr` will be interpreted as if they were set
+to `any`. In other words, firewall rules which do not explicitly configure `local_cidr` will apply both to ports on the
+local machine as well as ports on any hosts accessible via [unsafe_routes](/docs/config/tun/#tununsafe_routes).
+
+When set to `false`, firewall rules which do not explicitly set `local_cidr` will only apply to the local host. To
+permit access to machines accessible via unsafe_routes, define a firewall rule which explicitly references those routes
+in the `local_cidr` field.
+
 ## firewall.conntrack
 
 Settings for the Connection Tracker.

docs/config/sshd.mdx

@@ -22,8 +22,12 @@ sshd:
     - user: steeeeve
       keys:
         - '[ssh public key string]'
+  trusted_cas:
+    - '[ssh ca public key string]'
 ```
 
+See also the [Debugging with Nebula SSH commands](/docs/guides/debug-ssh-commands/) guide.
+
 ## sshd.enabled
 
 <Pill className="mb-24">Default: False</Pill>
@@ -37,7 +41,28 @@ allowed for your safety.
 
 ## sshd.host_key
 
-`host_key` points to a file containing the ssh host private key to use for the ssh server side of the console.
+`host_key` points to a file containing the ssh host private key to use for the ssh server side of the console. In the
+above example, `/path/to/ssh_host_ed25519_key` contains a PEM-encoded SSH host key. The following example shows a host
+key inlined as a YAML multiline string.
+
+```
+sshd:
+  host_key: |
+    -----BEGIN OPENSSH PRIVATE KEY-----
+    b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
+    QyNTUxOQAAACCAvcPQI9IPXWXmsCFBi+IGoqxjKcCZjivS2ev7wVLWjAAAAKCzhBSYs4QU
+    mAAAAAtzc2gtZWQyNTUxOQAAACCAvcPQI9IPXWXmsCFBi+IGoqxjKcCZjivS2ev7wVLWjA
+    AAAECkLDZ1uXRNpvWTG+tff7MSoy6WCDkNhlwB+I5BpI0zfYC9w9Aj0g9dZeawIUGL4gai
+    rGMpwJmOK9LZ6/vBUtaMAAAAGmptYWd1aXJlQGpvaG5zLW1icC0zLmxvY2FsAQID
+    -----END OPENSSH PRIVATE KEY-----
+```
+
+:::warning
+
+Do not use the above private key in your own config file. SSH host keys should be unique per host, and provide
+authenticity that you are connecting to the correct server.
+
+:::
 
 You can generate a host key using the `ssh-keygen` command line utility.
 
@@ -47,3 +72,11 @@ You can generate a host key using the `ssh-keygen` command line utility.
 
 These options are how you create `users` for the debug ssh daemon. Password authentication for the ssh debug console is
 NOT supported.
+
+# sshd.trusted_cas
+
+As an alternative to (or in addition to) `authorized_users`, you may define a list of trusted SSH CA public keys. Any
+SSH certificate signed by a trusted CA will be granted access to the SSH debug server.
+
+If an SSH certificate contains at least one principal, the connecting username must match a principal in the
+certificate. If no principals are specified in the certificate, any username can be used.

docs/config/tun.mdx

@@ -96,6 +96,8 @@ tun:
       install: true # controls whether this route is installed in the systems routing table.
 ```
 
+For more information, see the [Extend network access beyond overlay hosts](/docs/guides/unsafe_routes/) guide.
+
 ## tun.use_system_route_table
 
 <Pill className="mb-24">Default: False</Pill>

docs/guides/debug-ssh-commands/index.mdx

@@ -55,6 +55,7 @@ Available commands:
 change-remote - Changes the remote address used in the tunnel for the provided vpn ip
 close-tunnel - Closes a tunnel for the provided vpn ip
 create-tunnel - Creates a tunnel for the provided vpn ip and address
+device-info - Prints information about the network device.
 help - prints available commands or help <command> for specific usage info
 list-hostmap - List all known previously connected hosts
 list-lighthouse-addrmap - List all lighthouse map entries