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

Question

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?

Tasadduq Burney · Answer

Answer
The most reliable way to tell whether the problem is boot‑time enablement or a network block is to check if the sshd process actually starts after a reboot.

Run systemctl is-enabled ssh. If it returns disabled, the service is not configured to start at boot – this explains the loss of connectivity after a reboot.
After a reboot, examine journalctl -u ssh -b. Look for lines such as Started OpenBSD Secure Shell server and Listening on 0.0.0.0:22 port 22. Their absence confirms the daemon never started.
If the journal shows the daemon started, verify the listening socket with ss -tlnp | grep :22. Seeing the port listed means sshd is running locally; any remaining connection failure is then due to a firewall, security‑group, or host packet filter.
If the port is not listed, the service is not running (enablement problem). Enable it persistently with systemctl enable --now ssh and regenerate host keys after a clone: rm /etc/ssh/ssh_host_* && dpkg-reconfigure openssh-server.
Finally, test connectivity from another host. If it still fails while ss -tlnp shows the port, run tcpdump -i any port 22 to see whether SYN packets arrive; lack of packets indicates a network‑path block.

Ask: Are there any custom iptables/nftables rules or cloud security‑group entries that could be dropping port 22? Knowing this changes the next step from pure enablement to firewall adjustment.

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

1 answer

Answer

Your perspective belongs here.

0 question comments