There will be an intentionally vulnerable server which is hosted in the cloud which he wants his friends to attempt to hack into.

Rather than using the default VPC I thought this would be a good time to learn more about provisioning VPCs, route tables, subnets by using Terraform instead.

Users will use WireGuard to VPN into the public subnet, and from there they will be able to access the target (10.0.0.10).

Below is a diagram of what I ended up creating:

TLDR — THE FINISHED CONFIGURATION FILES

If you just want the final configuration files, here they are:

PROVIDERS.TF:

provider "aws" {
        region = var.aws_region
}

VARIABLES.TF:

variable "aws_region" {
        default = "ap-southeast-2"
        description = "The AWS region were our resources will reside."
}

variable "instance_type" {
        default = "t2.micro"
        description = "The instance type of the EC2 instance."
}

variable "ami_id" {
        default = "ami-0ba8d27d35e9915fb"
        description = "The AMI ID of the EC2 insance."
}

variable "az" {
        default = "ap-southeast-2a"
}

variable "my_public_key" {
        description = "The public key which will be imported into aws_instance.ctf_EC2_vpn"
}

variable "your_public_ip_address" {
        description = "Your actual public IP address. Eg) 1.2.3.4/32 "
}

variable "friends_public_key" {
        description = "Enter your friend's public key here: "

• When you run terraform apply it will prompt you for your public key as well as your public IP address. This will be used to restrict SSH access to only your IP address.

VERSIONS.TF:

terraform {
        required_version = ">= 0.12"

        required_providers {
                aws = {
                        source = "hashicorp/aws"
                        version = "~> 5.0"
                }
        }
}

MAIN.TF:

## Create the VPC ##

resource "aws_vpc" "ctf_vpc" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = {
    Name = "ctf_vpc"
  }
}

## Create the private subnet ##

resource "aws_subnet" "ctf_private_subnet" {
  vpc_id            = aws_vpc.ctf_vpc.id
  cidr_block        = "10.0.0.0/24"
  availability_zone = var.az
  tags = {
    Name = "ctf_private_subnet"
  }
}

## Now to create the security group for the PRIVATE subnet ##

resource "aws_security_group" "ctf_sg_private_subnet" {
  name        = "sg_private_subnet"
  description = "Allow access from the public subnet only."
  vpc_id      = aws_vpc.ctf_vpc.id
  tags = {
    Name = "ctf_sg_private_subnet"
  }
}

## Now to allow SSH from the private subnet ##

resource "aws_vpc_security_group_ingress_rule" "Allow_access_from_public_subnet" {
  security_group_id = aws_security_group.ctf_sg_private_subnet.id
  cidr_ipv4         = "10.0.1.0/24" ## The source IPv4 range ##
  from_port         = 22
  to_port           = 22
  ip_protocol       = "tcp"
}

## Allow ICMP traffic to the PRIVATE subnet ##

resource "aws_vpc_security_group_ingress_rule" "Allow_ICMP" {
  security_group_id = aws_security_group.ctf_sg_private_subnet.id
  cidr_ipv4         = "10.0.1.0/24" ## The source IPv4 range ##
  from_port         = -1
  to_port           = -1
  ip_protocol       = "icmp"
}

## Allow all egress out of the private subnet ##

resource "aws_vpc_security_group_egress_rule" "Allow_all_outbound_from_private_subnet" {
  security_group_id = aws_security_group.ctf_sg_private_subnet.id
  cidr_ipv4         = "0.0.0.0/0" ## The destination IPv4 range ##
  ip_protocol       = -1
}

## Create the PUBLIC subnet ##

resource "aws_subnet" "ctf_public_subnet" {
  vpc_id                  = aws_vpc.ctf_vpc.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = var.az
  map_public_ip_on_launch = true ## Assigns a public IP address on instance launch
  tags = {
    Name = "ctf_public_subnet"
  }
}

## Now to create the security group for the PUBLIC subnet ##

resource "aws_security_group" "ctf_sg_public_subnet" {
  name        = "sg_public_subnet"
  description = "Allow VPN access from everywhere."
  vpc_id      = aws_vpc.ctf_vpc.id
  tags = {
    Name = "ctf_sg_public_subnet"
  }
}

## Add rule to allow connections from 0.0.0.0/0 into UDP 51832 ##

resource "aws_vpc_security_group_ingress_rule" "Allow_VPN" {
  security_group_id = aws_security_group.ctf_sg_public_subnet.id
  cidr_ipv4         = "0.0.0.0/0"
  from_port         = 51832
  to_port           = 51832
  ip_protocol       = "udp"
}

## Add rule to allow connections from 0.0.0.0/0 into TCP 22 ##
## Alternatively you can change cidr_ipv4 to be your public IP address ##

resource "aws_vpc_security_group_ingress_rule" "Allow_SSH" {
  security_group_id = aws_security_group.ctf_sg_public_subnet.id
  cidr_ipv4         = var.your_public_ip_address
  from_port         = 22
  to_port           = 22
  ip_protocol       = "tcp"
}

resource "aws_vpc_security_group_egress_rule" "Allow_all_outbound" {
  ip_protocol       = "-1" ## All protocols ##
  security_group_id = aws_security_group.ctf_sg_public_subnet.id
  cidr_ipv4         = "0.0.0.0/0"
  description       = "Allow all outbound traffic"
}

## Now to create the route table for the PRIVATE subnet ##

resource "aws_route_table" "ctf_rtb_private_subnet" {
  vpc_id = aws_vpc.ctf_vpc.id
  route {
    #   cidr_block = "10.0.0.0/16"
    #   gateway_id = "local" ##  this as a local route is already created by default
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.ctf_nat_gw.id
  }
  tags = {
    Name = "ctf_rtb_private_subnet"
  }
}

## Now we have to associate the routing table wuth the private subnet ##

resource "aws_route_table_association" "ctf_rtb_association_private_subnet" {
  route_table_id = aws_route_table.ctf_rtb_private_subnet.id
  subnet_id      = aws_subnet.ctf_private_subnet.id
}

## Create an Internet Gateway ##

resource "aws_internet_gateway" "ctf_igw" {
  vpc_id = aws_vpc.ctf_vpc.id
  tags = {
    Name = "ctf_igw"
  }
}

## Now to create the route table for the PUBLIC subnet ##

resource "aws_route_table" "ctf_rtb_public_subnet" {
  vpc_id = aws_vpc.ctf_vpc.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.ctf_igw.id

  }
  tags = {
    Name = "ctf_rtb_public_subnet"
  }
}

## Now we have to associate the routing table with the public subnet ##

resource "aws_route_table_association" "ctf_rtb_association_public_subnet" {
  route_table_id = aws_route_table.ctf_rtb_public_subnet.id
  subnet_id      = aws_subnet.ctf_public_subnet.id
}

## Now to create the NACL for the private subnet ##

## Commented this out as this is too restrictive for what the CTF needs ##

resource "aws_network_acl" "ctf_nacl_private_subnet" {
  vpc_id     = aws_vpc.ctf_vpc.id
  subnet_ids = [aws_subnet.ctf_private_subnet.id] # subnet_ids expects a list, therefore must be in square brackets
  #    egress {
  #        protocol   = "-1"
  #        rule_no    = 100
  #        action     = "allow"
  #        cidr_block = "10.0.1.0/24"
  #       from_port  = 0
  #        to_port    = 0
  #   }
  #   ingress {
  #       protocol   = "tcp"
  #       rule_no    = 100
  #       action     = "allow"
  #       cidr_block = "10.0.1.0/24"
  #       from_port  = 22
  #       to_port    = 22
  #   }
  #   ingress {  ## Allow ICMP Echo Reply ##
  #       protocol = "icmp"
  #       rule_no = 101
  #       action = "allow"
  #       cidr_block = "10.0.1.0/24"
  #       from_port = 0
  #       to_port = 0
  #   }
  #   ingress {  ## Allow ICMP Echo Response ##
  #       protocol = "icmp"
  #       rule_no = 102
  #       action = "allow"
  #       cidr_block = "10.0.1.0/24"
  #       from_port = 0
  #       to_port = 0
  #       icmp_type = 8
  #   }

  ingress {
    protocol   = -1
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }
  egress {
    protocol   = -1
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }
  tags = {
    Name = "ctf_nacl_private_subnet"
  }
}

## Create the NACL for the public subnet ##

resource "aws_network_acl" "ctf_nacl_public_subnet" {
  vpc_id     = aws_vpc.ctf_vpc.id
  subnet_ids = [aws_subnet.ctf_public_subnet.id]


  ingress {
    protocol   = "udp"
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 51832
    to_port    = 51832
  }
  ingress {
    protocol   = "tcp"
    rule_no    = 101
    action     = "allow"
    cidr_block = var.your_public_ip_address
    from_port  = 22
    to_port    = 22
  }
  ingress {
    protocol   = "tcp"
    rule_no    = 102
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 1024
    to_port    = 65535
  }
  ingress {
    protocol   = "udp"
    rule_no    = 103
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 1024
    to_port    = 65535
  }
  ingress {
    protocol   = "icmp"
    rule_no    = 104
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }
  ingress {
    protocol   = -1
    rule_no    = 105
    action     = "allow"
    cidr_block = "10.0.0.0/16"
    from_port  = 0
    to_port    = 0
  }
  egress {
    protocol   = "-1"
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }
  tags = {
    Name = "ctf_nacl_public_subnet"
  }
}

## Now to create the EC2 Instance within the PRIVATE subnet ##

resource "aws_instance" "ctf_EC2_vuln" {
  ami                    = var.ami_id
  availability_zone      = var.az
  instance_type          = var.instance_type
  subnet_id              = aws_subnet.ctf_private_subnet.id
  vpc_security_group_ids = [aws_security_group.ctf_sg_private_subnet.id]
  private_ip             = "10.0.0.10"
  key_name               = aws_key_pair.lumenyx_public_key.id
  tags = {
    Name = "ctf_EC2_vuln"
  }
  root_block_device {
    volume_size = 50
    volume_type = "gp3"
  }
  user_data = <<-EOF
    #!/bin/bash
    sudo apt update
    sudo apt upgrade -y
    sudo apt install docker.io -y
    echo "${var.friends_public_key}" >> /home/ubuntu/.ssh/authorized_keys
    sudo hostnamectl set-hostname vulnerable_instance
    sed -i 's/preserve_hostname: false/preserve_hostname: true/' /etc/cloud/cloud.cfg
  EOF

  depends_on = [aws_nat_gateway.ctf_nat_gw] ## The script was running before the NAT gateway was provisioned. Therefore we need this ##
}

## Adding the key pair ##

resource "aws_key_pair" "lumenyx_public_key" {
  key_name   = "lumenyx_public_key"
  public_key = var.my_public_key
  tags = {
    Name = "lumenyx_public_key"
  }
}

## Now to create the EC2 Instance within the PUBLIC subnet ##

resource "aws_instance" "ctf_EC2_vpn" {
  ami                    = var.ami_id
  availability_zone      = var.az
  instance_type          = var.instance_type
  subnet_id              = aws_subnet.ctf_public_subnet.id
  vpc_security_group_ids = [aws_security_group.ctf_sg_public_subnet.id]
  key_name               = aws_key_pair.lumenyx_public_key.id
  tags = {
    Name = "ctf_EC2_vpn"
  }

  user_data = <<-EOF
  #!/bin/bash
  sudo apt update
  sudo apt upgrade -y
  sudo hostnamectl set-hostname vpn-server
  sed -i 's/preserve_hostname: false/preserve_hostname: true/' /etc/cloud/cloud.cfg
  EOF
}

## Adding the NAT Gateway ##

resource "aws_nat_gateway" "ctf_nat_gw" {
  allocation_id = aws_eip.ctf_nat_gw_eip.id
  subnet_id     = aws_subnet.ctf_public_subnet.id
}

## Allocating an Elastic IP address for the NAT gw ##

resource "aws_eip" "ctf_nat_gw_eip" {
  tags = {
    Name = "ctf_nat_gw_eip"
  }
  depends_on = [aws_internet_gateway.ctf_igw]
}

OUTPUTS.TF:

output "vpc_id" {
        description = "The ID of the VPC."
        value = aws_vpc.ctf_vpc.id
}

