SSH started manually on Kali stops working after reboot — boot-time enablement or network path?

On a production Kali Linux host (2024.x rolling release, deployed from a cloned image), an SSH service that is started manually during a session accepts connections as expected. After the host reboots, the service is no longer reachable, even though the sshd configuration itself was never changed.

Kali documents a policy of disabling most network services at boot by default, so a unit that is merely running is not necessarily enabled. There is also uncertainty about two other differences between the working local test and the production deployment: whether cloned host keys could cause client-side trust failures, and whether a firewall or security-group rule on the production path blocks the port independently of the service state.

Verification planned includes checking systemctl is-enabled ssh, reviewing journalctl -u ssh -b after a reboot, confirming the listening port with ss -tlnp, and comparing local versus production packet filtering.

Which checks most reliably distinguish a boot-enablement problem from a network reachability problem on Kali? Should the service be enabled persistently at boot, or started on demand to limit attack surface? Are there Kali-specific steps needed after deploying from a cloned image before SSH can be trusted in production?