To configure the SSH daemon to start only after the network is fully online in Raspbian 12, you must override the default systemd unit file. By creating a drop-in configuration that modifies the
After and
Wants directives, you ensure the service waits for the
network-online.target. This prevents connection failures during boot when the network interface is not yet ready.
Understanding the Boot Sequence Issue
In modern Linux distributions like Raspbian Bookworm, systemd manages service dependencies rigorously. The default
sshd.service often starts before the network stack is completely initialized. This can lead to intermittent SSH connections or services failing to bind to interfaces that are still configuring their IP addresses via DHCP. The goal is to align the SSH daemon's startup with the
network-online.target, which represents a state where the network is considered functional and reachable.
Creating the Systemd Drop-In Override
Rather than editing the original service file directly, which may be overwritten by package updates, you should use a drop-in directory. This method preserves the integrity of the upstream configuration while allowing local customizations.
First, create the drop-in directory for the SSH service using the following command:
sudo mkdir -p /etc/systemd/system/sshd.service.d
Next, create a new configuration file within this directory. You can name it
network-online.conf:
sudo nano /etc/systemd/system/sshd.service.d/network-online.conf
Inside this file, you need to specify the dependencies that enforce the timing constraint. Add the following lines:
[Unit]
After=network-online.target
Wants=network-online.target
The
After directive ensures that
sshd does not start until
network-online.target has been reached. The
Wants directive indicates that
sshd requires the network to be online but does not strictly fail if the target cannot be achieved (though in practice, the network target is almost always available on headless servers).
Applying the Changes
Once the configuration file is saved, you must reload the systemd daemon to recognize the new drop-in configuration. Execute the following command:
sudo systemctl daemon-reload
This command forces systemd to re-read all unit files and apply the changes without requiring a reboot. You can verify that the override has been applied correctly by checking the effective configuration of the service:
systemctl cat sshd.service
Look for the
[Unit] section at the bottom of the output, which should include your custom
After and
Wants lines. If they appear, the configuration is active.
Testing the Configuration
To confirm that the SSH service now respects the network dependency, you can restart the service and check its status:
sudo systemctl restart sshd
systemctl status sshd
If the service starts successfully and shows an active state, the override is working. Additionally, you can monitor the boot process to see the order of operations. Using
journalctl can help you trace the exact moment the network target is reached relative to the SSH service start time.
For users managing multiple services, understanding how these targets interact is crucial. Proper ordering prevents race conditions that can leave critical services in a broken state. If you are dealing with more complex networking scenarios, such as port forwarding over VPNs, you might also want to review
Port Forwarding VM via OpenVPN: A Comprehensive Guide to understand how different network layers interact during startup.
Troubleshooting Common Issues
If the SSH service still fails to start properly, check the following:
- Network Target Availability: Ensure that your system actually reaches
network-online.target. Some minimal installations might skip this target if no network manager is present.
- Service Status: Run
systemctl is-active sshd to verify the current state. If it is inactive, check logs with journalctl -u sshd for specific errors.
- Conflicting Units: Occasionally, other network-related units might interfere. Check for any other drop-ins in the
sshd.service.d directory that might conflict with your changes.
By adhering to these steps, you ensure a robust and reliable SSH setup that aligns with the network infrastructure's readiness.
Frequently Asked Questions
Why doesn't my SSH service start immediately after boot?
It is designed to wait for the network to be fully operational. This delay prevents binding errors when the network interface is still initializing. Once the network is online, the service starts automatically.
Can I use network.target instead of network-online.target?
No,
network.target only indicates that the network management stack has started, not that connectivity is established. Use
network-online.target to ensure actual network availability for SSH connections.
How do I revert these changes if needed?
Remove the drop-in file located at
/etc/systemd/system/sshd.service.d/network-online.conf. Then run
sudo systemctl daemon-reload to restore the default behavior.
Does this affect other services that depend on SSH?
Indirectly, yes. Services that rely on SSH being available earlier in the boot process might experience delays. However, most standard services do not require SSH to be active during the initial boot phase.
What if I am using a static IP address?
Even with a static IP, using
network-online.target is recommended. It ensures that the network interface is fully configured and up before the SSH daemon attempts to listen on it, preventing potential race conditions.