output "instance_public_ip" {
       description = "The public IP of the EC2 instance."
       value = aws_instance.ctf_EC2_vpn.public_ip
}

AWS MANAGEMENT CONSOLE — OPTIONAL

I’m going to briefly go over the basics in the AWS Management Console first before I translate it to Terraform.

You can skip this section by going to TERRAFORM CONFIGURATIONS below. However if you’re here to learn how to build things in Terraform (which is text-based), it might help to do it visually in the GUI first.

Now we’ll create the basic infrastructure.

Let it be known that there is a better and faster way of creating a VPC than the way I’m going to show. There’s actually a way to automate the creation of all of this in less than 5 minutes. However for learning purposes we’ll do everything the long way so we can internalise what is needed for when we create it in Terraform.

I chose the region physically closest to me. You can change it to whatever you want as long as it remains consistent:

Here are the basic steps we will be doing in this section:

1. Create the VPC.
2. Create public / private subnets.
3. Enable a public IPv4 address for the public subnet.
4. Create the Internet Gateway.
5. Attach the IGW to the VPC.
6. Add a default gateway route for the public route table.
7. Explicitly associate the public route table with the public subnet.
8. Create a route table for the private subnet.
9. Configure the rtb’s inbound rules to come from one port (22) from the public subnet
10. Create a security group for the public subnet
11. Edit the security groups inbound rules (allow UDP 51832 from anywhere)

VPC

Go to the VPC Console and Create VPC:

Create the VPC. Below are the settings that I chose:

Create the VPC.

Now we can review:

SUBNETS

We’ll create the Public and Private Subnets. Take note of the information needed for each subnet, like the IPv4 range and the VPC we’re linking to.

Still within the VPC Console, go to Subnets and ‘Create subnet’:

Within the screenshots are the steps to create the Public subnet:

Take note of the IPv4 subnet block and the Availability Zone. We will be using adding this in Terraform manually soon.

Now that that’s done, let’s create the Private subnet:

Create the subnet.

Now we have two newly created subnets:

Now we want to assign ctf-public-subnet with a public IP address:

NOTE: The subnet is still not public. The difference between public and private subnets is their internet connectivity. For a subnet to be considered public, it has to have a route to an Internet Gateway and resources must have a public IPv4 address.

INTERNET GATEWAY

Now we will create an Internet gateway and link it to the route table (which was automatically created):

Now the Internet gateway is attached to the ‘ctf’ VPC. It is still NOT connected to the public subnet yet.

The route table still needs to be updated.

ROUTE TABLES

Now we have to explicitly associate this route table with the public subnet:

CREATE SECURITY GROUPS

Create a security group for the public subnet.

Name the group: ctf-sg-public-subnet

Description: Security group for the public subnet.

We’ll also add a rule:

Create the security Group.

I’ll stop it here with the AWS Management Console. There is more we’ll do with the configurations in Terraform.

TERRAFORM CONFIGURATIONS

Install AWS CLI by following the official AWS documentation here.

Install Terraform for your specific OS by following the Terraform documentation here.

Create the Terraform folders:

mkdir terraform-projects && cd terraform-projects

mkdir ctf-project2026-03-09 && cd ctf-project

CREATE THE TERRAFORM FILES:

touch providers.tf variables.tf main.tf outputs.tf versions.tf

• main.tf — The main configuration file for Terraform.
• outputs.tf — “Terraform output values let you export structured data about your resources. You can use this data to configure other parts of your infrastructure with automation tools, or as a data source for another Terraform workspace.”
• providers.tf — Is used to define what cloud platforms (like AWS, Azure, GCP) will be used.
• variables.tf — Used to define variables.
• versions.tf — Is used to define what version of Terraform will be used to ensure that the configurations remain consistent over time.

Edit the files:

VARIABLES.TF:

There are 3 parameters for the variables.tf file which are default, type, and description.

variable "aws_region" {
        default = "ap-southeast-2"
        description = "The AWS region were our resources will reside."
}

variable "instance_type" {
        default = "t2.micro"
        description = "The instance type of the EC2 instance."
}

variable "ami_id" {
        default = "ami-0ba8d27d35e9915fb"
        description = "The AMI ID of the EC2 insance."
}

variable "az" {
        default = "ap-southeast-2a"
}

I got my AMI ID from EC2 > Instances > Launch an Instance > Chose my AMI and copied the ID:

PROVIDERS.TF:

provider "aws" {
        region = var.aws_region
}

VERSIONS.TF:

terraform {
        required_version = ">= 0.12"

        required_providers {
                aws = {
                        source = "hashicorp/aws"
                        version = "~> 5.0"
                }
        }
}

OUTPUTS.TF:

output "vpc_id" {
        description = "The ID of the VPC."
        value = aws_vpc.ctf_vpc.id
}

output "instance_public_ip" {
       description = "The public IP of the EC2 instance."
       value = aws_instance.ctf_EC2_vpn.public_ip
}

BUILDING MAIN.TF

Here are my initial configurations for main.tf. This is what I started off with and fixed it up heavily down the line.

MAIN.TF:

Virtual Private Cloud — VPC:

## Create the VPC ##

resource  "aws_vpc" "ctf_vpc" {
    cidr_block = "10.0.0.0/16"
    enable_dns_support = true
    enable_dns_hostnames = true
    tags = {
        Name = "ctf_vpc"
    }
}

• Documentation for aws_vpc.

Private Subnet:

## Create the private subnet ##

resource "aws_subnet" "ctf_private_subnet" {
    vpc_id = aws_vpc.ctf_vpc.id
    cidr_block = "10.0.0.0/24"
    availability_zone = var.az
    tags = {
        Name = "ctf_private_subnet"
    }
}

• Documentation for aws_subnet.

Security Group with Rules — Private Subnet:

## Now to create the security group for the PRIVATE subnet ##

resource "aws_security_group" "ctf_sg_private_subnet" {
    name = "sg_private_subnet"
    description = "Allow access from the public subnet only."
    vpc_id = aws_vpc.ctf_vpc.id
}

## Now to create the ingress rules for the PRIVATE subnet ##

resource "aws_vpc_security_group_ingress_rule" "Allow_access_from_public_subnet" {
    security_group_id = aws_security_group.ctf_sg_private_subnet.id
    cidr_ipv4 = "10.0.1.0/24" ## The source IPv4 range ##
    from_port = 22
    to_port = 22
    ip_protocol = "tcp"
}

• Documentation for aws_security_group.
• Documentation for aws_vpc_security_group_ingress_rule.

Route Table — Private Subnet:

## Now to create the route table for the PRIVATE subnet ##

resource "aws_route_table" "ctf_rtb_private_subnet" {
    vpc_id =  aws_vpc.ctf_vpc.id
#   cidr_block = "10.0.0.0/16"
#   gateway_id = "local" ##  this as a local route is already created by default
    tags = {
        Name = "ctf_rtb_private_subnet"
    }
}

## Now we have to associate the routing table wuth the private subnet ##

resource "aws_route_table_association" "ctf_rtb_association_private_subnet" {
    route_table_id = aws_route_table.ctf_rtb_private_subnet.id
    subnet_id = aws_subnet.ctf_private_subnet.id
}

• Documentation for aws_route_table.
• Documentation for aws_route_table_association.

Public Subnet:

## Create the PUBLIC subnet ##

resource "aws_subnet" "ctf_public_subnet" {
    vpc_id = aws_vpc.ctf_vpc.id
    cidr_block = "10.0.1.0/24" 
    availability_zone = var.az
    map_public_ip_on_launch = true  ## Assigns a public IP address on instance launch
    tags = {
        Name = "ctf_public_subnet"
    }
}

• Documentation for aws_subnet.

Security Group with Rules — Public Subnet:

## Now to create the security group for the PUBLIC subnet ##

resource "aws_security_group" "ctf_sg_public_subnet" {
    name = "sg_public_subnet"
    description = "Allow VPN access from everywhere."
    vpc_id = aws_vpc.ctf_vpc.id
    tags = {
        Name = "ctf_sg_public_subnet"
    }
}

## Add rule to allow connections from 0.0.0.0/0 into UDP 51832 ##

resource "aws_vpc_security_group_ingress_rule" "Allow_VPN" {
    security_group_id = aws_security_group.ctf_sg_public_subnet.id
    cidr_ipv4 = "0.0.0.0/0"
    from_port = 51832
    to_port = 51832
    ip_protocol = "udp"
}

• Documentation for aws_security_group.
• Documentation for aws_vpc_security_group_ingress_rule.

Route Table — Public Subnet:

## Now to create the route table for the PUBLIC subnet ##

resource "aws_route_table" "ctf_rtb_public_subnet" {
    vpc_id =  aws_vpc.ctf_vpc.id
    route {
        cidr_block = "0.0.0.0/0"
        gateway_id = aws_internet_gateway.ctf_igw.id
        
    }
    tags = {
        Name = "ctf_rtb_public_subnet"
    }
}

## Now we have to associate the routing table with the public subnet ##

resource "aws_route_table_association" "ctf_rtb_association_public_subnet" {
    route_table_id = aws_route_table.ctf_rtb_public_subnet.id
    subnet_id = aws_subnet.ctf_public_subnet.id
}

• Documentation for aws_route_table.
• Documentation for aws_route_table_association.

Internet Gateway:

## Create an Internet Gateway ##

resource "aws_internet_gateway" "ctf_igw" {
    vpc_id = aws_vpc.ctf_vpc.id
    tags = {
        Name = "ctf_igw"
    }
}

• Documentation for aws_internet_gateway.

TESTING

So far we have added everything in the main.tf file except for the Network Access Control Lists (NACLs) and the EC2 instances themselves.

Message from the future: There was so much more I had to add and fix.

Let’s test out how it’s going:

Run these commands to initialise, plan, and apply the configurations:

terraform init

terraform plan

terraform apply

Now let’s check the AWS management console.

VPC:

Subnets:

Route tables:

Internet Gateway:

Security groups:

Resource map shows that items within the public subnet can reach the Internet Gateway:

Look good to me so far. If there’s any upcoming issues I’ll troubleshoot it.

EC2 & NETWORK ACCESS CONTROL LISTS (NACLs)

Now let’s add the NACLs and the EC2 Instances to the main.tf file.

A Network Access Control list is basically a stateless subnet-level firewall.

Since it’s stateless you must explicitly state inbound rules as well as outbound.

NOTE: We don’t necessarily need to add the NACLs, however it is good to learn how to use them.

• Documentation for aws_network_acl.
• Documentation for aws_instance.

NACL — Private Subnet:

## Now to create the NACL for the private subnet ##

resource "aws_network_acl" "ctf_nacl_private_subnet" {
    vpc_id = aws_vpc.ctf_vpc.id
    subnet_ids = aws_subnet.ctf_private_subnet.id
    ingress {
        protocol   = "tcp"
        rule_no    = 100
        action     = "allow"
        cidr_block = "10.0.0.0/24"
        from_port  = 22
        to_port    = 22
    }
    tags = {
        Name = "ctf_nacl_private_subnet"
  }
}

NACL — Public Subnet:

## Create the NACL for the public subnet ## 

resource "aws_network_acl" "ctf_nacl_public_subnet" {
    vpc_id = aws_vpc.ctf_vpc.id
    subnet_ids = aws_subnet.ctf_public_subnet.id
    ingress {
        protocol   = "udp"
        rule_no    = 100
        action     = "allow"
        cidr_block = "0.0.0.0/0"
        from_port  = 51832
        to_port    = 51832
    }
    tags = {
        Name = "ctf_nacl_public_subnet"
  }
}

EC2 Instance — Vulnerable Instance:

## Now to create the EC2 Instance within the PRIVATE subnet ##

resource "aws_instance" "ctf_EC2_vuln" {
  ami                    = var.ami_id
  availability_zone      = var.az
  instance_type          = var.instance_type
  subnet_id              = aws_subnet.ctf_private_subnet.id
  vpc_security_group_ids = [aws_security_group.ctf_sg_private_subnet.id]
  private_ip             = "10.0.0.10"
  key_name               = aws_key_pair.lumenyx_public_key.id
  tags = {
    Name = "ctf_EC2_vuln"
  }
  root_block_device {
    volume_size = 50
    volume_type = "gp3"
  }
  user_data = <<-EOF
    #!/bin/bash
    sudo apt update
    sudo apt upgrade -y
    sudo apt install docker.io -y
    echo "${var.friend_public_key}" >> /home/ubuntu/.ssh/authorized_keys
    sudo hostnamectl set-hostname vulnerable_instance
    sed -i 's/preserve_hostname: false/preserve_hostname: true/' /etc/cloud/cloud.cfg
  EOF
}

