2

I've been trying to automatically add UFW rules to allow SSH access during an installation of 16.04 while using a preseed file. However, none of the documented methods result in port 22 being open after the first boot.

Specifically, I've tried variations of the following lines:

ufw     ufw/enable      boolean true
ufw     ufw/allow_custom_ports  string 22/tcp
ufw     ufw/allow_known_ports  string 22/tcp
ufw     ufw/allow_known_ports   string  SSH

But none of them seemed to make a difference. Additionally, my attempts to add the rule in the post-install section failed as the iptables kernel module is not loaded, resulting in an error.

Is this possible to accomplish within the preseed file? Or should I just give up and enable the firewall on boot with a hack?

1
  • I don't see why this would be needed. Default install of Ubuntu has IPTables set to ACCEPT all inbound packets by default already. Is there some other element to your setup that we should know? Does your preseed include installing an SSH server to listen on the port?
    – user535733
    Feb 6 '17 at 17:43
4

I have been trying to get this working for a while, too. Nothing seems to work. Until I finally gave up and I fixed it with a simple rc.local workaround:

d-i preseed/late_command string \
    mv /target/etc/rc.local /target/etc/rc.local.orig; \
    echo '#!/bin/sh -e' > /target/etc/rc.local; \
    echo '/usr/sbin/ufw allow ssh' >> /target/etc/rc.local; \
    echo 'mv -f /etc/rc.local.orig /etc/rc.local' >> /target/etc/rc.local; \
    echo 'test -x /etc/rc.local && /etc/rc.local' >> /target/etc/rc.local; \
    echo 'exit 0' >> /target/etc/rc.local; \
    chmod +x /target/etc/rc.local

The workaround will add a custom rc.local script using preseed/late_command which will:

  1. Make a backup of the original rc.local as rc.local.orig (using mv)

  2. Then new rc.local is created -- which is a script that will be executed on the first boot up of the system

  3. The new script will:

    1. Enable SSH access using ufw
    2. Restore the original rc.local (by moving rc.local.orig to rc.local, deleting itself)
    3. Test if the original rc.local is executable and run it
    4. Exit successfully
6
  • Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. Feb 4 '17 at 22:26
  • I forgot to comment. I edited the answer here and removed the link, since it doesn't give much more info. Although if somebody wants is as a reference, original gist is here: gist.github.com/jheusala/a8862fb9be5bfde6a367eb97fde73c34
    – thejhh
    Feb 7 '17 at 20:28
  • I dont get this answer, first you rename the rc.local to rc.local.orig then, what you did next is create rc.local file... shouldn't u rename this at the end ?
    – MaXi32
    Aug 28 at 9:41
  • I edited the answer to include much more detailed explanation about the workaround and what the script does. I hope this helps to understand it @MaXi32
    – thejhh
    Aug 29 at 10:56
  • @thejhh I wonder why we could not execute those command using in-target command.
    – MaXi32
    Aug 30 at 16:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.