I would recommend simply shutting down the firewall service using Console and see if that allows you to log back in via SSH. You can do that by running:
If you’re able to login with
ufw disabled, then your IP was most likely blocked. Normally, I recommend using actual ports over defined services when setting up
ufw. Using actual ports seems to be far less problematic.
So if you’re able to login with
ufw disabled, I’d now run a reset to wipe all existing rules.
You now have a clean slate from which to work from. So let’s rebuild.
We’ll start with default rules. We’ll deny all incoming and allow outgoing. These rules won’t matter as right now,
ufw is disabled, so you shouldn’t get locked out when running them if you ran both of the commands above.
ufw default deny incoming
ufw default allow outgoing
Now we need to specify which ports to allow in. I always start with SSH since that’s the first thing I’ll be using and it’s the most important to start with.
Now, from the looks of it, you’re using another port – from what I’ve read, that’s
5069, though let’s confirm that to make sure so that you don’t end up getting locked out again.
grep "Port" /etc/ssh/sshd_config
You’ll see a port echo'ed out to the screen that looks like
Port ... where
... is the port. If that says
22, then we’ll use
22. If it says
5069, then use that.
So let’s allow SSH. As above, change
22 to the other port if that’s what’s showing in your SSH config.
ufw allow 22/tcp
Now since you’re using Apache and LetsEncrypt, we need to allow HTTP and HTTPS connections, and we can do that by allowing ports 80 and 443 through.
ufw allow 80/tcp
ufw allow 443/tcp
At this point, unless you need to allow additional ports through, we can go ahead and start
ufw back up and let it resume.
You’ll get a warning that you may be kicked, but as long as you used the correct SSH port in the above command, you’ll be fine.
Hopefully that helps to get you back in :).