• Within `user_data`, I want to ensure that my friend’s public key is added so he can SSH into the vulnerable box too.

EC2 Instance — VPN Server:

## Now to create the EC2 Instance within the PUBLIC subnet ##

resource "aws_instance" "ctf_EC2_vpn" {
  ami                    = var.ami_id
  availability_zone      = var.az
  instance_type          = var.instance_type
  subnet_id              = aws_subnet.ctf_public_subnet.id
  vpc_security_group_ids = [aws_security_group.ctf_sg_public_subnet.id]
  key_name               = aws_key_pair.lumenyx_public_key.id
  tags = {
    Name = "ctf_EC2_vpn"
  }

  user_data = <<-EOF
  #!/bin/bash
  sudo apt update
  sudo apt upgrade -y
  sudo hostnamectl set-hostname vpn-server
  sed -i 's/preserve_hostname: false/preserve_hostname: true/' /etc/cloud/cloud.cfg
  EOF
}

NOTE: Regarding the private IP address of aws_instance.ctf_EC2_vuln, the first 4 ip addresses of the range is reserved (0 to 3), therefore I couldn’t make it 10.0.0.1.

Now that the EC2 Instances are created, let’s also allow keys for the VPN instance so we can SSH from our host machine.

Added these three variables to variables.tf:

variable "my_public_key" {
        description = "The public key which will be imported into aws_instance.ctf_EC2_vpn"
}

variable "your_public_ip_address" {
        description = "Your actual public IP address. Eg) 1.2.3.4/32 "
}

variable "friend_public_key" {
  description = "Friend's public key: "
}

Added this to main.tf:

## Adding the key pair ##

resource "aws_key_pair" "lumenyx_public_key" {
    key_name = "lumenyx_public_key"
    public_key = var.my_public_key
    tags = {
        Name = "lumenyx_public_key"
    }
}

• Documentation for aws_key_pair.

When you run the terraform plan or terraform apply commands, it will prompt you for your public key as well as your public IP address.

The public key will be used to authenticate SSH access, and the public IP will be used to whitelist only your public IP address.

Now let’s test it out on our host machine if we can SSH into it without a password:

ssh ubuntu@[IP address listed]

It timed out.

I believe the issue is because we didn’t update the NACL configuration to allow SSH, nor did I allow outbound traffic (there’s an implicit deny that blocks all outbound traffic).

After lots of troubleshooting I realised that the rules that I ended up using were too restrictive to allow the CTF to properly take place, which is why I opened it up completely.

Here is what I ended up with:

## Now to create the NACL for the private subnet ##

## Commented this out as this is too complicated for what the CTF needs ##

resource "aws_network_acl" "ctf_nacl_private_subnet" {
    vpc_id = aws_vpc.ctf_vpc.id
    subnet_ids = [aws_subnet.ctf_private_subnet.id] # subnet_ids expects a list, therefore must be in square brackets
#    egress {
#        protocol   = "-1"
#        rule_no    = 100
#        action     = "allow"
#        cidr_block = "10.0.1.0/24"
#       from_port  = 0
#        to_port    = 0
#   }
#   ingress {
#       protocol   = "tcp"
#       rule_no    = 100
#       action     = "allow"
#       cidr_block = "10.0.1.0/24"
#       from_port  = 22
#       to_port    = 22
#   }
#   ingress {  ## Allow ICMP Echo Reply ##
#       protocol = "icmp"
#       rule_no = 101
#       action = "allow"
#       cidr_block = "10.0.1.0/24"
#       from_port = 0
#       to_port = 0
#   }
#   ingress {  ## Allow ICMP Echo Response ##
#       protocol = "icmp"
#       rule_no = 102
#       action = "allow"
#       cidr_block = "10.0.1.0/24"
#       from_port = 0
#       to_port = 0
#       icmp_type = 8
#   }
   
    ingress {
        protocol   = -1
        rule_no    = 100
        action     = "allow"
        cidr_block = "0.0.0.0/0"
        from_port  = 0
        to_port    = 0
    }
    egress {
        protocol   = -1
        rule_no    = 100
        action     = "allow"
        cidr_block = "0.0.0.0/0"
        from_port  = 0
        to_port    = 0
    }
   tags = {
       Name = "ctf_nacl_private_subnet"
 }
}

## Create the NACL for the public subnet ##

resource "aws_network_acl" "ctf_nacl_public_subnet" {
    vpc_id = aws_vpc.ctf_vpc.id
    subnet_ids = [aws_subnet.ctf_public_subnet.id]

    ingress {  ## Allow inbound VPN traffic ##
        protocol   = "udp"
        rule_no    = 100
        action     = "allow"
        cidr_block = "0.0.0.0/0"
        from_port  = 51832
        to_port    = 51832
    }
   ingress { ## Allow SSH from only my public IP address ##
        protocol = "tcp"
        rule_no = 101
        action = "allow"
       cidr_block = var.your_public_ip_address
        from_port = 22
        to_port = 22
    }
    ingress { ## Allow TCP traffic on ephemeral ports ##
        protocol = "tcp"
        rule_no = 102
        action = "allow"
        cidr_block = "0.0.0.0/0"
        from_port = 1024
        to_port = 65535
    }
    ingress { ## Allow UDP traffic on ephemeral ports ##
        protocol = "udp"
        rule_no = 103
        action = "allow"
        cidr_block = "0.0.0.0/0"
        from_port = 1024
        to_port = 65535
    }
    ingress { ## Allow ICMP Echo Replies ##
        protocol = "icmp"
        rule_no = 104
        action = "allow"
        cidr_block = "0.0.0.0/0"
        from_port = 0
        to_port = 0
    }
    ingress { ## Allow all traffic from 10.0.0.0/16 ##
        protocol = -1
        rule_no = 105
        action = "allow"
        cidr_block = "10.0.0.0/16"
        from_port = 0
        to_port = 0
    }
    egress { ## Allow all outbound traffic ##
        protocol   = "-1"
        rule_no    = 100
        action     = "allow"
        cidr_block = "0.0.0.0/0"
        from_port  = 0
        to_port    = 0
    }
    tags = {
        Name = "ctf_nacl_public_subnet"
  }
}

Now lets try to SSH into it now:

FIXING SSH — THE VULNERABLE INSTANCE

I’m not able to SSH into the vulnerable instance yet. It keeps timing out.

I believe the issue is that there is a missing outbound rule for the public subnet’s security group. Therefore I added this resource:

resource "aws_vpc_security_group_egress_rule" "Allow_all_outbound_from_private_subnet" {
    security_group_id = aws_security_group.ctf_sg_private_subnet.id
    cidr_ipv4 = "0.0.0.0/0" ## The destination IPv4 range ##
    ip_protocol = -1
}

As long as the VPN is on, I can now SSH into the vulnerable server from my host machine.

However there’s another issue. It cannot connect to the internet as it’s in a private subnet.

It needs an internet connection to pull docker images and dependencies for the CTF.

We can resolve this by adding a NAT Gateway.

NAT GATEWAY AND ELASTIC IP

A NAT Gateway is used to allow resources in a private subnet to initiate outbound connections to the internet without the internet being able to talk to these resources directly.

The NAT gateway must be attached to a public subnet and also have an elastic IP address attached.

NAT Gateway:

## Adding the NAT Gateway ##

resource "aws_nat_gateway" "ctf_nat_gw" {
    allocation_id = aws_eip.ctf_nat_gw_eip.id
    subnet_id = aws_subnet.ctf_public_subnet.id
}

• Documentation for aws_nat_gateway.

Elastic IP:

## Allocating an Elastic IP address for the NAT gw ##

resource "aws_eip" "ctf_nat_gw_eip" {
    tags = {
        Name = "ctf_nat_gw_eip"
    }
    depends_on = [aws_internet_gateway.ctf_igw]
}

• Documentation for aws_eip.

That’s all the configurations for main.tf. Here is the finished version:

## Create the VPC ##

resource "aws_vpc" "ctf_vpc" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = {
    Name = "ctf_vpc"
  }
}

## Create the private subnet ##

resource "aws_subnet" "ctf_private_subnet" {
  vpc_id            = aws_vpc.ctf_vpc.id
  cidr_block        = "10.0.0.0/24"
  availability_zone = var.az
  tags = {
    Name = "ctf_private_subnet"
  }
}

## Now to create the security group for the PRIVATE subnet ##

resource "aws_security_group" "ctf_sg_private_subnet" {
  name        = "sg_private_subnet"
  description = "Allow access from the public subnet only."
  vpc_id      = aws_vpc.ctf_vpc.id
  tags = {
    Name = "ctf_sg_private_subnet"
  }
}

## Now to allow SSH from the private subnet ##

resource "aws_vpc_security_group_ingress_rule" "Allow_access_from_public_subnet" {
  security_group_id = aws_security_group.ctf_sg_private_subnet.id
  cidr_ipv4         = "10.0.1.0/24" ## The source IPv4 range ##
  from_port         = 22
  to_port           = 22
  ip_protocol       = "tcp"
}

## Allow ICMP traffic to the PRIVATE subnet ##

resource "aws_vpc_security_group_ingress_rule" "Allow_ICMP" {
  security_group_id = aws_security_group.ctf_sg_private_subnet.id
  cidr_ipv4         = "10.0.1.0/24" ## The source IPv4 range ##
  from_port         = -1
  to_port           = -1
  ip_protocol       = "icmp"
}

## Allow all egress out of the private subnet ##

resource "aws_vpc_security_group_egress_rule" "Allow_all_outbound_from_private_subnet" {
  security_group_id = aws_security_group.ctf_sg_private_subnet.id
  cidr_ipv4         = "0.0.0.0/0" ## The destination IPv4 range ##
  ip_protocol       = -1
}

## Create the PUBLIC subnet ##

resource "aws_subnet" "ctf_public_subnet" {
  vpc_id                  = aws_vpc.ctf_vpc.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = var.az
  map_public_ip_on_launch = true ## Assigns a public IP address on instance launch
  tags = {
    Name = "ctf_public_subnet"
  }
}

## Now to create the security group for the PUBLIC subnet ##

resource "aws_security_group" "ctf_sg_public_subnet" {
  name        = "sg_public_subnet"
  description = "Allow VPN access from everywhere."
  vpc_id      = aws_vpc.ctf_vpc.id
  tags = {
    Name = "ctf_sg_public_subnet"
  }
}

## Add rule to allow connections from 0.0.0.0/0 into UDP 51832 ##

resource "aws_vpc_security_group_ingress_rule" "Allow_VPN" {
  security_group_id = aws_security_group.ctf_sg_public_subnet.id
  cidr_ipv4         = "0.0.0.0/0"
  from_port         = 51832
  to_port           = 51832
  ip_protocol       = "udp"
}

## Add rule to allow connections from 0.0.0.0/0 into TCP 22 ##
## Alternatively you can change cidr_ipv4 to be your public IP address ##

resource "aws_vpc_security_group_ingress_rule" "Allow_SSH" {
  security_group_id = aws_security_group.ctf_sg_public_subnet.id
  cidr_ipv4         = var.your_public_ip_address
  from_port         = 22
  to_port           = 22
  ip_protocol       = "tcp"
}

resource "aws_vpc_security_group_egress_rule" "Allow_all_outbound" {
  ip_protocol       = "-1" ## All protocols ##
  security_group_id = aws_security_group.ctf_sg_public_subnet.id
  cidr_ipv4         = "0.0.0.0/0"
  description       = "Allow all outbound traffic"
}

## Now to create the route table for the PRIVATE subnet ##

resource "aws_route_table" "ctf_rtb_private_subnet" {
  vpc_id = aws_vpc.ctf_vpc.id
  route {
    #   cidr_block = "10.0.0.0/16"
    #   gateway_id = "local" ##  this as a local route is already created by default
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.ctf_nat_gw.id
  }
  tags = {
    Name = "ctf_rtb_private_subnet"
  }
}

