fix: add ufw SSH allow rule when sshd is enabled - #4665
Conversation
When UFW firewall is selected alongside sshd during installation, UFW would block SSH connections on first boot, locking users out of their system. Check if sshd.service is enabled in the target system by checking the systemd symlink, and if so, run 'ufw allow SSH' inside the chroot to ensure SSH access is not blocked. Fixes archlinux#4616
|
Services are enabled after the application installations so your check won't really do much https://github.com/archlinux/archinstall/blob/master/archinstall/scripts/guided.py#L169. |
Yes I have ,thanks for the comment |
|
Thanks for the fix, but I am not sure if defaulting to enabling SSH is the best practice in terms of giving users the most control over their machines. I also have some doubts about using I have implemented a different fix that allows the users to select whether they want to enable SSH on boot, as someone suggested in the original issue, and uses a systemd service to enable the SSH. Happy to make changes if you have any feedback. |
When UFW firewall is selected alongside sshd during installation, UFW would block SSH connections on first boot, locking users out of their system.
Check if sshd.service is enabled in the target system by checking the systemd symlink, and if so, run 'ufw allow SSH' inside the chroot to ensure SSH access is not blocked.
Fixes #4616
PR Description:
When a user selects both UFW firewall and sshd during archinstall, UFW is enabled but no SSH allow rule is added. This means on first boot, all SSH connections are blocked by UFW, completely locking the user out of a remote system with no recovery path short of physical access.
Fix:
After enabling and configuring UFW, check if sshd.service is enabled in the target system by looking for its systemd symlink at etc/systemd/system/multi-user.target.wants/sshd.service. If found, run ufw allow SSH inside the chroot before installation completes.
This ensures SSH access is preserved when both sshd and UFW are selected together, which is the expected behavior for any server installation.
Why this approach:
The installer has no central registry of enabled services, so checking the systemd symlink is the most reliable way to detect whether sshd was enabled during the current install session without requiring refactoring of the service tracking logic.