## Now we have to associate the routing table wuth the private subnet ##

resource "aws_route_table_association" "ctf_rtb_association_private_subnet" {
  route_table_id = aws_route_table.ctf_rtb_private_subnet.id
  subnet_id      = aws_subnet.ctf_private_subnet.id
}

## Create an Internet Gateway ##

resource "aws_internet_gateway" "ctf_igw" {
  vpc_id = aws_vpc.ctf_vpc.id
  tags = {
    Name = "ctf_igw"
  }
}

## Now to create the route table for the PUBLIC subnet ##

resource "aws_route_table" "ctf_rtb_public_subnet" {
  vpc_id = aws_vpc.ctf_vpc.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.ctf_igw.id

  }
  tags = {
    Name = "ctf_rtb_public_subnet"
  }
}

## Now we have to associate the routing table with the public subnet ##

resource "aws_route_table_association" "ctf_rtb_association_public_subnet" {
  route_table_id = aws_route_table.ctf_rtb_public_subnet.id
  subnet_id      = aws_subnet.ctf_public_subnet.id
}

## Now to create the NACL for the private subnet ##

## Commented this out as this is too restrictive for what the CTF needs ##

resource "aws_network_acl" "ctf_nacl_private_subnet" {
  vpc_id     = aws_vpc.ctf_vpc.id
  subnet_ids = [aws_subnet.ctf_private_subnet.id] # subnet_ids expects a list, therefore must be in square brackets
  #    egress {
  #        protocol   = "-1"
  #        rule_no    = 100
  #        action     = "allow"
  #        cidr_block = "10.0.1.0/24"
  #       from_port  = 0
  #        to_port    = 0
  #   }
  #   ingress {
  #       protocol   = "tcp"
  #       rule_no    = 100
  #       action     = "allow"
  #       cidr_block = "10.0.1.0/24"
  #       from_port  = 22
  #       to_port    = 22
  #   }
  #   ingress {  ## Allow ICMP Echo Reply ##
  #       protocol = "icmp"
  #       rule_no = 101
  #       action = "allow"
  #       cidr_block = "10.0.1.0/24"
  #       from_port = 0
  #       to_port = 0
  #   }
  #   ingress {  ## Allow ICMP Echo Response ##
  #       protocol = "icmp"
  #       rule_no = 102
  #       action = "allow"
  #       cidr_block = "10.0.1.0/24"
  #       from_port = 0
  #       to_port = 0
  #       icmp_type = 8
  #   }

  ingress {
    protocol   = -1
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }
  egress {
    protocol   = -1
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }
  tags = {
    Name = "ctf_nacl_private_subnet"
  }
}

## Create the NACL for the public subnet ##

resource "aws_network_acl" "ctf_nacl_public_subnet" {
  vpc_id     = aws_vpc.ctf_vpc.id
  subnet_ids = [aws_subnet.ctf_public_subnet.id]


  ingress {
    protocol   = "udp"
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 51832
    to_port    = 51832
  }
  ingress {
    protocol   = "tcp"
    rule_no    = 101
    action     = "allow"
    cidr_block = var.your_public_ip_address
    from_port  = 22
    to_port    = 22
  }
  ingress {
    protocol   = "tcp"
    rule_no    = 102
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 1024
    to_port    = 65535
  }
  ingress {
    protocol   = "udp"
    rule_no    = 103
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 1024
    to_port    = 65535
  }
  ingress {
    protocol   = "icmp"
    rule_no    = 104
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }
  ingress {
    protocol   = -1
    rule_no    = 105
    action     = "allow"
    cidr_block = "10.0.0.0/16"
    from_port  = 0
    to_port    = 0
  }
  egress {
    protocol   = "-1"
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }
  tags = {
    Name = "ctf_nacl_public_subnet"
  }
}

## Now to create the EC2 Instance within the PRIVATE subnet ##

resource "aws_instance" "ctf_EC2_vuln" {
  ami                    = var.ami_id
  availability_zone      = var.az
  instance_type          = var.instance_type
  subnet_id              = aws_subnet.ctf_private_subnet.id
  vpc_security_group_ids = [aws_security_group.ctf_sg_private_subnet.id]
  private_ip             = "10.0.0.10"
  key_name               = aws_key_pair.lumenyx_public_key.id
  tags = {
    Name = "ctf_EC2_vuln"
  }
  root_block_device {
    volume_size = 50
    volume_type = "gp3"
  }
  user_data = <<-EOF
    #!/bin/bash
    sudo apt update
    sudo apt upgrade -y
    sudo apt install docker.io -y
    echo "${var.friend_public_key}" >> /home/ubuntu/.ssh/authorized_keys
  EOF
}

## Adding the key pair ##

resource "aws_key_pair" "lumenyx_public_key" {
  key_name   = "lumenyx_public_key"
  public_key = var.my_public_key
  tags = {
    Name = "lumenyx_public_key"
  }
}

## Now to create the EC2 Instance within the PUBLIC subnet ##

resource "aws_instance" "ctf_EC2_vpn" {
  ami                    = var.ami_id
  availability_zone      = var.az
  instance_type          = var.instance_type
  subnet_id              = aws_subnet.ctf_public_subnet.id
  vpc_security_group_ids = [aws_security_group.ctf_sg_public_subnet.id]
  key_name               = aws_key_pair.lumenyx_public_key.id
  tags = {
    Name = "ctf_EC2_vpn"
  }

  user_data = <<-EOF
  #!/bin/bash
  sudo apt update
  sudo apt upgrade -y
  EOF
}

## Adding the NAT Gateway ##

resource "aws_nat_gateway" "ctf_nat_gw" {
  allocation_id = aws_eip.ctf_nat_gw_eip.id
  subnet_id     = aws_subnet.ctf_public_subnet.id
}

## Allocating an Elastic IP address for the NAT gw ##

resource "aws_eip" "ctf_nat_gw_eip" {
  tags = {
    Name = "ctf_nat_gw_eip"
  }
  depends_on = [aws_internet_gateway.ctf_igw]
}

INSTALLING WIREGUARD WITH PIVPN

Now I’ll SSH into the VPN server and install WireGuard:

ssh ubuntu@[public-IP]

Now let’s update everything:

sudo apt update && sudo apt upgrade -y

Install PiVPN:

curl -L https://install.pivpn.io | bash

Go through the installer:

Ensure the port is UDP 51832:

Now we can add everyone’s profile and generate keys for them to log into the VPN:

pivpn -a

I’ll supply the configurations with the players:

cat ~/configs/[configuration file]

CONCLUSION

Now every client who has a configuration can now access the public subnet, and from there they can attack the vulnerable server in the other subnet.

How to connect to the VPN server.

We’re all set! I’ll see you on game day.

Authentik is an open-source identity provider that you host yourself, so your logins and user data stay on your own hardware instead of with a third-party service.

In this guide we’ll use it to issue SSH certificates.

This is part 3 of my 3 part series.

1. Set up a Private Certificate Authority
2. Set up SSH certificates
3. Set up Authentik so SSH certificates are provisioned when logged into.

For more detailed information about this, please refer to the official documentation.

HOW IT LOOKS ONCE IT’S SET UP

1. You’re unable to SSH in.

2. You run the step ssh certificate command.

3. You put in your username and password when the browser opens.

4. You can now SSH into authorised machines as you have now been given a valid SSH certificate.

CREATE THE AUTHENTIK DOCKER CONTAINER

Create a dedicated folder:

mkdir authentik && cd authentik

Download the Docker compose file:

wget https://docs.goauthentik.io/compose.yml

Generate PostgreSQL Password and Secret Key:

echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env

Comment out the /var/run/docker.sock:/var/run/docker.sock line:

services:
  postgresql:
    env_file:
    - .env
    environment:
      POSTGRES_DB: ${PG_DB:-authentik}
      POSTGRES_PASSWORD: ${PG_PASS:?database password required}
      POSTGRES_USER: ${PG_USER:-authentik}
    healthcheck:
      interval: 30s
      retries: 5
      start_period: 20s
      test:
      - CMD-SHELL
      - pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}
      timeout: 5s
    image: docker.io/library/postgres:16-alpine
    restart: unless-stopped
    volumes:
    - database:/var/lib/postgresql/data
  server:
    command: server
    depends_on:
      postgresql:
        condition: service_healthy
    env_file:
    - .env
    environment:
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY:?secret key required}
    image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2026.8.5}
    ports:
#    - ${COMPOSE_PORT_HTTP:-9000}:9000 ## I want to use HTTPS exclusively ##
    - ${COMPOSE_PORT_HTTPS:-9443}:9443
    restart: unless-stopped
    shm_size: 512mb
    volumes:
    - ./data:/data
    - ./custom-templates:/templates
  worker:
    command: worker
    depends_on:
      postgresql:
        condition: service_healthy
    env_file:
    - .env
    environment:
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY:?secret key required}
    image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2026.8.5}
    restart: unless-stopped
    shm_size: 512mb
    user: root
    volumes:
#    - /var/run/docker.sock:/var/run/docker.sock # We only need this if 
    - ./data:/data                               # we use Outposts 
    - ./certs:/certs
    - ./custom-templates:/templates
volumes:
  database:
    driver: local

The reason we are commenting out the /var/run/docker.sock line is because “Mounting the Docker socket to a container comes with some inherent security risks. To reduce these risks, you can use a Docker Socket Proxy as an additional layer of protection.”

Here is how it’s a security risk:

Some apps can’t log users in through Authentik directly because they only understand older protocols like LDAP. This is when Authentik uses an ‘outpost’, which is a helper container that Authentik spins up (on its own) that sits between the app and Authentik and translates between the two.

In order to spin up this helper container, Authentik needs admin-level access to Docker. It gets this power by having the host’s /var/run/docker.sock (which is the Docker socket) mounted into the container at the same path /var/run/docker.sock.

Think of /var/run/docker.sock as the entry point for controlling Docker. Every docker command (like docker run) goes through here.

In the above scenario, we would be giving the container access to the entry point for controlling Docker, because it needs to create and remove helper containers.

If the container were to become compromised then an attacker could use that access to create a new container with your whole filesystem mounted inside it, essentially giving them root on the host machine.

Apps that support modern standards like OIDC and SAML don’t need an outpost at all as they can talk to Authentik directly. Therefore they don’t need to mount /var/run/docker.sock.

In today’s scenario we don’t need outposts, so commenting out that line is fine.

Create the container:

docker compose up -d

You can now log in:

https://<your server's IP or hostname>:9443

ISSUE A CERTIFICATE FOR AUTHENTIK

Here is the official documentation for TLS certificates.

1. Install Step-CLI for your operating system.

2. Ensure you’re in the authentik container directory:

cd ~/authentik

3. Use the hostname that you will type into the browser to reach the service:

step ca certificate authentik-worker-1 \
~/authentik/certs/authentik-worker-1.crt \
~/authentik/certs/authentik-worker-1.key \
--san <main-service-hostname> \
--san <any-additional-hostnames/ip-addresses>

In my specific case:

step ca certificate authentik-worker-1 \
~/docker-files/authentik/certs/authentik-worker-1.crt \
~/docker-files/authentik/certs/authentik-worker-1.key \
--san endeavour-pi-01-tailscale \
--san 100.117.215.78

The certificate is named after the authentik-worker-1 container because that’s where the certs folder is located (see compose.yml below).

GIVE THE AUTHENTIK CONTAINER ACCESS TO THE CERTIFICATE

step creates the certificate files so that only your user can read them, however the container needs to be able to read them too.

1. On the machine hosting the container, find out which user the container runs as:

docker exec authentik-worker-1 id

Look at the uid at the start of the output. If it’s uid=0(root), the container runs as root and can already read the files, so skip to step 3.

If the uid is any other number, continue to step 2, even if the gid is 0.

For example, Grafana shows uid=472(grafana) gid=0(root). It runs as an ordinary user, so it still needs step 2:

2. Note the gid number. Give that group read-only access to the key and make the certificate readable:

sudo chgrp <gid> certs/authentik-worker-1.key
chmod 640 certs/authentik-worker-1.key
chmod 644 certs/authentik-worker-1.crt

The certificate is public (644) and the key is restricted to those who own it and the container’s group (640).

3. Restart the container:

docker compose up -d

CONFIGURE THE WEB CERTIFICATE

Time to get rid of the HTTPS ‘Not Secure’ error.

1. Within the admin interface, go to System > Brands > Actions:

2. Select ‘authentik-worker-1’ as the Web Certificate:

3. Now visit the website but with the DNS name instead. In my case:

https://endeavour-pi-01-tailscale:9443

4. The certificate error should no longer be present.

SET UP CERTIFICATE AUTO-RENEW

We are going to create the service on the machine that hosts the service whose certificate you want to auto-renew.

Run this as your normal user (not root) if you haven’t set it up before:

sudo tee /etc/systemd/system/cert-renewer@.service > /dev/null << EOF
[Unit]
Description=Renew certificate %i
After=network-online.target

[Service]
Type=oneshot
User=$USER
Environment=STEPPATH=$HOME/.step
Environment=CERT=$HOME/certs/%i.crt
Environment=KEY=$HOME/certs/%i.key
ExecCondition=/usr/bin/step certificate needs-renewal \${CERT}
ExecStart=/usr/bin/step ca renew --force \${CERT} \${KEY}
ExecStartPost=-/bin/chmod 644 \${CERT}
ExecStartPost=-/bin/sh -c 'docker inspect -f "{{.State.Running}}" %i 2>/dev/null | grep -qx true && docker restart %i'
EOF

This is used for the certificates in the ~/certs directory (see here for more context).

Create the timer on the machine that hosts the service whose certificate you want to auto-renew (if you haven’t set it up before):

sudo tee /etc/systemd/system/cert-renewer@.timer > /dev/null << EOF
[Unit]
Description=Check certificate %i for renewal

[Timer]
OnCalendar=*:0/15
RandomizedDelaySec=60
Persistent=true

[Install]
WantedBy=timers.target
EOF

This timer checks every 15 minutes if a certificate needs renewing.

• @ marks a template in systemd. It’s used for one file that’s used many times, each time under a different name. @ comes right before the name, and before the extension (.timer).
  E.g. cert-renewer@grafana.timer
• %i is used as a placeholder for ‘whatever comes after the @’.

Now we will add an override so the renewer uses Authentik’s certificate.

By default it looks in ~/certs, but Authentik keeps its certificates in its own certs folder. The override changes the location for Authentik only, so the other certificates aren’t affected:

sudo mkdir -p /etc/systemd/system/cert-renewer@authentik-worker-1.service.d
sudo tee /etc/systemd/system/cert-renewer@authentik-worker-1.service.d/override.conf > /dev/null << 'EOF'
[Service]
Environment=CERT=/home/<YOUR_USERNAME>/authentik/certs/%i.crt
Environment=KEY=/home/<YOUR_USERNAME>/authentik/certs/%i.key
EOF

In my specific case:

sudo mkdir -p /etc/systemd/system/cert-renewer@authentik-worker-1.service.d
sudo tee /etc/systemd/system/cert-renewer@authentik-worker-1.service.d/override.conf > /dev/null << 'EOF'
[Service]
Environment=CERT=/home/lumenyx/docker-files/authentik/certs/%i.crt
Environment=KEY=/home/lumenyx/docker-files/authentik/certs/%i.key
EOF

Now reload systemd:

sudo systemctl daemon-reload

Enable the cert-renewer timer:

CERT_NAME=$(basename -s .crt certs/*.crt)

sudo systemctl enable --now cert-renewer@${CERT_NAME}.timer

Check the timer is working:

systemctl list-timers 'cert-renewer*'

Confirm that the service itself works:

sudo systemctl start cert-renewer@${CERT_NAME}.service
journalctl -u cert-renewer@${CERT_NAME}.service -n 20

The logs may say that it was skipped, this is fine since it’s not time to renew the certificate.

Oct 28 22:48:52 ENDEAVOUR-PI-01 systemd[1]: Starting cert-renewer@authentik-worker-1.service - Renew certificate authentik-worker-1...
Oct 28 22:48:52 ENDEAVOUR-PI-01 systemd[1]: cert-renewer@authentik-worker-1.service: Skipped due to 'exec-condition'.
Oct 28 22:48:52 ENDEAVOUR-PI-01 systemd[1]: Condition check resulted in cert-renewer@authentik-worker-1.service - Renew certificate authentik-worker-1 being skipped.

However if you see a ‘file not found’ error instead, then that may be due to a misconfiguration.

When the certificate renews you will be able to see it:

journalctl -u cert-renewer@authentik-worker-1.service --no-pager | grep -C10 "Your certificate has been saved"

FINALLY SETTING UP AUTHENTIK TO RENEW SSH CERTIFICATES

1. Log into Authentik with your admin account and click on Manage users:

Click on New User:

Choose Internal User:

Then create the account.

IMPORTANT: The name before the @ (user@domain), has to be the same as the SSH username, or else it won’t work.

Create an ssh-users group:

Then add your user into the group.

Now to create the SSH Renewal application:

Choose OAuth2/OpenID Provider:

For Authorization Flow choose the implicit-consent option:

Note down the Client ID and Client Secret:

Redirect URIs/Origins (RegEx):

http://127\.0\.0\.1:\d+.*

• After you log in on the SSH client, Authentik redirects your browser to the redirect URI (in this case 127.0.0.1:<random-port>) carrying a one-time code that step uses to finish the login.

Signing Key: authentik Self-signed Certificate

The ‘authentik Self-signed Certificate’ is used to sign the login tokens and prove to the Certificate Authority that they actually came from Authentik and that they haven’t been changed.

This screen outlines who can get an SSH certificate through Authentik. If you leave it empty then every Authentik user can get one:

I will configure it to only allow users who are part of ‘ssh-users’ to have this access:

Now we need to add a provisioner (the thing that tells step-ca how to check who you are before it signs a certificate).

On the machine that is hosting the Certificate Authority, run this command:

docker exec -it step-ca step ca provisioner add authentik --type OIDC \
--client-id <CLIENT_ID> \
--client-secret <CLIENT_SECRET> \
--configuration-endpoint=<OpenID_Configuration_URL>

In my specific case:

docker exec -it step-ca step ca provisioner add authentik --type OIDC \
--client-id c82XSYTXEWmeOaZZaJaoariK8n6QjegM8rc4j80q \
--client-secret <CLIENT_SECRET> \
--configuration-endpoint=https://endeavour-pi-01-tailscale:9443/application/o/ssh-certificate-renewal/.well-known/openid-configuration

• Admin name: step
• Password: Your CA password

Restart the CA container:

docker restart step-ca

Crap. Ran into an issue. The container cannot resolve the hostname since it’s using 8.8.8.8:

We’ll have to reconfigure the step-ca container to use our internal DNS server.

We have to remove the container (since it was spun up using docker run):

docker rm -f step-ca

Recreate the container:

docker run -d --name step-ca --restart unless-stopped \
    -v step:/home/step \
    -p 9000:9000 \
    --dns <DOCKER_BRIDGE_GATEWAY_IP OR LAN_IP> \
    -e "SSL_CERT_DIR=/etc/ssl/certs:/home/step/certs" \
    -e "DOCKER_STEPCA_INIT_NAME=Smallstep" \
    -e "DOCKER_STEPCA_INIT_DNS_NAMES=localhost,$(hostname -f),<hostname-clients-use-to-reach-the-ca>,<ipaddr-clients-will-use-to-reach-the-ca>" \
    -e "DOCKER_STEPCA_INIT_REMOTE_MANAGEMENT=true" \
    -e "DOCKER_STEPCA_INIT_SSH=true" \
    smallstep/step-ca:0.30.2

• --dns sends the container’s DNS lookups to Pi-hole which is on the same machine. If the DNS server was a different machine then we would just use the LAN IP.
• -e “SSL_CERT_DIR=/etc/ssl/certs:/home/step/certs” This is used so that step-ca trusts its own root certificate when acting as an ordinary HTTPS client.

If the DNS server is on the same machine as the step-ca container then you can find the Docker bridge gateway IP like so:

docker network inspect bridge | grep Gateway

Add the provisioner:

docker exec -it step-ca step ca provisioner add authentik --type OIDC \
--client-id <CLIENT_ID> \
--client-secret <CLIENT_SECRET> \
--configuration-endpoint=<OpenID_Configuration_URL>

On the SSH client, run this command to get a new SSH certificate:

step ssh certificate <YOUR_AUTHENTIK_EMAIL> ~/.ssh/id_ecdsa --provisioner authentik

In my specific case:

step ssh certificate lumenyx@endeavour.com ~/.ssh/id_ecdsa --provisioner authentik --no-password --insecure

• I added the --no-password --insecure so my private key isn’t protected by a passphrase. I don’t want to put in 2 password since I already incorporate SSH passwords AND keys.

It will open a browser:

Then you log in with the account you set up earlier:

And you’re in:

WHAT WE’LL BE DOING

We’ll set up SSH user and host certificates so that a client with 1 valid SSH certificate can log into approved SSH servers.

The certificate will expire after 16 hours and will (at this stage) need to be renewed manually.

This is part 2 of my 3 part series.

1. Set up a Private Certificate Authority
2. Set up SSH certificates
3. Set up Authentik so SSH certificates are provisioned when logged into.

HOW SSH CERTIFICATES WORK

A CA signs the SSH client’s public key (newly created by step ssh certificate and saved as ~/.ssh/id_ecdsa.pub) along with the usernames it may log in as, and any server that trusts the CA’s user public key (/etc/ssh/ssh_user_ca.pub) will believe it.

A CA signs the SSH server’s public key (/etc/ssh/ssh_host_ed25519_key.pub) along with its hostnames, and any client that trusts the CA’s host public key (the @cert-authority line in ~/.ssh/known_hosts) will believe it.

We will go over this process below.

THE GENERAL PROCESS

SETUP (DONE ONCE)

1. The CA has two key pairs: a host CA pair used for signing SSH servers, and a user CA pair used for signing people.

• Private Host CA Key: /var/lib/docker/volumes/step/_data/secrets/ssh_host_ca_key
• Private User CA Key: /var/lib/docker/volumes/step/_data/secrets/ssh_user_ca_key

• Public Host CA Key: /var/lib/docker/volumes/step/_data/certs/ssh_host_ca_key.pub
• Public User CA Key: /var/lib/docker/volumes/step/_data/certs/ssh_user_ca_key.pub

2. Each SSH server and SSH client is set up so it can securely talk to the CA (bootstrapping). This uses the fingerprint of the CA’s root SSL certificate (not the SSH keys), and it does this once per machine.

On SSH servers, bootstrapping is run with sudo. (The renewal service and writing to /etc/ssh needs root permissions)

On SSH clients, bootstrapping is run as a normal user.

3. Each SSH server gives the CA its public key (/etc/ssh/ssh_host_ed25519_key.pub) along with its valid hostnames.

The CA then signs them with its private host CA key (/var/lib/docker/volumes/step/_data/secrets/ssh_host_ca_key), and that becomes the SSH server’s host certificate (/etc/ssh/ssh_host_ed25519_key-cert.pub).

This host certificate is what each SSH server presents to every connecting SSH client so that the client can confirm the authenticity of the SSH server (as long as the client has the CA’s public host key stored, which we will get to shortly).

4. Each SSH server is then told to trust the CA’s public user key. We do this by copying the /var/lib/docker/volumes/step/_data/certs/ssh_user_ca_key.pub onto each SSH server (saved as /etc/ssh/ssh_user_ca.pub) and telling SSH to trust it.

5. Each SSH client is told to trust the CA’s public host key, via the @cert-authority line in known_hosts.

WHEN THE USER CERTIFICATE EXPIRES

6. When the user certificate expires, you run step ssh certificate. The SSH client makes a new private/public key pair and sends the public key and username to the CA. The CA then sends back a user certificate.

Three files are saved on the SSH client:

• The private key (made by step ssh certificate): ~/.ssh/id_ecdsa
• The public key (made by step ssh certificate): ~/.ssh/id_ecdsa.pub
• The user certificate (sent back by the CA): ~/.ssh/id_ecdsa-cert.pub

The user certificate is valid for 16 hours by default.

WHEN AN SSH CLIENT CONNECTS TO AN SSH SERVER

7. The SSH server shows its host certificate. The SSH client checks that this certificate is signed by the host CA.

8. The SSH client shows its user certificate. The SSH server checks that this certificate is signed by the user CA.

9. Each side proves it holds the private key that matches its certificate by digitally signing a piece of data unique to this connection with that private key. The other side then checks the digital signature using the public key inside the certificate.

DO THIS ON EACH SERVER

1. Install step-cli:

Depending on your operating system the installation may vary. Please consult the installation documentation.

I am using Ubuntu:

sudo apt-get update && sudo apt-get install -y --no-install-recommends curl gpg ca-certificates
sudo install -d -m 0755 /etc/apt/keyrings
sudo curl -fsSL https://packages.smallstep.com/keys/apt/repo-signing-key.gpg -o /etc/apt/keyrings/smallstep.asc
sudo tee /etc/apt/sources.list.d/smallstep.sources > /dev/null << EOF
Types: deb
URIs: https://packages.smallstep.com/stable/debian
Suites: debs
Components: main
Signed-By: /etc/apt/keyrings/smallstep.asc
EOF
sudo apt-get update && sudo apt-get -y install step-cli

2. Get the fingerprint of the root TLS certificate (we will only use this cert for the initial bootstrap).

You can get this by going to the machine that hosts the container and running:

CA_FINGERPRINT=$(docker run --rm -v step:/home/step smallstep/step-ca:0.30.2  step certificate fingerprint certs/root_ca.crt)
echo $CA_FINGERPRINT

3. Set your server up so it can securely talk to our Certificate Authority (bootstrapping):

Ensure it is run with sudo since the later steps run as root:

sudo step ca bootstrap --ca-url https://<CA_HOSTNAME/IP>:9000 --fingerprint $CA_FINGERPRINT --install

Confirm the health from each of the servers that you’re bootstrapping:

curl https://<CA_IP/HOSTNAME>:9000/health

4. From the SSH server, copy the ssh_user_ca_key.pub key (from the CA) into the /etc/ssh/ directory (in the server):

sudo sh -c 'step ssh config --roots > /etc/ssh/ssh_user_ca.pub'

5. Have the sshd_config.d on all the servers trust the SSH user CA key (ssh_user_ca_key.pub):

echo 'TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub' | sudo tee /etc/ssh/sshd_config.d/00-step-ca.conf

• Think of the sshd_config.d directory as a place for extra SSH settings.
• We are creating a new file called 00-step-ca.conf in the /etc/ssh/sshd_config.d folder. Its name starts with a ‘00’ so it loads first.
• More info on the tee command is here.

6. Test the validity of the SSH configuration files. If it prints nothing then we’re all good:

sudo sshd -t

7. Reload the sshd daemon:

sudo systemctl reload sshd

GIVE EACH SERVER A HOST CERTIFICATE

Now we’ll set up a way to verify the authenticity of the SSH servers.

Ask your CA to sign the server’s existing host public key, which will then produce a host certificate.

(/etc/ssh/ssh_host_ed25519_key.pub (on the SSH server)
+
/var/lib/docker/volumes/step/_data/secrets/ssh_host_ca_key (on the CA)
=
/etc/ssh/ssh_host_ed25519_key-cert.pub (on the SSH server))

1. Do this on each server:

sudo step ssh certificate --host --sign \
--principal <hostname> \
--principal <server-ip-address> \
--principal <hostname-your-domain> \
<hostname> /etc/ssh/ssh_host_ed25519_key.pub

--principal lists the names the cert is valid for. It will accept the name you put into your ssh command (eg ssh lumenyx@principal). Ensure you list all the names/principals that you would use when logging in.

2. Add a line to this configuration file on each ssh server. This will hand this certificate to anyone who connects:

echo 'HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub' | sudo tee -a /etc/ssh/sshd_config.d/00-step-ca.conf

Confirm that you see two lines:

sudo cat /etc/ssh/sshd_config.d/00-step-ca.conf

3. Test and reload ssh:

sudo sshd -t

sudo systemctl reload sshd

SET UP SSH HOST RENEWALS

We’ll have to set up auto-renewal as host certs (what proves the ssh server is genuine) expire after 30 days.

To set up renewal, we use a provisioner called SSHPOP (SSH Proof Of Possession). Check if we have it installed.

Run this on the device that hosts the CA:

docker exec step-ca step ca provisioner list

Look for SSHPOP. If it’s there then we’re good to continue.

1. Run this on each SSH server to create a renewal service:

sudo tee /etc/systemd/system/ssh-host-renew.service > /dev/null << 'EOF'
[Unit]
Description=Renew SSH host certificate
After=network-online.target

[Service]
Type=oneshot
Environment=STEPPATH=/root/.step
ExecStart=/usr/bin/step ssh renew --force /etc/ssh/ssh_host_ed25519_key-cert.pub /etc/ssh/ssh_host_ed25519_key
ExecStartPost=/bin/systemctl reload sshd
EOF

• This service runs around boot and waits for the network to be up (After=network-online.target)
• It runs once then stops (Type=oneshot)
• STEPPATH points to root’s saved bootstrap settings (Environment=STEPPATH=/root/.step)
• The service renews the host certificate, then it reloads sshd

2. Create the timer.

We need a timer to trigger the ssh-host-renew.service to run once a day.

Add this to all your SSH servers:

sudo tee /etc/systemd/system/ssh-host-renew.timer > /dev/null << 'EOF'
[Unit]
Description=Daily SSH host certificate renewal

[Timer]
OnCalendar=daily
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target
EOF

• The timer runs once daily at midnight (OnCalendar=daily)
• A random wait time of up to 1 hour is added so all the SSH servers aren’t hitting the CA at the same time (RandomizedDelaySec=1h)
• If the SSH server happens to be off when the timer runs, then it will run when the server is back up (Persistent=true)

3. Enable the timer.

Run this on each SSH server:

sudo systemctl daemon-reload
sudo systemctl enable --now ssh-host-renew.timer

This loads the new files into systemd (daemon-reload) and then enables the timer.

Check that the timer is enabled:

systemctl list-timers ssh-host-renew.timer

Test the renewer manually (rather than waiting):

sudo systemctl start ssh-host-renew.service
journalctl -u ssh-host-renew.service -n 20

We have now set up the timer to renew the SSH host certificate every day. Since the host SSH certificate is valid for 30 days, this means that we have a month to catch an issue if something goes wrong.

RUN THIS ON SSH CLIENTS

1. Install step-cli and bootstrap the CA.

Depending on your operating system the installation may vary. Please consult the installation documentation.

I am using Ubuntu:

sudo apt-get update && sudo apt-get install -y --no-install-recommends curl gpg ca-certificates
sudo install -d -m 0755 /etc/apt/keyrings
sudo curl -fsSL https://packages.smallstep.com/keys/apt/repo-signing-key.gpg -o /etc/apt/keyrings/smallstep.asc
sudo tee /etc/apt/sources.list.d/smallstep.sources > /dev/null << EOF
Types: deb
URIs: https://packages.smallstep.com/stable/debian
Suites: debs
Components: main
Signed-By: /etc/apt/keyrings/smallstep.asc
EOF
sudo apt-get update && sudo apt-get -y install step-cli

Declare your CA Fingerprint:

CA_FINGERPRINT=<FINGERPRINT>

Set up a new client so it can securely talk to the CA (bootstrapping):

step ca bootstrap --ca-url https://<CA_HOSTNAME/IP>:9000 --fingerprint $CA_FINGERPRINT --install

This cross-referenced the root SSL certificate with the fingerprint. If they match then the SSL certificate is downloaded into the system trust store. This allows things like curl and Chrome to trust certs from the CA (Firefox is different).

3. Add the host CA’s public key (/var/lib/docker/volumes/step/_data/certs/ssh_host_ca_key.pub) to the known_hosts file on the SSH client:

echo "@cert-authority <SERVER1_HOSTNAME>,<SERVER1_IP>,<SERVER2_HOSTNAME>,<SERVER2_IP> $(step ssh config --host --roots)" >> ~/.ssh/known_hosts

• The @ symbol indicates a special line that tells SSH that this isn’t a normal entry (like a server name + its key) and to treat it differently.
• The SERVER_HOSTNAME or the SERVER_IP are the addresses that will be used to SSH into each server. For example if we list example.local but not its IP address, and we SSH with its IP address, then we will get the ‘authenticity of host can’t be established’ warning.
• step ssh config — host — roots fetches the CA’s host CA public key.

For example my specific command is as follows:

echo "@cert-authority endeavour-pi-*,jennifer-pi-*,jennifer-nuc-*,192.168.0.*,192.168.15.*,100.*,remote-* $(step ssh config --host --roots)" >> ~/.ssh/known_hosts

If the .ssh folder doesn’t exist yet, create it then run the above command:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

If you need to update this in the future when new SSH servers are added, include the hostnames and IP addresses into the line (don’t run the command again):

vim ~/.ssh/known_hosts

4. Get your user certificate.

Request a user certificate from the CA:

step ssh certificate <IDENTITY> ~/.ssh/id_ecdsa --principal <SERVER_USERNAME> --provisioner <PROVISIONER_NAME>

In my case:

step ssh certificate lumenyx ~/.ssh/id_ecdsa --principal lumenyx --provisioner admin --no-password --insecure

• I added --no-password and --insecure because I didn’t want to add another password. This is for a homelab. Just be aware that anyone who copies ~/.ssh/id_ecdsa can log in until the certificate expires.

INCREASING THE USER CERT EXPIRY LIMIT

Currently we have to create a new user certificate every 16 hours.

We can increase it like so on the CA host:

docker exec -it step-ca step ca provisioner update admin \
  --ssh-user-default-dur 168h \
  --ssh-user-max-dur 168h
docker restart step-ca

• The admin name is ‘step’.
• The password is the CA password.

This new expiry will take effect the next time you run step ssh certificate.

DUCKDNS

1. Create and log into a Duck DNS account — https://www.duckdns.org/.
2. Create your domain.
3. Follow the up instructions by copying and pasting the commands:

4. Done.

This will make your Raspberry Pi update the current public IP address for your domain every 5 minutes. If your public IP address ever changes for some reason, then the domain you created will then point to the current address after 5 minutes.

This is part 1 of my 3 part series.

1. Set up a Private Certificate Authority
2. Set up SSH certificates
3. Set up Authentik so SSH certificates are provisioned when logged into.

Smallstep have created several simple ways to create your own private Certificate Authority.

We will also enable it to support SSH certificates.

We’ll be using their steps for Docker.

GENERAL PROCESS

1. Install step-cli.
2. Run the step-ca container (creates the root and intermediate certificates).
3. Get the root certificate’s fingerprint.
4. Bootstrap each end device to trust the root (plus Firefox separately).
5. On the service’s host, request a certificate from the CA for the hostname clients use to reach the service.
6. Point the service at the certificate.
7. Set up auto-renewal.

INSTALL STEP-CLI

Depending on your operating system the installation may vary. Please consult the installation documentation.

I am using Ubuntu:

sudo apt-get update && sudo apt-get install -y --no-install-recommends curl gpg ca-certificates
sudo install -d -m 0755 /etc/apt/keyrings
sudo curl -fsSL https://packages.smallstep.com/keys/apt/repo-signing-key.gpg -o /etc/apt/keyrings/smallstep.asc
sudo tee /etc/apt/sources.list.d/smallstep.sources > /dev/null << EOF
Types: deb
URIs: https://packages.smallstep.com/stable/debian
Suites: debs
Components: main
Signed-By: /etc/apt/keyrings/smallstep.asc
EOF
sudo apt-get update && sudo apt-get -y install step-cli

CREATE THE CA CONTAINER

Firstly we’ll create a container using the image provided by Smallstep.

It will listen on port 9000.

Run:

docker run -d --name step-ca --restart unless-stopped \
    -v step:/home/step \
    -p 9000:9000 \
    -e "DOCKER_STEPCA_INIT_NAME=Smallstep" \
    -e "DOCKER_STEPCA_INIT_DNS_NAMES=localhost,$(hostname -f),<hostname-clients-use-to-reach-the-ca>,<ipaddr-clients-will-use-to-reach-the-ca>" \
    -e "DOCKER_STEPCA_INIT_REMOTE_MANAGEMENT=true" \
    -e "DOCKER_STEPCA_INIT_SSH=true" \
    smallstep/step-ca:0.30.2

Ensure that you use a container tag that is not ‘latest’ as using the latest tag is bad practice since the container could introduce breaking changes if it’s ever recreated.

I’ll use smallstep/step-ca:0.30.2 instead.

What does this container do?

This container creates a root key (meant to be kept private), a root certificate (can be shared publicly) as well as an intermediate certificate.

The root certificate is what all the devices trust.

However the root private key (currently stored in /var/lib/docker/volumes/step/_data/secrets/) must be kept secure. How you keep it secure is up to you. I’ve seen it recommended that people store it offline onto a Yubikey, and they use the intermediate key to sign everything.

The intermediate certificate is signed by the root, and its private key is what actually signs your service certificates.

If the intermediate key is ever compromised, you can use the root key to sign a new intermediate certificate, and your devices continue trusting the same root.

What does DOCKER_STEPCA_INIT_DNS_NAMES do?

This is the list of hostnames and IP addresses that clients will use to reach the CA.

The CA puts these into its own HTTPS certificate. When a client connects, it checks that the hostname or IP address that it used is actually in the certificate. If it isn’t then the connection is refused by the client.

For example, earlier I tried to connect to the CA using its IP address (rather than the DNS name that I specified) and therefore my connection was rejected.

What does DOCKER_STEPCA_INIT_SSH=true do?

This sets up the CA to also issue SSH certificates as well as HTTPS certificates.

Without this setting, the CA can only issue HTTPS certificates.

FIND THE USERNAME AND PASSWORD FOR THE CA

The logs for this container will display the CA admin username and password:

docker logs step-ca

HAVE YOUR MACHINE TRUST THE CA

We can connect to the Certificate Authority now that it’s up and running. To do this, clients need to know the URL, and the SHA256 fingerprint of the Certificate Authority.

{
  CA_FINGERPRINT=$(docker run --rm -v step:/home/step smallstep/step-ca:0.30.2  step certificate fingerprint certs/root_ca.crt)
  step ca bootstrap --ca-url https://localhost:9000 --fingerprint $CA_FINGERPRINT --install
}

What does this do?

This spins up a temporary container that reads the root certificate’s fingerprint from the step volume (the volume is on the host at /var/lib/docker/volumes/step/_data) then places it into a variable called $CA_FINGERPRINT.

Then it sets up the client so that it can talk to the CA securely by downloading the root certificate (the root cert that needs to be installed on every device in order to trust the CA) and then cross-referencing it with the SHA256 hash. This is called ‘bootstrapping’.

The install flag adds the root certificate to the client’s system trust store, so your programs like curl and browsers will trust any certificate that the CA issues.

Run a health check:

curl https://localhost:9000/health

TRUSTING THE CA ON LINUX CLIENTS

Every client needs the root certificate installed before it will trust certificates issued by the CA.

The process is the same as above, except the client reaches the CA over the network instead of through localhost.

1. On the client install step-cli. Follow the documentation for your OS.

For Debian/Ubuntu:

sudo apt-get update && sudo apt-get install -y --no-install-recommends curl gpg ca-certificates
sudo install -d -m 0755 /etc/apt/keyrings
sudo curl -fsSL https://packages.smallstep.com/keys/apt/repo-signing-key.gpg -o /etc/apt/keyrings/smallstep.asc
sudo tee /etc/apt/sources.list.d/smallstep.sources > /dev/null << EOF
Types: deb
URIs: https://packages.smallstep.com/stable/debian
Suites: debs
Components: main
Signed-By: /etc/apt/keyrings/smallstep.asc
EOF
sudo apt-get update && sudo apt-get -y install step-cli

2. Obtain the root certificate’s fingerprint. This can be shared publicly as the hash doesn’t allow anyone to do anything with your CA.

On the CA HOST:

docker exec step-ca step certificate fingerprint certs/root_ca.crt

3. On the CLIENT, run these commands to download the root certificate, cross-reference with SHA256 fingerprint, and if it passes, install it to the trust store.

CA_FINGERPRINT=<ROOT_CERT_FINGERPRINT>

Ensure that you change the IP address to the correct IP address of the CA:

step ca bootstrap --ca-url https://<CA_IP_ADDRESS>:9000 --fingerprint $CA_FINGERPRINT --install

4. Confirm that it actually works:

curl https://<CA_IP_ADDRESS_OR_DNS_NAME>:9000/health

If it fails it would look like this:

If you ever want to uninstall the root certificate:

step certificate uninstall ~/.step/certs/root_ca.crt

rm -rf ~/.step

TRUSTING THE CA ON WINDOWS CLIENTS

1. On the client install step-cli. Follow the documentation for your OS.

winget install Smallstep.step

2. Run Powershell as an admin and bootstrap the root:

step ca bootstrap --ca-url https://<CA_HOSTNAME_OR_IP_FROM_DNS_NAMES>:9000 --fingerprint <ROOT_CERT_FINGERPRINT> --install

CHANGES FOR FIREFOX

If you use a Chromium-based browser then your connection should say secure. However if you use Firefox then it may still say that it’s not secure:

This is because Firefox ignores the Windows/Linux trusted store and prefers its own.

To fix it we should import the root certificate into Firefox directly:

1. Firefox settings
2. Privacy & Security
3. Advanced Settings
4. Certificates
5. Manage Certificates
6. Authorities tab > Import
7. Choose root_ca.crt ( %USERPROFILE%\.step\certs\root_ca.crt)
8. Tick ‘Trust this CA to identify websites”

ISSUE A CERTIFICATE FOR YOUR SERVICE

This machine will need step-cli installed and bootstrapped to the CA (follow the above steps).

On the machine running the service that needs the certificate, request one from the CA.

Create the certs directory:

mkdir -p ~/certs

Use the hostname that you will type into the browser to reach the service:

step ca certificate <service-hostname> \
~/certs/<container-name>.crt \
~/certs/<container-name>.key \
--san <main-service-hostname> \ 
--san <any-additional-hostnames/ip-addresses>

This command creates a Certificate Signing Request (CSR) and sends it to the CA, which signs it and returns the certificate.

IMPORTANT — Name the certificate the same name as the service’s container. The auto-renew step uses this name to restart the container after each renewal. For example my grafana server’s container name is called “grafana”.

If the names don’t match, the service will keep using the old certificate until it expires.

When it asks ‘What provisioner key do you want to use?’ select ‘admin’ and then enter your admin password.

GIVE THE SERVICE CONTAINER ACCESS TO THE CERTIFICATE

step creates the certificate files so that only your user can read them, however the container needs to be able to read them too.

1. On the machine hosting the container, find out which user the container runs as:

docker exec <container-name> id

Look at the uid at the start of the output. If it’s uid=0(root), the container runs as root and can already read the files, so skip to step 3.

If the uid is any other number, continue to step 2, even if the gid is 0.

For example, Grafana shows uid=472(grafana) gid=0(root). It runs as an ordinary user, so it still needs step 2:

2. Note the gid number. Give that group read-only access to the key and make the certificate readable:

sudo chgrp <gid> ~/certs/<container-name>.key
chmod 640 ~/certs/<container-name>.key
chmod 644 ~/certs/<container-name>.crt

The certificate is public (644) and the key is restricted to those who own it and the container’s group (640).

3. Finally, point your service at the certificate.

We need to update the docker-compose file for our services container (eg Vaultwarden, Grafana, Frigate, etc), not the step-ca container.

Add this line to the docker-compose file for your container to mount the certs/key files into the container read-only:

    volumes:
      - ${HOME}/certs/<.crt_file>.crt:/certs/<.crt_file>.crt:ro
      - ${HOME}/certs/<.key_file>.key:/certs/<.key_file>.key:ro

Then tell the service to use the certificate. Every service has its own HTTPS (or TLS) settings, so check your service’s documentation , and point them at:

• Certificate: /certs/<container-name>.crt
• Key: /certs/<container-name>.key

If you go to the official documentation page, there should be a section for SSL/TLS/HTTPS (example https://docs.frigate.video/configuration/tls)

If you are struggling to find the appropriate environment variables as I was, ask an LLM:

“I’m running <service name> in Docker using the image image:tag, set up with docker compose. I have a TLS certificate and private key mounted into the container at /certs/<container-name>.crt and /certs/<container-name>.key. What do I add to my compose file to make the service serve HTTPS using these files? Please give the exact environment variables (or config file settings, if it doesn’t support environment variables), and link to the official documentation where they’re listed.”

For example, Grafana uses these environment variables, added under the service’s environment:

  GF_SERVER_PROTOCOL: https
  GF_SERVER_CERT_FILE: /certs/grafana.crt
  GF_SERVER_CERT_KEY: /certs/grafana.key

Check if there’s any errors with the config:

docker compose config

Then recreate the container:

docker compose up -d

ENABLE AUTO-RENEW FOR CERTIFICATES

Certificates issued by the CA are intentionally short-lived. This is because if a key is ever stolen then it stops being useful after the certificate expires (24hr by default).

The CA doesn’t renew certificates itself. Each machine holding a certificate is responsible for renewing its own.

Here is the official documentation for more detail.

Create the service on the machine that hosts the service whose certificate you want to auto-renew.

Run this as your normal user (not root):

sudo tee /etc/systemd/system/cert-renewer@.service > /dev/null << EOF
[Unit]
Description=Renew certificate %i
After=network-online.target

[Service]
Type=oneshot
User=$USER
Environment=STEPPATH=$HOME/.step
Environment=CERT=$HOME/certs/%i.crt
Environment=KEY=$HOME/certs/%i.key
ExecCondition=/usr/bin/step certificate needs-renewal \${CERT}
ExecStart=/usr/bin/step ca renew --force \${CERT} \${KEY}
ExecStartPost=-/bin/chmod 644 \${CERT}
ExecStartPost=-/bin/sh -c 'docker inspect -f "{{.State.Running}}" %i 2>/dev/null | grep -qx true && docker restart %i'
EOF

• The first ExecStartPost line keeps the certificate readable by the container after each renewal, since renewing rewrites the certificate file.
• The second ExecStartPost line checks if the container is running, and only restarts it if it’s already up (this is because most services read their certs when they start).

Confirm it looks good:

cat /etc/systemd/system/cert-renewer@.service

Create the timer on the machine that hosts the service whose certificate you want to auto-renew:

sudo tee /etc/systemd/system/cert-renewer@.timer > /dev/null << EOF
[Unit]
Description=Check certificate %i for renewal

[Timer]
OnCalendar=*:0/15
RandomizedDelaySec=60
Persistent=true

[Install]
WantedBy=timers.target
EOF

Confirm it looks good:

cat /etc/systemd/system/cert-renewer@.timer

Now reload systemd:

sudo systemctl daemon-reload

Find the certificate (first you have to copy the certificate name):

basename -s .crt ~/certs/*.crt

Note the certificate name:

Enable the timer:

IMPORTANT — YOU HAVE TO RUN THIS PART EACH TIME YOU MAKE A NEW CERTIFICATE

sudo systemctl enable --now cert-renewer@<cert-name>.timer

In this example this becomes:

sudo systemctl enable --now cert-renewer@grafana.timer

List the active timers that start with cert-renewer:

systemctl list-timers 'cert-renewer*'

You can close out of it by pressing ‘q’.

Confirm that the service itself works:

sudo systemctl start cert-renewer@grafana.service
journalctl -u cert-renewer@grafana.service -n 20

The logs may say that it was skipped, this is fine since it’s not time to renew the certificate.

However if you see a ‘file not found’ error instead, then that may be due to a misconfiguration.

CONCLUSION

You now have a private Certificate Authority running in Docker, with its root certificate trusted by your clients, ready to issue HTTPS and SSH certificates to your home lab.

From here, the next step is setting up SSH certificates so that you don’t have to copy keys into authorized_keys any more.

Unfortunately there isn’t a simple way to identify what Distribution Lists a user is a part of in Microsoft Exchange.

Thankfully we can use this Powershell script.

Disclaimer: This is vibe-coded. This is just for my internal notes so I can copy and use it whenever I need.

FINDING A SINGLE USER’S DISTRIBUTION LISTS

Connect to Exchange:

Connect-ExchangeOnline

Declare the user’s email address:

$userEmail = "user1@company.com"

Run the script. This is in one line so we can paste it without worrying about line-break issues:

$dn = (Get-Recipient -Identity $userEmail -ErrorAction Stop).DistinguishedName -replace "'","''"; $results = Get-DistributionGroup -ResultSize Unlimited -Filter "Members -eq '$dn'" | Select-Object @{n='DistributionList';e={$_.DisplayName}}, Alias, @{n='PrimarySMTP';e={$_.PrimarySmtpAddress}}; $results | Format-Table -AutoSize; Write-Host "Found $(@($results).Count) distribution list(s)." -ForegroundColor Green

FINDING MULTIPLE USERS DISTRIBUTION LISTS

Connect to Exchange:

Connect-ExchangeOnline

Declare the email addresses you want to query:

$userEmails = @("user1@company.com", "user2@company.com")

Run the script:

$results = foreach ($u in $userEmails) { try { $dn = (Get-Recipient -Identity $u -ErrorAction Stop).DistinguishedName -replace "'","''"; Get-DistributionGroup -ResultSize Unlimited -Filter "Members -eq '$dn'" | Select-Object @{n='User';e={$u}}, @{n='DistributionList';e={$_.DisplayName}}, Alias, @{n='PrimarySMTP';e={$_.PrimarySmtpAddress}} } catch { Write-Warning "Could not find recipient $u" } }; $results | Sort-Object User | Format-Table -AutoSize; Write-Host "Found $(@($results).Count) membership(s)." -ForegroundColor Green

You would like to minimize the cost of storage by placing infrequently accessed files in lower-priced storage tiers. You also plan to explore different protection mechanisms that Azure Storage offers, including network access, authentication, authorization, and replication.

Finally, you want to determine to what extent Azure Files is suitable for hosting your on-premises file shares.

TASK 1: CREATE AND CONFIGURE A STORAGE ACCOUNT

Within the Azure Portal go to Storage accounts > Blob Storage > Create:

We want to create it with the following settings (you can change the region if you want):

• Resource group: az104-rg7
• Storage account name: Choose your own
• Primary service: Azure Blob Storage or Azure Data Lake Storage
• Performance: Standard
• Redundancy: Geo-redundant storage (GRS)
• Enable ‘Make read access to data available in the event of regional unavailability’.

Accept the defaults for the Advanced tab.

Within the Networking tab, disable public access:

Regarding Data protection, accept the defaults but take note of the 7 day soft delete policy. Knowing about this could come in handy further in your career:

Accept the defaults for the Security, Encryption and Tags tab.

Review and create the storage account

WHITELIST OUR PUBLIC IP ADDRESS

Once the Storage account is created, we want to whitelist our public IP address.

Once your Storage account is deployed, click on Go to resource:

Click on Networking and click on Manage which is underneath public network access:

We want to Enable public access and select Enabled from selected networks.

Then we can add our public IPv4 address:

ENABLE LIFECYCLE MANAGEMENT

Now we’ll enable lifecycle management so that any files that haven’t been modified in 30 days get moved to another tier.

What is lifecycle management?

Lifecycle management automatically moves data between tiers based on the rules you define, such as how long it’s been since the data was accessed.

The first thing to note is that there are two main costs:

• There’s the fixed cost, which is the amount that you have to pay Azure for them just to hold your data (regardless of if you access it or not).
• The access cost, which is applied every time you access the data.

Azure has numerous tiers for storage. There’s tiers are Hot, Cool, Cold and Archive.

Different tiers are used for different purposes. The Hot tier is used for frequently accessed data. It has the highest fixed cost (the cost just to hold it) but a lower access/transaction cost.

Compared to the Cold tier which has a lower fixed cost but is pricier than Hot and Cool each time it’s accessed.

Below is a table provided by Microsoft with more information:

Based on this knowledge, which tier should website images be stored in? They should be stored in the Hot tier.

Which tier should website logs be stored in? Depending on the types of logs they could be anywhere between Cool and Archive.

Let’s set up a lifecycle management rule.

Click on Lifecycle management > Add a rule:

Configure the rule name to be MoveToCool and configure the same settings as the screenshots below:

TASK 2: CREATE AND CONFIGURE SECURE BLOB STORAGE

Now we’re going to set up storage that becomes immutable for a time limit of 180 days.

Within the Storage account go to Containers > Add container:

• Name: data
• Anonymous access level: Private (no anonymous access)

What is anonymous access?

In this context it’s the ability to view files and photos without needing an account.

Now that the ‘data’ container has been created, click on the ellipsis (…) and select ‘Access policy’:

Now to add the policy:

• Policy type: Time-based retention
• Set retention period for: 180

What are we actually doing? What is ‘Time-based retention’?

We’re locking every blob written to this container so that it can’t be modified or deleted for 180 days, regardless of who it is.

This can be used for compliance/legal reasons but can also be used to protect against ransomware/accidental deletion.

What about the other option? What is ‘Legal hold’?

Legal hold is when we want to apply the same lock as time-based retention indefinitely.

The lock can also be removed manually by someone with permission like an administrator.

It’s used for when data needs to be preserved for an investigation or an audit that has no predetermined end date.

MANAGE BLOB UPLOADS

Give yourself the ability to access the storage account using its access key (as opposed to using Entra).

Within the storage account go to Configuration > Allow storage account key access > Enabled

Access Control (IAM) > Add > Add role assignment:

Add the Storage Blob Data Contributor role:

Also assign the Storage File Data Privileged Contributor Role as well:

Go back to the data container we created earlier and click on upload:

Add a random file:

Confirm that you have a new folder called ‘securitytest’ and that your file was uploaded:

Now we’re going to check out our photo. If it comes back with an error then that means that our security settings are correctly set up:

The error shown is because we have set the setting to be Private (no anonymous access).

(See Troubleshooting Azure Storage Account Permissions)

Here are the relevant settings (don’t change them yet):

CONFIGURE LIMITED ACCESS TO THE BLOB STORAGE

We’re going to generate a SAS URL to view the file. This file can only be viewed via this URL with the settings that we set.

Follow the screenshot below:

Confirm that it works:

TASK 3: CREATE AND CONFIGURE SECURE AZURE FILE STORAGE

In this phase we’ll create and configure Azure File shares, then use the Storage Browser to manage the file share.

CREATE THE FILE SHARE AND UPLOAD A FILE

Storage accounts > Blob Storage > Classic file shares > + Classic file share

• Name: share1
• Access tier: Transaction optimized
• Disable backup for lab simplicity

EXPLORE STORAGE BROWSER AND UPLOAD A FILE

RESTRICT ACCESS TO THE STORAGE ACCOUNT

In this phase we’ll set up a VNet and de-list our IP address so we can test if unauthorised IP addresses will be denied.

Now we’re going to set up a service endpoint.

What is a Service Endpoint?

A Service Endpoint tags your traffic from your VNet’s subnet with that subnet’s source info as it leaves toward an Azure PaaS service (like a storage account), so the service can allow or deny this access.

The traffic also routes through Microsoft’s backbone network instead of the public internet.

The Service Endpoint attaches a tag to traffic leaving 10.0.0.0/24 and sends it to Azure Storage (Microsoft.Storage) over Microsoft’s backbone network instead of the public internet.

This improves security as it goes over the Microsoft backbone network, therefore removing the need for the traffic to go over the public internet at all.

It also improves speed as using the Microsoft backbone network utilises a more optimised route than a public internet path.

Now we’re going to remove our whitelisted IP address and replace it with the VNet we just created.

Add it to our whitelisted networks:

Remove our public IP:

Confirm that your access to view the file share has been revoked:

CLEANUP YOUR RESOURCES

We can remove all our resources by deleting our Resource Group.

Open Cloud Shell in Powershell and run this command:

Remove-AzResourceGroup az104-rg7 -Force

TROUBLESHOOTING ISSUES WITH ACCESSING THE STORAGE ACCOUNT ITSELF

COMMON CAUSE 1: YOUR NETWORK HASN’T BEEN WHITELISTED

When you try to access the Container (Storage account > Data storage > Containers > Your Container) it gives you an error 403:

To check and confirm if your IP address is whitelisted go to:

Storage account > Security + Networking > Networking > Public network access > Manage

For this example we could configure a Private endpoint to access the storage account, however we’ll instead change the setting to ‘Enable’ and add our public IP address:

COMMON CAUSE 2: INSUFFICIENT ROLE PRIVILEGES

This error message below is due to insufficient privileges.

We can check what roles the user has and assign them as necessary:

EMAIL="UserEmailAddress@domain.com"

az role assignment list --assignee $EMAIL --all --output table

We’ll have to add the necessary roles for what access is needed.

Examples of roles to add:

• Reader
• Storage Blob Data Contributor
• Storage Blob Data Owner

TROUBLESHOOTING ISSUES WITH ACCESSING FILES IN STORAGE ACCOUNTS

COMMON CAUSE 1: BLOB ANONYMOUS ACCESS IS DISABLED

The issue may be that Blob anonymous access is disabled. Whether it should or shouldn’t be disabled depends on the organisation, however this is something to check.

Check:

Storage Account > Settings > Configuration > Allow Blob anonymous access

COMMON CAUSE 2: THE ACCESS LEVEL ON THE CONTAINER IS SET TO PRIVATE

Go to:

Storage account > Storage browser > Blob containers > Change access level

Changing the setting as a test has confirmed that this was the issue:

COMMON CAUSE 3: THE STORAGE ACCOUNT KEY ACCESS IS DISABLED

When “Allow storage account key access” is disabled, anything that relies on the storage account keys stops working.

Roles like the Storage Account Contributor role or even the Owner role can retrieve the account keys and use them to reach the data, however if the storage account key access is disabled, then anyone using this role will be denied.

Use this quick guide to save yourself some headache.

Open CloudShell:

Switch to Bash and define the email address you want:

EMAIL="EmailAddress@domain.com"

Use this command:

az role assignment list --assignee $EMAIL --all --output table

If you want to include multiple people then you can use this script:

for user in "EmailAddress01@domain.com" "EmailAddres02@domain.com"; do
  echo "=== $user ==="
  az role assignment list --assignee "$user" --all --output table
done

“Fail2Ban v1.1.0 reads log file that contains password failure report and bans the corresponding IP addresses using firewall rules.”

Here’s how to configure it onto your Linux system.

Install it:

sudo apt install fail2ban -y

Start and enable fail2ban:

sudo systemctl enable --now fail2ban

Go to the config directory:

cd /etc/fail2ban

The main configuration file is called fail2ban.conf.

We can copy that to become fail2ban.local if we want to make any changes:

cp fail2ban.conf fail2ban.local

The .local file will take precedence over the .conf file.

The .conf file comes installed with the rest of the package but can be overwritten during upgrades. This is why we copy it to .local which will take precedence over .conf.

We can also do this with jail.conf:

cp jail.conf jail.local

APPLY CONFIGURATIONS

Now to edit the line with ignoreip to allow our own public IP. This is so we don’t accidentally ban ourselves:

sudo vim jail.local

Find this line, uncomment it and add your public IP address at the end:

ignoreip = 127.0.0.1/8 ::1 < YOUR-PUBLIC-IP-ADDRESS >

NOTE: This is only if you have a static public IP address.

Now we can set the default values all of the jails.

These are the values within the file that we may want to change:

• bantime — How long is an IP address banned for? If you want them permanently banned you would specify -1.
• findtime — The time window fail2ban looks back over to count failed login attempts before issuing a ban.
• maxretry — How many failed login attempts before an IP address gets banned.

Now to configure the SSH Daemon settings. We want to enable the SSHD jail:

Within [sshd] we want to add this line:

enabled = true

If you use an ssh port that’s not 22, you can update port to be the correct SSH port.

If we want to, we can set up maxretry, bantime, and findtime specifically for each jail. Configuring this per-jail will take precedence over the settings we configured earlier:

Restart fail2ban so it picks up on the changes:

sudo systemctl restart fail2ban

VIEWING FAIL2BAN

We can use this command to view our options with Fail2Ban:

fail2ban-client