DEV Community: Shoban Chiddarth

AWS Terraform infrastructure for a FastAPI+PostgreSQL backend

Shoban Chiddarth — Mon, 23 Mar 2026 14:47:31 +0000

Introduction

This blog post showcases the AWS infrastructure written in Terraform for the backend of alumni-connect, a MVP of a college project written in FastAPI with a PostgreSQL database.

The terraform repo: https://github.com/ShobanChiddarth/alumni-connect-terraform
The backend repo: https://github.com/ShobanChiddarth/alumni-connect-backend

Architecture

VPC Design

Since this is an MVP, I went with the absolute minimal for everything. 1 VPC exists on ap-south-1. It has an internet gateway. Frontend is hosted in netlify, so API requests as well as management traffic (SSH) will enter through the internet gateway.

Subnet Design

There are 4 subnets in total.

A public subnet to handle management traffic (ap-south-1a)
2 private subnets for backend and database EC2 instances (ap-south-1a)
Another public subnet to satisfy AWS's hard requirement of multi AZ for load balancers (ap-south-1b)

The management subnet:

Contains the bastion EC2
Contains a NAT gateway for EC2 instances in the private subnet to reach the internet

Load Balancer

The backend EC2 has no public IP and sits in a private subnet. Its security group only accepts port 8000 from the ALB security group - there is no direct path from the internet to the backend. The ALB is the only entry point.

listens on port 80 for HTTP traffic from the public internet
spans across ap-south-1a (management subnet) and ap-south-1b (empty subnet) - AWS requires an internet-facing ALB to span at least 2 AZs
forwards the traffic from the internet to port 8000 in the backend EC2

Security Groups Design

SSH traffic from the internet is allowed only to the bastion EC2
SSH traffic to the backend and database EC2s are allowed only from the bastion EC2
HTTP traffic from the internet is allowed only to the load balancer
HTTP traffic to the backend is allowed only from the load balancer
Database traffic (port 5432) to the database EC2 is allowed only from the backend EC2

SSH Keys

Bastion EC2's SSH private key stays on the local computer of the person deploying this
Other EC2s SSH private key stays in the bastion

EC2 instances

Backend EC2 is set to pull and run docker image shobanchiddarth/alumni-connect-backend:0.0.2
Database EC2 is set to pull and run docker image postgres:16

NAT Gateway Cost Problem

I wrote a LinkedIn post about this. Click here to view it.

If you are not able to see it, here are the contents of the post:

I recently faced a problem with making EC2 instances communicate with the internet while deploying a FastAPI+Postgres backend architecture on AWS using Terraform. NAT Gateways exist to solve this - a NAT gateway can be placed in a public subnet and traffic can be routed through it.

But NAT Gateways are costly. ~$0.045/hr just to exist, plus data transfer charges.

The solution I used: keep the NAT gateway in the Terraform code, but destroy it immediately after deployment. Private instances lose internet access after packages are updated, Docker images are pulled, and containers are running.

terraform destroy -target=aws_nat_gateway.alumni-nat-gw -target=aws_eip.nat-gateway-elastic-ip

I also tried a NAT instance - an EC2 that acts as a router - but ran into configuration issues getting it to actually forward traffic. Ended up not going down that path for this project.

This temporary NAT gateway approach is good enough for a college project MVP with almost no users that gets destroyed in a few hours anyway.

Has anyone dealt with this in production? Is there a cleaner pattern for private subnet internet access beyond NAT gateway or NAT instance?

#Terraform #AWS #VPC #CloudComputing #IaC #CloudCost

Steps to Deploy

Clone the repo

git clone https://github.com/ShobanChiddarth/alumni-connect-terraform
cd alumni-connect-terraform/infrastructure

Set AWS credentials

export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

Set the database password
```
export TF_VAR_db_password="..."
```
Deploy
```
terraform init
terraform apply
```

Destroy the NAT gateway after apply

terraform destroy \
 -target=aws_nat_gateway.alumni-nat-gw \
 -target=aws_eip.nat-gateway-elastic-ip

To tear down everything:

terraform destroy

Proof of Deployment

These are screenshots I took when it was live. I then destroyed the whole infrastructure.

I archived the API landing URL (first image) in Wayback Machine. Here is the link: https://web.archive.org/web/20260322130840/http://alumni-alb-backend-83642402.ap-south-1.elb.amazonaws.com/

Conclusion

This is the full Terraform infrastructure for the alumni-connect backend.

IAM Development Lab in Keycloak

Shoban Chiddarth — Fri, 20 Mar 2026 17:17:13 +0000

Introduction

This is the ultimate IAM development and employee lifecycle management lab I am doing where I will be making use of the skills I learnt from the TATA virtual internship via Forage: Cybersecurity Analyst - IAM Developer to develop and implement an IAM solution for a fictional organization.

I chose Keycloak for this lab instead of SailPoint with Oracle Identity Manager because Keycloak is fully open source. This is a standalone lab independent of OpenLDAP.

The internship covered

IAM fundamentals
Digital identity
Authentication
Authorization
SSO
least privilege principle And then walked through designing and planning a full IAM implementation for a fictional enterprise called TechCorp (but the fictional org we will be representing is called Acme). The proposed solution used
SailPoint for automated user lifecycle management and
Oracle Identity Manager for RBAC with a four-phase implementation plan covering deployment, testing, training, and ongoing monitoring.

This lab takes those same requirements and implements them end-to-end:

A structured org with departments and roles
RBAC enforced at the role level
Full user lifecycle management from provisioning to offboarding
MFA
SSO via OIDC
Email-based verification flows
Brute force protection
Audit logging All running on-premises in VirtualBox with no external dependencies. ## Pre-Requisites

Build Log

Keycloak Server Initialization

I cloned a debian server VM, put it in the current VirtualBox host only network I have, assigned a static IP (192.168.57.8), Then I edited its hostname, and mapped DNS record keycloak.acme.internal -> 192.168.57.8 in Pi-Hole.

debian@keycloak:~$ sudo ifconfig enp0s3
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.57.8  netmask 255.255.255.0  broadcast 192.168.57.255
        inet6 fe80::43b5:ca52:a96d:134a  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:8a:4a:29  txqueuelen 1000  (Ethernet)
        RX packets 28569  bytes 3772704 (3.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28550  bytes 2712767 (2.5 MiB)
        TX errors 0  dropped 2 overruns 0  carrier 0  collisions 0

debian@keycloak:~$ nslookup keycloak.acme.internal
Server:     192.168.57.3
Address:    192.168.57.3#53

Name:   keycloak.acme.internal
Address: 192.168.57.8

debian@keycloak:~$

Then I installed java on it because Keycloak requires it.

sudo apt install default-jre -y

Java version 21 btw

debian@keycloak:~$ java --version
openjdk 21.0.10 2026-01-20
OpenJDK Runtime Environment (build 21.0.10+7-Debian-1deb13u1)
OpenJDK 64-Bit Server VM (build 21.0.10+7-Debian-1deb13u1, mixed mode, sharing)

Then I downloaded Keycloak from GitHub, extracted it and put it in /opt

debian@keycloak:~/Downloads$ ls
keycloak-26.5.6.tar.gz
debian@keycloak:~/Downloads$ tar -xzf keycloak-26.5.6.tar.gz 
debian@keycloak:~/Downloads$ ls
keycloak-26.5.6  keycloak-26.5.6.tar.gz
debian@keycloak:~/Downloads$ sudo mv keycloak-26.5.6 /opt/keycloak
debian@keycloak:~/Downloads$ cd /opt
debian@keycloak:/opt$ ls
keycloak
debian@keycloak:/opt$

And created a new user and set appropriate permissions.

sudo useradd -r -s /sbin/nologin keycloak
sudo chown -R keycloak:keycloak /opt/keycloak

Local CA certificates for Keycloak

I did the usual, created certs for keycloak.acme.internal and moved them to the Keycloak server and pointed Keycloak to it.

debian@keycloak:~/acme-certs$ ls
keycloak.acme.internal-key.pem  keycloak.acme.internal.pem
debian@keycloak:~/acme-certs$ sudo mkdir -p /opt/keycloak/conf/certs
debian@keycloak:~/acme-certs$ sudo cp keycloak.acme.internal.pem /opt/keycloak/conf/certs/keycloak.crt
debian@keycloak:~/acme-certs$ sudo cp keycloak.acme.internal-key.pem /opt/keycloak/conf/certs/keycloak.key
debian@keycloak:~/acme-certs$ sudo chown -R keycloak:keycloak /opt/keycloak/conf/certs
debian@keycloak:~/acme-certs$ sudo chmod 640 /opt/keycloak/conf/certs/keycloak.key
debian@keycloak:~/acme-certs$ sudo nano /opt/keycloak/conf/keycloak.conf 
debian@keycloak:~/acme-certs$ cat /opt/keycloak/conf/
cache-ispn.xml  certs/          keycloak.conf   README.md       truststores/    
debian@keycloak:~/acme-certs$ cat /opt/keycloak/conf/keycloak.conf | head -5
hostname=keycloak.acme.internal
https-certificate-file=/opt/keycloak/conf/certs/keycloak.crt
https-certificate-key-file=/opt/keycloak/conf/certs/keycloak.key
http-enabled=false

debian@keycloak:~/acme-certs$

Keycloak initial build

sudo -u keycloak KEYCLOAK_ADMIN=admin KEYCLOAK_ADMIN_PASSWORD=admin123 /opt/keycloak/bin/kc.sh build

Output:

debian@keycloak:~/acme-certs$ sudo -u keycloak KEYCLOAK_ADMIN=admin KEYCLOAK_ADMIN_PASSWORD=password /opt/keycloak/bin/kc.sh build
WARNING: Usage of the default value for the db option in the production profile is deprecated. Please explicitly set the db instead.
INFO: The following run time options were found, but will be ignored during build time: kc.https-certificate-key-file, kc.http-enabled, kc.hostname, kc.https-certificate-file

Updating the configuration and installing your custom providers, if any. Please wait.
2026-03-19 20:00:27,827 INFO  [io.quarkus.deployment.QuarkusAugmentor] (main) Quarkus augmentation completed in 10529ms
Server configuration updated and persisted. Run the following command to review the configuration:

    kc.sh show-config

debian@keycloak:~/acme-certs$ /opt/keycloak/bin/kc.sh show-config
Current Mode: production
Current Configuration:
    kc.log-level-org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup =  null (Derived)
    kc.log-level-io.quarkus.config =  null (Derived)
    kc.hostname =  keycloak.acme.internal (keycloak.conf)
    kc.log-console-output =  default (classpath application.properties)
    kc.log-level-io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor =  null (Derived)
    kc.log-level-liquibase.database.core.PostgresDatabase =  null (Derived)
    kc.optimized =  true (Persisted)
    kc.version =  26.5.6 (SysPropConfigSource)
    kc.log-level-io.smallrye.openapi.runtime.scanner.dataobject =  null (Derived)
    kc.https-certificate-file =  /opt/keycloak/conf/certs/keycloak.crt (keycloak.conf)
    kc.log-level-org.jboss.resteasy.resteasy_jaxrs.i18n =  null (Derived)
    kc.log-level-io.quarkus.arc.processor.BeanArchives =  null (Derived)
    kc.log-level-io.quarkus.deployment.steps.ReflectiveHierarchyStep =  null (Derived)
    kc.http-enabled =  false (keycloak.conf)
    kc.log-level-org.hibernate.SQL_SLOW =  null (Derived)
    kc.https-certificate-key-file =  /opt/keycloak/conf/certs/keycloak.key (keycloak.conf)
    kc.log-level-io.quarkus.arc.processor.IndexClassLookupUtils =  null (Derived)
    kc.log-file =  /opt/keycloak/bin/../data/log/keycloak.log (classpath application.properties)
    kc.log-level-org.hibernate.engine.jdbc.spi.SqlExceptionHelper =  null (Derived)
debian@keycloak:~/acme-certs$

Keycloak daemon build (systemd)

I created a file /etc/systemd/system/keycloak.service with contents

[Unit]
Description=Keycloak Identity and Access Management
After=network.target

[Service]
User=keycloak
Group=keycloak
Environment=KEYCLOAK_ADMIN=admin
Environment=KEYCLOAK_ADMIN_PASSWORD=admin123
ExecStart=/opt/keycloak/bin/kc.sh start
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

And enabled the service

debian@keycloak:~/acme-certs$ sudo systemctl daemon-reload
debian@keycloak:~/acme-certs$ sudo systemctl enable --now keycloak
Created symlink '/etc/systemd/system/multi-user.target.wants/keycloak.service' → '/etc/systemd/system/keycloak.service'.
debian@keycloak:~/acme-certs$ sudo systemctl status keycloak
● keycloak.service - Keycloak Identity and Access Management
     Loaded: loaded (/etc/systemd/system/keycloak.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-03-19 20:05:40 IST; 6s ago
 Invocation: cde0a8f017a24bac8dd23934aa7a5bf2
   Main PID: 3250 (kc.sh)
      Tasks: 29 (limit: 2301)
     Memory: 269.9M (peak: 270.2M)
        CPU: 6.151s
     CGroup: /system.slice/keycloak.service
             ├─3250 /bin/sh /opt/keycloak/bin/kc.sh start
             └─3322 java -Djava.util.concurrent.ForkJoinPool.common.threadFactory=io.quarkus.bootstrap.forkjoin.QuarkusForkJoinW>

Mar 19 20:05:40 keycloak.acme.internal systemd[1]: Started keycloak.service - Keycloak Identity and Access Management.
Mar 19 20:05:46 keycloak.acme.internal kc.sh[3322]: 2026-03-19 20:05:46,328 INFO  [org.hibernate.orm.jdbc.batch] (JPA Startup Th>
debian@keycloak:~/acme-certs$

Keycloak admin dashboard

I visited https://keycloak.acme.internal:8443 from where the rootCA.pem was trusted in the OS as well as browser certificate store.

Then signed in.

And then created a permanent admin account as it says. I created a new user with username administrator, set a password, and then assigned admin role to it. Then logged in with that user and deleted the temporary admin user.

Then I created a realm for our fictional org - acme - with display name "Acme Corp", user self-registration disabled (admin-provisioned org), and email verification enabled.

Mailpit initial setup

Since this is a local lab with no real mail infrastructure, I used Mailpit - a lightweight fake SMTP server that catches all outbound emails and displays them in a web UI instead of actually delivering them. This lets me test Keycloak's email flows (verification, password reset, OTP) without setting up a real mail server or domain. I ran it on the same VM as Keycloak since it's a single binary with minimal resource usage.

I installed mailpit from GitHub, on the same VM as Keycloak.

wget https://github.com/axllent/mailpit/releases/download/v1.29.3/mailpit-linux-amd64.tar.gz
mkdir mailpit
tar -xzf mailpit-linux-amd64.tar.gz -C mailpit
cd mailpit
sudo mv mailpit /usr/local/bin/
sudo chmod +x /usr/local/bin/mailpit

And then verified it

$ mailpit version
mailpit v1.29.3 compiled with go1.26.1 on linux/amd64
Error checking for latest release: failed to fetch releases: received status code 403

And I created a new user for it

sudo useradd -r -s /sbin/nologin mailpit

Mailpit daemon build (systemd)

I put the following contents on /etc/systemd/system/mailpit.service (copied the previously generated keys to /etc/mailpit/certs and changed ownership of that folder to mailpit)

# /etc/systemd/system/mailpit.service
[Unit]
Description=Mailpit SMTP and Web UI
After=network.target

[Service]
User=mailpit
Group=mailpit
ExecStart=/usr/local/bin/mailpit --smtp 0.0.0.0:1025 --listen 0.0.0.0:8025 --ui-tls-cert /etc/mailpit/certs/keycloak.acme.internal.pem --ui-tls-key /etc/mailpit/certs/keycloak.acme.internal-key.pem
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

And ran

sudo systemctl daemon-reload
sudo systemctl enable --now mailpit
sudo systemctl status mailpit

It works

debian@keycloak:~/Downloads/mailpit$ sudo systemctl daemon-reload
sudo systemctl enable --now mailpit
sudo systemctl status mailpit
Created symlink '/etc/systemd/system/multi-user.target.wants/mailpit.service' → '/etc/systemd/system/mailpit.service'.
● mailpit.service - Mailpit SMTP and Web UI
     Loaded: loaded (/etc/systemd/system/mailpit.service; enabled; preset: enab>
     Active: active (running) since Fri 2026-03-20 15:37:36 IST; 67ms ago
 Invocation: 1046374b8fb24c4f92c8a6fe9683cb5f
   Main PID: 2010 (mailpit)
      Tasks: 3 (limit: 2301)
     Memory: 8.7M (peak: 8.7M)
        CPU: 13ms
     CGroup: /system.slice/mailpit.service
             └─2010 /usr/local/bin/mailpit --smtp 0.0.0.0:1025 --listen 0.0.0.0>

Mar 20 15:37:36 keycloak.acme.internal systemd[1]: Started mailpit.service - Ma>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
Mar 20 15:37:36 keycloak.acme.internal mailpit[2010]: time="2026/03/20 15:37:36>
debian@keycloak:~/Downloads/mailpit$

Keycloak to use Mailpit for email

After I created the ACME Corp realm on Keycloak, I went to Realm Settings, email, entered these values to make use of Mailpit as email service.

Then I visited Mailpit dashboard at https://keycloak.acme.internal:8025/

It works.

Password Policy in Keycloak

I went to Authentication -> Password Policy -> Password Policies and set the password requirements to have

Minimum 10 characters
Minimum 1 Uppercase
Minimum 1 Lowercase
Minimum 1 Digit
Minimum 1 Special Character
Password history: 3 (prevents reuse of last 3 passwords)

I also configured brute force detection under Realm Settings -> Security Defenses -> Brute force detection:

Brute Force Mode: Lockout permanently after temporary lockout
Max login failures: 5
Maximum temporary lockouts: 1
Strategy to increase wait time: Multiple
Wait increment: 1 minute
Max wait: 15 minutes
Failure reset time: 12 hours

After 5 failed login attempts the account locks out temporarily. If login failures continue through the temporary lockout, the account gets permanently locked and requires an admin to manually re-enable it. This will be demonstrated later in the user lifecycle section using Burp Suite to capture the login request and a Python script to simulate a brute force attack with a wordlist.

Organization Structure

I created the above organization structure in Keycloak - four groups for departments, three realm roles (employee, manager, it-admin), and seven users provisioned and assigned accordingly.

All users:

Group Engineering:

Group Finance:

Group HR:

.png)

Group IT:

Role employee:

Role manager:

Role IT Admin:

Enforcing MFA via TOTP (Google Authenticator)

I set up password based logins for users (Something You Know). Now I will set up Google Authenticator based 2FA (Something You Have). For this lab, I will be using gauth.apps.gbraad.nl, a browser based Google Authenticator app implementation, on the host machine, as my Google Authenticator client.

I duplicated the default browser authentication flow in Authentication -> Flows, named it acme browser, and set the Browser - Conditional OTP step from Conditional to Required. Then under Authentication -> Bindings, I set the Browser flow to acme browser. This forces TOTP on every login for all users in the acme realm.

I also enabled the following required actions under Authentication -> Required actions:

Update Password
Verify Email
Configure OTP

These are applied to all users, so on first login every user is forced to change their temporary password, verify their email via Mailpit, and set up TOTP before they can access anything.

jsmith is forced to setup Google Authenticator login in next successful login:

jsmith added key to Google Authenticator

jsmith enters the OTP value and logs in successfully. Every other account did the same.

OIDC Client and SSO Demo

To demonstrate SSO, I registered a client in the acme realm pointing to the official Keycloak demo app hosted at https://www.keycloak.org/app/. Since it's a static page that runs entirely in the browser, it talks directly to my local Keycloak instance - no server-side component needed.

Client settings:

Client type: OpenID Connect
Client authentication: Off (public client)
Valid redirect URIs: https://www.keycloak.org/app/*
Valid post logout redirect URIs: https://www.keycloak.org/app/*
Web origins: https://www.keycloak.org

On the demo app, I pointed it at my Keycloak instance by entering the server URL, realm, and client ID.

Clicking Sign In redirected to the Keycloak login page, went through the full authentication flow - password then TOTP - and landed back on the demo app showing jsmith's authenticated session with the decoded token.

Employee lifecycle management

To demonstrate the full employee lifecycle, I walked through four real-world IAM events using mclark from the HR department.

1. mclark gets promoted to HR manager

mclark was promoted from HR employee to HR manager. In Keycloak, this meant removing the employee role and assigning manager under the user's Role Mappings tab.

Before:

After:

2. mclark takes a vacation (account disabled)

mclark went on an extended leave of absence. Rather than deleting the account, it was disabled - access is immediately revoked but the account and its data remain intact for when the employee returns.

3. mclark returns (account enabled)

mclark returned from leave. The account was re-enabled, restoring access with all roles and group memberships unchanged.

4. mclark quits (account deleted)

mclark resigned. The account was permanently deleted from the realm.

Confirmation:

mclark is no more:

Brute Force Protection

Now I am going to do a brute force attack on jsmith's account. I am going to manually type in some random password values and hit enter multiple times to see what happens.

As you can see from the admin dashboard, jsmith is now temporarily locked.

Event log

Keycloak captures two categories of events per realm. Login events record every authentication-related action - successful logins, failed attempts, logouts, and token operations. Admin events record every administrative action performed on the realm - user creation, role assignments, deletions, client configuration changes, and so on. Both are visible under Events in the admin console.

Login Events

Here is a snippet of lwilson signin related events

Admin Events

Here is a snippet of admin events related to jsmith getting promoted

Conclusion

The internship asked for a designed IAM solution and an implementation plan. This lab is that plan executed.

Every requirement from the Tata Forage simulation is covered here in a working deployment:

Keycloak handles identity and access management for Acme Corp the same way SailPoint and Oracle Identity Manager would handle it for TechCorp.
RBAC is enforced through realm roles mapped to job functions.
User provisioning and de-provisioning follow the same lifecycle model - onboarding with required actions, role changes on promotion, account suspension on leave, and full deletion on resignation.
MFA via TOTP enforces the "something you know + something you have" authentication standard.
SSO via OIDC demonstrates seamless access across applications from a single authenticated session.
Mailpit handles all email flows locally.
Brute force protection is configured and verified.
Admin and login events are captured in the audit log.

The entire stack - Keycloak, Mailpit, TLS via a local CA, DNS via Pi-hole, and network routing via pfSense - runs self-contained in VirtualBox, making it fully reproducible as a home lab without any cloud dependency or paid tooling.

Integrating a local mail server into my LDAP lab

Shoban Chiddarth — Thu, 19 Mar 2026 07:38:19 +0000

GitHub Repo: @ShobanChiddarth/postfix-dovecot-mailserver-in-openldap-lab

Introduction

This is the second stage of my OpenLDAP home lab. I set up a mail server to work with existing LDAP configuration.

Pre-Requisites

Setup Process

Mail Server Install

In the existing setup, I cloned another debian server VM, gave it static IP 192.168.57.7, set its hostname to mail-server.acme.internal and then added the DNS record in Pi-hole. Then I went ahead and installed the required packages for postfix and dovecot to work with LDAP.

sudo apt install -y postfix postfix-ldap dovecot-core dovecot-imapd dovecot-ldap dovecot-lmtpd

Then I chose "Internet Site" in the postfix install prompt asking about which type of mail server to install and set the domain to acme.internal.

Postfix Config

I edited /etc/postfix/main.cf to have this configuration:

myhostname = mail-server.acme.internal
mydomain = acme.internal
mydestination = $myhostname, $mydomain, localhost
mynetworks = 192.168.57.0/24 127.0.0.0/8
inet_interfaces = all
mailbox_transport = lmtp:unix:private/dovecot-lmtp
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
local_recipient_maps = ldap:/etc/postfix/ldap-recipients.cf

mailbox_transport hands mail delivery off to Dovecot via LMTP. The smtpd_sasl_* settings let Postfix use Dovecot for SMTP authentication. local_recipient_maps tells Postfix to look up valid recipients in LDAP instead of the local user table - without this, Postfix rejects mail to LDAP users with "User unknown in local recipient table".

I created /etc/postfix/ldap-recipients.cf for the recipient lookup:

server_host = ldaps://ldap-server.acme.internal
bind = yes
bind_dn = cn=sssd,ou=service-accounts,dc=acme,dc=internal
bind_pw = SSSDPass123
search_base = ou=users,dc=acme,dc=internal
query_filter = (&(objectClass=posixAccount)(mail=%s))
result_attribute = mail

Then reloaded Postfix:

sudo systemctl reload postfix

Local CA Config on Mail Server

I copied rootCA.pem that I created earlier to this server and trusted it.

debian@mail-server:~/acme-certs$ ls
rootCA.pem
debian@mail-server:~/acme-certs$ sudo cp rootCA.pem /usr/local/share/ca-certificates/acme-rootCA.crt
[sudo] password for debian: 
debian@mail-server:~/acme-certs$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt, it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
debian@mail-server:~/acme-certs$

Dovecot TLS Config

I generated a TLS cert for mail-server.acme.internal using mkcert and copied it to the server:

sudo cp mail-server.acme.internal.pem /etc/dovecot/private/mail-server.crt
sudo cp mail-server.acme.internal-key.pem /etc/dovecot/private/mail-server.key
sudo chown root:dovecot /etc/dovecot/private/mail-server.key
sudo chmod 640 /etc/dovecot/private/mail-server.key

Then updated /etc/dovecot/conf.d/10-ssl.conf:

ssl_server_cert_file = /etc/dovecot/private/mail-server.crt
ssl_server_key_file = /etc/dovecot/private/mail-server.key

Dovecot LDAP Config

I changed dovecot auth settings to use LDAP auth instead of system auth by editing /etc/dovecot/conf.d/10-auth.conf - commented out auth-system.conf.ext and uncommented auth-ldap.conf.ext.

debian@mail-server:~/acme-certs$ cat /etc/dovecot/conf.d/10-auth.conf | grep "include auth"
#!include auth-deny.conf.ext
#!include auth-master.conf.ext
#!include auth-oauth2.conf.ext
#!include auth-system.conf.ext
#!include auth-sql.conf.ext
!include auth-ldap.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-static.conf.ext

Dovecot 2.4 changed the config syntax from older versions, so the standard examples online did not work. After checking the example config the package ships with, I set /etc/dovecot/conf.d/auth-ldap.conf.ext to:

ldap_uris = ldaps://ldap-server.acme.internal
ldap_auth_dn = cn=sssd,ou=service-accounts,dc=acme,dc=internal
ldap_auth_dn_password = SSSDPass123
ldap_base = ou=users,dc=acme,dc=internal

passdb ldap {
  ldap_filter = (&(objectClass=posixAccount)(uid=%{user}))
  ldap_bind = yes
}

userdb ldap {
  ldap_filter = (&(objectClass=posixAccount)(uid=%{user}))
  fields {
    uid = vmail
    gid = vmail
    home = /var/mail/vhosts/%{user | username}
  }
}

This reuses the same read-only service account from the LDAP lab. ldap_bind = yes means Dovecot verifies passwords by actually binding to LDAP as the user rather than fetching and comparing the hash. The userdb block maps all mail storage to a dedicated vmail system user instead of running as the LDAP user's UID.

Note: ldap_auth_dn_password is stored in plaintext, but /etc/dovecot/conf.d/auth-ldap.conf.ext is owned by root and not readable by other users.

Dovecot Mail Storage and Postfix Integration

Since LDAP users don't have home directories on the mail server, I created a dedicated vmail system user to own all mailboxes and set up a central mail storage directory:

sudo adduser --system --no-create-home --group vmail
sudo mkdir -p /var/mail/vhosts
sudo chown -R vmail:vmail /var/mail/vhosts
sudo chmod 770 /var/mail/vhosts

I updated /etc/dovecot/conf.d/10-mail.conf to use this path:

mail_driver = maildir
mail_home = /var/mail/vhosts/%{user | username}
mail_path = %{home}/Maildir
first_valid_uid = 100

Then I configured the LMTP and auth unix sockets in /etc/dovecot/conf.d/10-master.conf so Postfix can hand off incoming mail to Dovecot and use Dovecot for SMTP authentication.

In the service lmtp block:

service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}

In the service auth block:

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

Then restarted Dovecot:

sudo systemctl restart dovecot

Verification

Sending mail

I sent a test mail from jsmith to adoe over SMTP from a desktop VM on the same network:

debian@debian:~/acme-certs$ curl -v --url "smtp://mail-server.acme.internal:25" \
  --mail-from "jsmith@acme.internal" \
  --mail-rcpt "adoe@acme.internal" \
  --upload-file - <<EOF
From: jsmith@acme.internal
To: adoe@acme.internal
Subject: Test from jsmith

Hello Alice, this is John.
EOF

Postfix accepted it and delivered it to Dovecot via LMTP:

250 2.0.0 Ok: queued as 98B624018B

Verified the mail landed in adoe's mailbox on the server:

debian@mail-server:~$ sudo ls /var/mail/vhosts/adoe/Maildir/new/
1773903163.M693787P7845.mail-server.acme.internal,S=560,W=576

Retrieving mail over IMAPS

I verified that adoe can authenticate and retrieve mail over IMAPS using their LDAP credentials:

debian@debian:~/acme-certs$ curl -v --url "imaps://mail-server.acme.internal/INBOX" \
  --user "adoe:Password456"

* SSL certificate verify ok.
* Connected to mail-server.acme.internal (192.168.57.7) port 993
< A002 OK Logged in
< * LIST (\HasNoChildren) "." INBOX
< A003 OK List completed (0.001 + 0.000 secs).

TLS handshake succeeded using the mkcert CA, LDAP authentication worked, and the INBOX is accessible.

Thunderbird Verification

Thunderbird has its own certificate store separate from the system trust store, so I had to manually import rootCA.pem into Thunderbird settings before it would trust the IMAPS connection.

adoe sends an email to jsmith

jsmith opens it

jsmith sends a reply email to adoe

adoe views the reply email

Conclusion

Postfix and Dovecot are now running as a mail server for acme.internal. Users defined in the OpenLDAP directory can send and receive mail using their LDAP credentials. Postfix looks up valid recipients in LDAP so it accepts mail for LDAP users. Dovecot authenticates over LDAPS using the same read-only service account from the LDAP lab and stores mail in a central directory owned by a dedicated vmail user. IMAP access is over TLS only.

This mail server will be used in the next part of this series as the SMTP backend for Keycloak notifications.

OpenLDAP home lab - Cyber Security technical write up

Shoban Chiddarth — Tue, 17 Mar 2026 07:55:15 +0000

GitHub Repo: @ShobanChiddarth/openldap-iam-lab

Introduction

This home lab is a part of my setup for an IAM lab using KeyCloak. In this lab I set up OpenLDAP in a Virtualbox lab.

Pre-Requisites

Setup Process

Let's say the fictional organization I am working in is Acme Inc. The domain name would be acme.internal. I have the VM intercommunication setup that I linked earlier ready. I also setup custom DNS records in the Pi-hole (ldap-server.acme.internal points to 192.168.57.5 and ldap-client.acme.internal points to 192.168.57.6).

Setting up LDAP server

I installed slapd and ldap-utils

sudo apt update
sudo apt install slapd ldap-utils

And set the admin password mid installation, then configured it with

sudo dpkg-reconfigure slapd

It asked me for organization name along with domain, I filled in with the appropriate details. And verified it with

debian@ldap-server:~$ sudo slapcat
dn: dc=acme,dc=internal
objectClass: top
objectClass: dcObject
objectClass: organization
o: Acme
dc: acme
structuralObjectClass: organization
entryUUID: 2938c77a-b601-1040-8564-d9abd6bd9b70
creatorsName: cn=admin,dc=acme,dc=internal
createTimestamp: 20260317035728Z
entryCSN: 20260317035728.729122Z#000000#000#000000
modifiersName: cn=admin,dc=acme,dc=internal
modifyTimestamp: 20260317035728Z

Creating Directory structure

I created structure.ldif to add two organizational units - one for users and one for groups, and loaded it.

debian@ldap-server:~$ nano structure.ldif
debian@ldap-server:~$ cat structure.ldif 
dn: ou=users,dc=acme,dc=internal
objectClass: organizationalUnit
ou: users

dn: ou=groups,dc=acme,dc=internal
objectClass: organizationalUnit
ou: groups
debian@ldap-server:~$ ldapadd -x -D "cn=admin,dc=acme,dc=internal" -W -f structure.ldif
Enter LDAP Password: 
adding new entry "ou=users,dc=acme,dc=internal"

adding new entry "ou=groups,dc=acme,dc=internal"

Adding users

I will be creating 2 users "John Smith" and "Alice Doe" with passwords Password123 and Password456 respectively. I generated the password hashes using

debian@ldap-server:~$ sudo /usr/sbin/slappasswd -s Password123
{SSHA}2sIS9koZfMFfwEjWoglS4Iu8XpCvamLk
debian@ldap-server:~$ sudo /usr/sbin/slappasswd -s Password456
{SSHA}QlqSwZdrWeINW5PS54vTx4Bpqt+6PLdi
debian@ldap-server:~$

Then created 2 users in users.ldif and loaded them.

debian@ldap-server:~$ nano users.ldif
debian@ldap-server:~$ cat users.ldif 
dn: uid=jsmith,ou=users,dc=acme,dc=internal
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: jsmith
sn: Smith
givenName: John
cn: John Smith
displayName: John Smith
uidNumber: 10001
gidNumber: 10001
userPassword: {SSHA}2sIS9koZfMFfwEjWoglS4Iu8XpCvamLk
loginShell: /bin/bash
homeDirectory: /home/jsmith
mail: jsmith@acme.internal

dn: uid=adoe,ou=users,dc=acme,dc=internal
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: adoe
sn: Doe
givenName: Alice
cn: Alice Doe
displayName: Alice Doe
uidNumber: 10002
gidNumber: 10002
userPassword: {SSHA}QlqSwZdrWeINW5PS54vTx4Bpqt+6PLdi
loginShell: /bin/bash
homeDirectory: /home/adoe
mail: adoe@acme.internal
debian@ldap-server:~$ ldapadd -x -D "cn=admin,dc=acme,dc=internal" -W -f users.ldif
Enter LDAP Password: 
adding new entry "uid=jsmith,ou=users,dc=acme,dc=internal"

adding new entry "uid=adoe,ou=users,dc=acme,dc=internal"

Adding groups

I created groups engineering and HR, added jsmith to engineering and Alice to HR, and loaded them.

debian@ldap-server:~$ nano groups.ldif
debian@ldap-server:~$ cat groups.ldif 
dn: cn=engineers,ou=groups,dc=acme,dc=internal
objectClass: posixGroup
cn: engineers
gidNumber: 10001
memberUid: jsmith

dn: cn=hr,ou=groups,dc=acme,dc=internal
objectClass: posixGroup
cn: hr
gidNumber: 10002
memberUid: adoe
debian@ldap-server:~$ ldapadd -x -D "cn=admin,dc=acme,dc=internal" -W -f groups.ldif
Enter LDAP Password: 
adding new entry "cn=engineers,ou=groups,dc=acme,dc=internal"

adding new entry "cn=hr,ou=groups,dc=acme,dc=internal"

debian@ldap-server:~$

Setting up LDAPS (using mkcert)

I created TLS certificates for ldap-server.acme.internal.

debian@debian:~/acme-certs$ mkcert -install
Created a new local CA 💥
The local CA is now installed in the system trust store! ⚡️
ERROR: no Firefox and/or Chrome/Chromium security databases found

debian@debian:~/acme-certs$ mkcert -CAROOT
/home/debian/.local/share/mkcert
debian@debian:~/acme-certs$ cp $(mkcert -CAROOT)/rootCA.pem .
debian@debian:~/acme-certs$ ls
rootCA-key.pem  rootCA.pem
debian@debian:~/acme-certs$ mkcert ldap-server.acme.internal
Note: the local CA is not installed in the Firefox and/or Chrome/Chromium trust store.
Run "mkcert -install" for certificates to be trusted automatically ⚠️

Created a new certificate valid for the following names 📜
 - "ldap-server.acme.internal"

The certificate is at "./ldap-server.acme.internal.pem" and the key at "./ldap-server.acme.internal-key.pem" ✅

It will expire on 17 June 2028 🗓

debian@debian:~/acme-certs$ ls -l
total 16
-rw------- 1 debian debian 1704 Mar 17 09:55 ldap-server.acme.internal-key.pem
-rw-r--r-- 1 debian debian 1472 Mar 17 09:55 ldap-server.acme.internal.pem
-rw-r--r-- 1 debian debian 1619 Mar 17 09:54 rootCA.pem
debian@debian:~/acme-certs$

Copied those 3 files onto the server and set the required permissions.

debian@ldap-server:~/acme-certs$ ls
ldap-server.acme.internal-key.pem  ldap-server.acme.internal.pem  rootCA.pem
debian@ldap-server:~/acme-certs$ sudo mkdir -p /etc/ldap/tls
debian@ldap-server:~/acme-certs$ sudo cp ldap-server.acme.internal.pem /etc/ldap/tls/ldap-server.crt
debian@ldap-server:~/acme-certs$ sudo cp ldap-server.acme.internal-key.pem /etc/ldap/tls/ldap-server.key
debian@ldap-server:~/acme-certs$ sudo cp rootCA.pem /etc/ldap/tls/rootCA.pem
debian@ldap-server:~/acme-certs$ sudo chown -R openldap:openldap /etc/ldap/tls
debian@ldap-server:~/acme-certs$ sudo chmod 640 /etc/ldap/tls/ldap-server.key
debian@ldap-server:~/acme-certs$ sudo chmod 644 /etc/ldap/tls/ldap-server.crt /etc/ldap/tls/rootCA.pem
debian@ldap-server:~/acme-certs$ ls -l /etc/ldap/tls/
total 12
-rw-r--r-- 1 openldap openldap 1472 Mar 17 10:51 ldap-server.crt
-rw-r----- 1 openldap openldap 1704 Mar 17 10:51 ldap-server.key
-rw-r--r-- 1 openldap openldap 1619 Mar 17 10:51 rootCA.pem
debian@ldap-server:~/acme-certs$ ls -ld /etc/ldap/tls/
drwxr-xr-x 2 openldap openldap 4096 Mar 17 10:51 /etc/ldap/tls/
debian@ldap-server:~/acme-certs$

Then I created tls conf file (tls.ldif) and applied it.

debian@ldap-server:~$ nano tls.ldif
debian@ldap-server:~$ cat tls.ldif 
dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/tls/rootCA.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/tls/ldap-server.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/tls/ldap-server.key
debian@ldap-server:~$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

debian@ldap-server:~$

Then I set SLAPD_SERVICES in /etc/default/slapd to use LDAPS

SLAPD_SERVICES="ldapi:/// ldaps:///"

And specified LDAP client tools on the server to use the certificate

debian@ldap-server:~$ echo "TLS_CACERT /etc/ldap/tls/rootCA.pem" | sudo tee -a /etc/ldap/ldap.conf
TLS_CACERT /etc/ldap/tls/rootCA.pem
debian@ldap-server:~$

Then I restarted slapd service and checked if LDAPS is working

debian@ldap-server:~$ sudo systemctl restart slapd
debian@ldap-server:~$ ldapsearch -x -H ldaps://ldap-server.acme.internal \
  -D "cn=admin,dc=acme,dc=internal" -W \
  -b "dc=acme,dc=internal" "(objectClass=*)"
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=acme,dc=internal> with scope subtree
# filter: (objectClass=*)
# requesting: ALL
#

# acme.internal
dn: dc=acme,dc=internal
objectClass: top
objectClass: dcObject
objectClass: organization
o: Acme
dc: acme

# users, acme.internal
dn: ou=users,dc=acme,dc=internal
objectClass: organizationalUnit
ou: users

# groups, acme.internal
dn: ou=groups,dc=acme,dc=internal
objectClass: organizationalUnit
ou: groups

# jsmith, users, acme.internal
dn: uid=jsmith,ou=users,dc=acme,dc=internal
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: jsmith
sn: Smith
givenName: John
cn: John Smith
displayName: John Smith
uidNumber: 10001
gidNumber: 10001
userPassword:: e1NTSEF9MnNJUzlrb1pmTUZmd0VqV29nbFM0SXU4WHBDdmFtTGs=
loginShell: /bin/bash
homeDirectory: /home/jsmith
mail: jsmith@acme.internal

# adoe, users, acme.internal
dn: uid=adoe,ou=users,dc=acme,dc=internal
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: adoe
sn: Doe
givenName: Alice
cn: Alice Doe
displayName: Alice Doe
uidNumber: 10002
gidNumber: 10002
userPassword:: e1NTSEF9UWxxU3daZHJXZUlOVzVQUzU0dlR4NEJwcXQrNlBMZGk=
loginShell: /bin/bash
homeDirectory: /home/adoe
mail: adoe@acme.internal

# engineers, groups, acme.internal
dn: cn=engineers,ou=groups,dc=acme,dc=internal
objectClass: posixGroup
cn: engineers
gidNumber: 10001
memberUid: jsmith

# hr, groups, acme.internal
dn: cn=hr,ou=groups,dc=acme,dc=internal
objectClass: posixGroup
cn: hr
gidNumber: 10002
memberUid: adoe

# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 7
debian@ldap-server:~$

But there was one small problem with this. The userPassword's base64 encoded SSHA has is visible. I am going to fix that using ACLs.

I created acls.ldif and set the contents and loaded it and verified it.

debian@ldap-server:~$ nano acls.ldif
debian@ldap-server:~$ cat acls.ldif 
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword
  by self write
  by anonymous auth
  by dn="cn=admin,dc=acme,dc=internal" write
  by * none
olcAccess: {1}to attrs=shadowLastChange
  by self write
  by * read
olcAccess: {2}to *
  by self write
  by dn="cn=admin,dc=acme,dc=internal" write
  by * read
debian@ldap-server:~$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f acls.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}mdb,cn=config"

debian@ldap-server:~$ ldapsearch -x -H ldaps://ldap-server.acme.internal \
  -b "dc=acme,dc=internal" "(uid=jsmith)" userPassword
# extended LDIF
#
# LDAPv3
# base <dc=acme,dc=internal> with scope subtree
# filter: (uid=jsmith)
# requesting: userPassword 
#

# jsmith, users, acme.internal
dn: uid=jsmith,ou=users,dc=acme,dc=internal

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
debian@ldap-server:~$

Setting up LDAP client

I copied rootCA.pem to the LDAP client and trusted it.

debian@ldap-client:~/acme-certs$ ls
rootCA.pem
debian@ldap-client:~/acme-certs$ sudo cp rootCA.pem /usr/local/share/ca-certificates/acme-rootCA.crt
[sudo] password for debian: 
debian@ldap-client:~/acme-certs$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt, it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
debian@ldap-client:~/acme-certs$

Then I installed System Security Services

sudo apt install -y sssd libpam-sss libnss-sss

I now created the configuration for it, set the permissions and enabled the service.

debian@ldap-client:~$ sudo nano /etc/sssd/sssd.conf
debian@ldap-client:~$ sudo cat /etc/sssd/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = acme.internal

[domain/acme.internal]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap-server.acme.internal
ldap_search_base = dc=acme,dc=internal
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
ldap_schema = rfc2307
cache_credentials = true
enumerate = true
debian@ldap-client:~$ sudo chmod 600 /etc/sssd/sssd.conf
debian@ldap-client:~$ sudo systemctl enable --now sssd
Synchronizing state of sssd.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable sssd
debian@ldap-client:~$

The only thing left is automatic home dir creation.

sudo pam-auth-update --enable mkhomedir

This will make sure a home directory is automatically created when john ssh-es into the ldap client.

LDAP Client Verification

debian@ldap-client:~$ id jsmith
uid=10001(jsmith) gid=10001(engineers) groups=10001(engineers)
debian@ldap-client:~$ getent passwd jsmith
jsmith:*:10001:10001:John Smith:/home/jsmith:/bin/bash
debian@ldap-client:~$ getent group engineers
engineers:*:10001:jsmith
debian@ldap-client:~$

LDAP client can see the users and groups set in the LDAP server.

SSH verification

From another desktop, copied rootCA.pem and trusted it.

debian@debian:~/acme-certs$ ls
rootCA.pem
debian@debian:~/acme-certs$ sudo cp rootCA.pem /usr/local/share/ca-certificates/acme-rootCA.crt
[sudo] password for debian: 
debian@debian:~/acme-certs$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt, it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
debian@debian:~/acme-certs$

Now I tried to ssh login

debian@debian:~/acme-certs$ ssh jsmith@ldap-client.acme.internal
The authenticity of host 'ldap-client.acme.internal (192.168.57.6)' can't be established.
ED25519 key fingerprint is SHA256:wo67g9IGEfMUrZBC1KzzKlHS1G41PidIUGXZ5kTGmV0.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ldap-client.acme.internal' (ED25519) to the list of known hosts.
jsmith@ldap-client.acme.internal's password: 
Creating directory '/home/jsmith'.
Linux ldap-client.acme.internal 6.12.73+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1 (2026-02-17) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
jsmith@ldap-client:~$ pwd
/home/jsmith
jsmith@ldap-client:~$

It worked. Also the home dir was automatically created.

Stopping anonymous bind and setup a service account for LDAP client

I need a password hash for the service account first. So I ran

debian@ldap-server:~$ sudo /usr/sbin/slappasswd -s SSSDPass123
[sudo] password for debian: 
{SSHA}ASFdTu5vaW4YSytPSFTpTc1StjoC+giz
debian@ldap-server:~$

Then I put it in service accounts conf file and then load it

debian@ldap-server:~$ nano service-accounts.ldif
debian@ldap-server:~$ cat service-accounts.ldif 
dn: ou=service-accounts,dc=acme,dc=internal
objectClass: organizationalUnit
ou: service-accounts

dn: cn=sssd,ou=service-accounts,dc=acme,dc=internal
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: sssd
description: Read-only service account for SSSD
userPassword: {SSHA}ASFdTu5vaW4YSytPSFTpTc1StjoC+giz
debian@ldap-server:~$ ldapadd -x -H ldaps://ldap-server.acme.internal \
  -D "cn=admin,dc=acme,dc=internal" -W -f service-accounts.ldif
Enter LDAP Password: 
adding new entry "ou=service-accounts,dc=acme,dc=internal"

adding new entry "cn=sssd,ou=service-accounts,dc=acme,dc=internal"

debian@ldap-server:~$

And then I create another ACL to make sure I only allow that specific account and disallow anonymous binds

debian@ldap-server:~$ nano acls2.ldif
debian@ldap-server:~$ cat acls2.ldif 
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword
  by self write
  by anonymous auth
  by dn="cn=admin,dc=acme,dc=internal" write
  by * none
olcAccess: {1}to attrs=shadowLastChange
  by self write
  by * read
olcAccess: {2}to *
  by self write
  by dn="cn=admin,dc=acme,dc=internal" write
  by dn="cn=sssd,ou=service-accounts,dc=acme,dc=internal" read
  by * none
debian@ldap-server:~$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f acls2.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}mdb,cn=config"

debian@ldap-server:~$

Now I set the LDAP client to use those accounts and restart the service

debian@ldap-client:~$ sudo cat /etc/sssd/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = acme.internal

[domain/acme.internal]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap-server.acme.internal
ldap_search_base = dc=acme,dc=internal
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
ldap_schema = rfc2307
cache_credentials = true
enumerate = true
ldap_default_bind_dn = cn=sssd,ou=service-accounts,dc=acme,dc=internal
ldap_default_authtok = SSSDPass123
debian@ldap-client:~$ sudo systemctl restart sssd

Note: ldap_default_authtok is stored in plaintext, but sssd.conf is locked to root only via the chmod 600 set earlier, so it is not readable by other users on the system.

Verifying again

LDAP client records fetching:

debian@ldap-client:~$ id jsmith
uid=10001(jsmith) gid=10001(engineers) groups=10001(engineers)
debian@ldap-client:~$ getent passwd adoe
adoe:*:10002:10002:Alice Doe:/home/adoe:/bin/bash
debian@ldap-client:~$

SSH verification:

debian@debian:~/acme-certs$ ssh jsmith@ldap-client.acme.internal
jsmith@ldap-client.acme.internal's password: 
Linux ldap-client.acme.internal 6.12.73+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1 (2026-02-17) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Mar 17 11:43:45 2026 from 192.168.57.104
jsmith@ldap-client:~$

It is working. Only the LDAP client can call the LDAP servers and anonymous binds are disabled.

Screenshots

VBoxManager

ALL VMs

Conclusion

OpenLDAP is now running as the centralized identity backend for acme.internal. The directory is secured with LDAPS using the lab's mkcert CA. ACLs enforce least-privilege access - password hashes are not exposed to anyone except the admin, and anonymous binds are disabled entirely. A dedicated read-only service account is the only thing allowed to query the directory, which is what SSSD on ldap-client uses. Users that exist only in LDAP can SSH into ldap-client with their home directories created automatically on first login.

This is the identity foundation for the next part of this series - connecting Keycloak to this LDAP directory as its user backend.

Setting up HTTPS on my home lab

Shoban Chiddarth — Mon, 09 Mar 2026 03:22:10 +0000

Introduction

This is the third part of my physical network engineering home lab series of blogs. In this blog I will be sharing how I set up SSL on my home lab and then accessed locally hosted services without a warning in the browser.

And no I am not buying a domain like a lot of YouTubers do, I am going to use mkcert to manage the SSL certificates and install the certificate on each client device and make HTTPS work with no warning from the browser. I chose mkcert because manually configuring openssl certificates and maintaining a certificate hierarchy is tedious for a home lab.

The goal of enabling HTTPS is to securely access the Pi-hole admin panel, and other locally hosted services in the home lab.

Side note: SSL is deprecated and replaced with TLS but the term SSL certificates is used in slang and I will be going with that in this blog

Requirements

A Linux machine
package libnss3-tools
```
sudo apt install libnss3-tools
```
package mkcert. For Linux Mint you can download via apt
```
sudo apt install mkcert
```
but if it is not available via apt you have to download it from GitHub

Steps

Creating `rootCA`

This is the highest in the hierarchy of certificates and we will be copying the root certificate to other devices to make them work with HTTPS.

On your client machine (not the server), run
```
mkcert -install
```
After it is installed, run
```
mkcert -CAROOT
```
This will print the directory where the root key and the root certificate is stored. Make a note of it.

gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$ mkcert -install
Created a new local CA 💥
The local CA is now installed in the system trust store! ⚡️
The local CA is now installed in the Firefox and/or Chrome/Chromium trust store (requires browser restart)! 🦊

gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$ mkcert -CAROOT
/home/gray/.local/share/mkcert
gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$

Creating Certificates

In a separate directory, run the following command. 2 files will be stored on that current directory which you will need to copy to the server.
```
mkcert domain-name.internal
```
I have created only for pi.hole because that is the only service I want to secure right now.

gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$ mkcert pi.hole

Created a new certificate valid for the following names 📜
 - "pi.hole"

The certificate is at "./pi.hole.pem" and the key at "./pi.hole-key.pem" ✅

It will expire on 8 June 2028 🗓

gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$ ls
pi.hole-key.pem  pi.hole.pem
gray@OMEN-Slim-Gaming-Laptop-16:~/home-lab-tls$

Combine those 2 files along with the rootCA.pem in this specific order

cat pi.hole-key.pem pi.hole.pem  $(mkcert -CAROOT)/rootCA.pem > pi.hole-combined.pem

Copy the combined file to the server, into the directory /etc/pihole
On the server, make sure the file is owned by user and group pihole and only the owner can read/write to it.

sudo chown pihole:pihole pi.hole-combined.pem                 
sudo chmod 600 pi.hole-combined.pem

Pointing the Pi-hole server to use these certificates

Edit this section in /etc/pihole/pihole.toml as shown

  [webserver.tls]
    # Path to the TLS (SSL) certificate file.
    #
    # All directories along the path must be readable and accessible by the user running
    # FTL (typically 'pihole'). This option is only required when at least one of
    # webserver.port is TLS. The file must be in PEM format, and it must have both,
    # private key and certificate (the *.pem file created must contain a 'CERTIFICATE'
    # section as well as a 'RSA PRIVATE KEY' section).
    #
    # The *.pem file can be created using `cp server.crt server.pem && cat server.key >>
    # server.pem` if you have these files instead
    #
    # Allowed values are:
    #     A valid TLS certificate file (*.pem)
    cert = "/etc/pihole/pi.hole-combined.pem"

    # Number of days the automatically generated self-signed TLS/SSL certificate will be
    # valid for.
    #
    # Defaults to 47 days. A minimum of 7 days is enforced.
    # Some devices may enforce shorter validity ranges. Note that defining a lower
    # validity range may require you to accept the self-signed certificate more often in
    # your browser.
    # Pi-hole will regenerate certificates it created itself two days prior to expiration.
    # If you are using your own certificate, you need to regenerate it yourself. In this
    # case, it is advised to set the validity range to 0 days, so that Pi-hole does not
    # try to regenerate your certificate. If you set the validity range to 0 days and
    # still try to generate a certificate, Pi-hole will set a fixed validity range of
    # roughly 30 years for the certificate.
    validity = 0

Replace cert variable with where you stored the combined certificate, and then restart Pi-hole.

sudo service pihole-FTL restart

Side Note: If nginx is running, disable it. Pi-hole's FTL has a built-in web server that handles TLS directly - Nginx will conflict with it on port 80/443.

sudo systemctl disable nginx --now

Verifying HTTPS on current device

Open https://pi.hole in the browser of the device you ran mkcert -install command on.

Verifying it on other devices

Copy the file $(mkcert -CAROOT)/rootCA.pem to other devices, and import to the device's certificates (instructions vary for each device, Google it) store and then open https://pi.hole on the browser.

Conclusion

The Pi-hole admin panel is now accessible over HTTPS with a trusted certificate - no browser warnings, no exceptions. Any other device on the network can be added by copying the rootCA.pem and importing it into the system trust store.

From here, the physical lab has DNS, ad-blocking, and HTTPS in place.

The Superior Way to make VMs communicate with each other as well as host, with internet access

Shoban Chiddarth — Sat, 07 Mar 2026 14:05:19 +0000

Introduction

On December 1, 2025, I made a LinkedIn post about setting up inter-VM networking with 3 VMs (a DHCP server, a web server and a client). The full details and a technical document are available in the post if you want to check it out.

The way I set up 3 VMs for inter-VM networking with internet access is

VMs are set to use "Virtualbox Host Only Ethernet Adapter"
Internet is shared to the adapter using Windows proprietary ICS ("Internet Connection Sharing") from Control Panel. It worked in a Windows host (I was temporarily using Windows at that time) because internet sharing is fully handled by Windows, and the inter-VM networking worked with no issues.

Now I am using a Linux host and need to set up inter-VM networking for a project, the same thing is not possible as ICS is a Windows proprietary service. A similar solution will require turning the host into a router and manually managing firewall entries and route tables every time a network segment is created or removed - invasive and hard to cleanly reverse. The other option is attaching two adapters to each VM: one for inter-VM and host communication, another for internet access - which gets complicated across several VMs and can cause issues with desktop environments and network managers.

There is a superior way to achieve the following:

VMs can communicate with each other
Host can communicate with VMs and vice versa
VMs can access the internet
Host does not need to be converted to a router
2 or more adapters do not need to be attached to every single VM
Nothing is permanently changed on the host that requires manual intervention to revert, everything stays in Virtualbox and goes away when you delete them

The solution is to run pfSense in a VM that acts as the router between network adapters, keeping everything contained inside VirtualBox.

Overview

The setup is simple: install pfSense inside a VM and attach two adapters to it.

The first adapter connects pfSense to the internet. You can use Bridged, NAT, or NAT Network - all three work as long as the host has internet access. (Bridged gives pfSense a real IP on your physical LAN; NAT and NAT Network are simpler and work without touching your router).

For more information on VirtualBox virtual networking, see the manual.

The second adapter is a VirtualBox Host Only Ethernet Adapter attached to a specific Host Only Network. This becomes the LAN side.

For every other VM in your lab, attach a single VirtualBox Host Only Ethernet Adapter and select the same Host Only Network you assigned to pfSense's LAN adapter.

In pfSense, assign the first adapter as WAN and the Host Only Ethernet Adapter as LAN.

Disable the VirtualBox built-in DHCP server for that Host Only Network, and configure DHCP inside pfSense instead.

Always boot pfSense before your lab VMs - it handles DHCP and routing for the entire network.

Steps

Install pfSense on VirtualBox

Download the pfSense ISO file from Netgate Shop
Click "New" on Virtual Box and fill in the name of the OS, select the ISO file.
Select OS: "BSD"; Distro: "FreeBSD"; OS Version: "FreeBSD 64 bit";

Select 2GB RAM and 4GB Hard Disk

Click on "Start" and then install the OS. By default, Virtualbox assigns the "NAT" adapter as the only interface. That is fine for now. Select that as the WAN interface in the installation process. For installing the OS, accept defaults for everything else.
After installation is over, shut the VM down instead of rebooting.
Go to VM's settings -> Storage and remove the ISO file.

Click "Ok" and then boot the VM up.

If it boots up to this state then it means that it is successful. Now you can reset the admin account and password, then shut it down.

Configuring interfaces on pfSense

Go to Virtualbox Networks and select "Host Only Networks". Create a new Host Only Network if you do not want to use the default. Note the subnet/CIDR block.
Go to Machines -> pfSense VM settings -> Network and enable a second adapter, and set it to VirtualBox Host Only Ethernet Adapter and then select the Host Only Network you wish to use it. Make sure to select "Allow All" in promiscuous mode. This allows pfSense to forward traffic on behalf of other VMs.

Click on "OK" and boot it up again.

Select "1" to configure interfaces. Then select no for VLANs, assign em0 as WAN interface and then em1 as LAN interface. Then confirm it.

Select 2 to set interface IP addresses. We need a static IP on the LAN interface because pfSense will be our DHCP server. Make sure you are setting up an IP that does not clash with the host, and lies in the same subnet as the VirtualBox Host only network, then choose to enable DHCP server on LAN. (IPv6 is optional). > Note: To find the host's IP on that network, go to VirtualBox Manager -> Networks -> Host Only Networks and select your network.

After it is done, access the static IP you set via a web browser from the host. Enter the username admin and the password you set up earlier.

pfSense web configuration

Click next on the welcome messages and on the initial configuration, enter the appropriate values as shown in the image. Make sure to set up a valid upstream DNS resolver.

Leave the timeserver as is, and choose your timezone.

Click next and you will be asked to configure WAN and LAN interfaces. Change nothing as you already set this one up.
Set the admin account password again when it prompts you to and then reload and login. At this point pfSense is fully operational. Any additional configuration such as firewall rules or DNS overrides can be done from this interface.

VM Intercommunication and Verification

Create VMs as needed. Make sure to attach a VirtualBox Host Only Ethernet Adapter and select the Host Only Network you set up pfSense in.

Set up a web server VM with a static IP and a test page to verify host-to-VM communication.

Set up a client VM in the same adapter and network, configured as a DHCP client. Verify that it receives an IP from pfSense.

From the client VM, access the web server using its IP. Verify that VM-to-VM communication works.

Verify internet access from the client VM.

Note that the client VM has only one interface attached - the Host Only Ethernet Adapter with the relevant Host Only Network selected. Through this single adapter, the VM can reach other VMs on the same network, the host, and the internet.

Conclusion

The result is a clean, self-contained lab network: VMs can communicate with each other and the host, have full internet access, and the host requires no permanent configuration changes. pfSense handles routing, DHCP, and DNS entirely within VirtualBox.

This setup works as a solid foundation for any multi-VM lab that needs real network services, making it particularly useful for cybersecurity home labs.

The Superior way to share files over a LAN

Shoban Chiddarth — Fri, 06 Mar 2026 13:18:02 +0000

GitHub: @ShobanChiddarth/openssh-server

You need to send a file to another machine on your network. It should be a solved problem. It is not.

Every method people actually reach for is either insecure, annoying to set up, or leaves something running on your machine long after you needed it. This post is about the one approach that gets all three things right - and it takes about two minutes to set up.

What You're Probably Doing (And Why It's Bad)

Let's go through the common options honestly.

Python HTTP server

python3 -m http.server 8080

Everyone knows this one. It works, and that's roughly where the positives end. Traffic is completely unencrypted. Anyone on the same network can see every byte in transit. There's no authentication - anyone who can reach the port can download anything you're serving.

Netcat

# sender
nc -l 9999 < file.txt

# receiver
nc 192.168.1.x 9999 > file.txt

Same problem. Cleartext, no auth, one shot if you're lucky. It's basically a raw pipe over TCP dressed up as a tool.

Installing openssh-server on your machine

This one at least solves the encryption problem. But now you've installed a permanent service on your host OS. sshd is running all the time, listening on port 22, attached to your actual system - its users, its filesystem, its everything. You wanted to share one folder for five minutes. You now have a permanently expanded attack surface.

And if you give the other person SSH credentials? They have a shell into your real machine. Full access. That's a lot of trust for a quick file transfer.

Samba / NFS

Heavy to configure, plenty of surface area, and definitely not something you spin up for a quick transfer and tear down cleanly.

The Actual Problem

The core issue with all of these is that they either skip encryption entirely, or they go too far in the other direction and give the other party more access than a file transfer requires.

What you actually want is:

Encrypted transfer
Auth (so not just anyone on the LAN can connect)
Access scoped to exactly one directory, nothing else
Zero footprint when you're done

The Solution: OpenSSH Inside a Docker Container

Here's the idea: run an SSH server inside a Docker container. Mount only the specific directory you want to share into that container. The other party connects over SSH, lands in that directory, and that's all they can see - not your home folder, not your system files, not anything else on your machine. When the transfer is done, you stop the container and it's completely gone.

The host OS never has sshd installed. No permanent service. No lingering open port. The container is the entire blast radius.

I built and published this as a ready-to-use Docker image with two variants: one based on Alpine Linux (smaller, recommended) and one based on Ubuntu Noble. The image handles user creation, password setup, and public key injection entirely through environment variables.

How It Works

When the container starts, the entrypoint script does the following:

Reads SSH_USER, SSH_PASSWORD, and SSH_PUBLIC_KEY from environment variables
Creates a low-privilege user inside the container with those credentials
Writes the public key to that user's ~/.ssh/authorized_keys
Starts sshd in the foreground

The user's home directory inside the container is whatever you bind-mount from your host. They can read and write files there. That's the full extent of what they can touch.

Step-by-Step: Running It

Prerequisites: Docker installed and running. That's it.

1. Pull the image

docker pull shobanchiddarth/openssh-server:alpine-1.0.0

Or if you prefer the Ubuntu variant:

docker pull shobanchiddarth/openssh-server:ubuntu-noble-1.0.0

2. Create the directory you want to share

mkdir -p /tmp/myshare

Put whatever files you want to transfer in here, or leave it empty for the other party to upload into.

3. Set up your environment variables

Grab the sample.env from the repo and copy it:

cp sample.env .env

Edit .env:

SSH_USER=USERNAME
SSH_PASSWORD=PASSWORD
SSH_PUBLIC_KEY=ssh-ed25519 AAAA... you@yourmachine

SSH_PUBLIC_KEY is optional in practice - if the other party doesn't have a key pair, they'll just use the password. But public key is always preferable.

4. Run the container

docker run -d \
  --name myshare \
  -p 0.0.0.0:2222:22 \
  --env-file .env \
  -v /tmp/myshare:/home/USERNAME \
  shobanchiddarth/openssh-server:alpine-1.0.0

The -v flag is the key part. /tmp/myshare is the folder on your machine. /home/USERNAME is where the SSH user lands inside the container. Those two are linked - anything written to one appears in the other. The username in the path should match SSH_USER in your .env.

Your LAN IP is whatever ip a (Linux) or ipconfig (Windows) shows for your network interface - typically something like 192.168.1.x.

5. Transfer files from the other machine

# Upload a file
scp -P 2222 /path/to/file.txt USERNAME@192.168.1.x:~/

# Download a file
scp -P 2222 USERNAME@192.168.1.x:~/file.txt ./

# Interactive session
sftp -P 2222 USERNAME@192.168.1.x

This works from Linux, macOS, and Windows (via PowerShell with OpenSSH, WSL, or Git Bash - all ship with scp and sftp).

6. Tear it down

docker stop myshare
docker rm myshare

Port closed. No service running. Nothing left behind.

Windows Host Note

If you're running Docker Desktop on Windows, the volume mount path uses Windows-style paths:

docker run -d `
  --name myshare `
  -p 0.0.0.0:2222:22 `
  --env-file .env `
  -v C:\Users\YourName\myshare:/home/USERNAME `
  shobanchiddarth/openssh-server:alpine-1.0.0

Everything else - the scp/sftp commands from the client side - is identical.

Security Properties at a Glance

Property	Behavior
Encryption	SSH - all traffic encrypted in transit
Authentication	Password + public key
Host filesystem	Completely inaccessible from inside the container
Shell access	Scoped to the container only
Host SSH daemon	Never installed
Persistence after use	Zero - stop the container, it's gone

One thing worth being explicit about: bind the port to 0.0.0.0 only on trusted networks. That makes the container reachable on all your local interfaces. If you want to lock it down to a specific interface, replace 0.0.0.0 with that interface's IP (e.g., 192.168.1.5:2222:22). Either way, don't forward port 2222 through your router - this is a LAN tool.

Why This Is Better

The Python HTTP server is convenient. This is only marginally less convenient - one docker run command instead of one python3 command - and in exchange you get encryption, authentication, proper access scoping, and a completely clean teardown.

If you have Docker, there's no good reason to reach for the HTTP server anymore.

The repo has both Alpine and Ubuntu variants, a sample.env template, and full usage documentation. Pull it, try it, and stop sharing files over cleartext.

The `known_hosts` problem

Let's say you want your friend to share a file to you. So you ask him his public ssh key and spin up a container with port and volume mapped. And then he tries to ssh into your container. Then he gets hit with this

ssh test@192.168.1.2
The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established.
ED25519 key fingerprint is SHA256:9d8pzTNQ1vLi2laKIqHnzOG+QdgNv8bDQVz67sNJi1E.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This is the unknown host warning, it is what ssh usually does to make sure you are accessing the machine you think you are accessing by showing the host key of the machine. So since your friend knows he is accessing your machine and trusts is, he types yes and then the host key gets added to ~/.ssh/known_hosts file. He then finishes the file sharing work and then closes the connection so you stop the container and delete it. Some time later if he wants to do another file sharing work, you spin up another container and if you are in the same LAN with the same private IP, ssh client on his machine sees your host with a different ssh host key when he is trying to access it. So it prints a message like this

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:s9QoffY4cHer0u66A9s57WzN3/ufOfCBGTq/v9fhr5w.
Please contact your system administrator.
Add correct host key in /home/mint/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/mint/.ssh/known_hosts:3
  remove with:
  ssh-keygen -f '/home/mint/.ssh/known_hosts' -R '[192.168.56.1]:2222'
Host key for [192.168.56.1]:2222 has changed and you have requested strict checking.
Host key verification failed.

But this can be ignored since it is true that the host key has changed and he has to remove the old known hosts entry with

ssh-keygen -f '/home/mint/.ssh/known_hosts' -R '[192.168.56.1]:2222'

as said in that message. If it is unsure whether or not SOMEONE is doing SOMETHING NASTY you should send your host key to your friend and ask him to compare. You can do it by

docker exec -it myshare /bin/sh # or /bin/bash if ubuntu
cd /etc/ssh
ls *host*.pub # to see the host public key names
ssh-keygen -lf ssh_host_ecdsa_key.pub 
ssh-keygen -lf ssh_host_ed25519_key.pub 
ssh-keygen -lf ssh_host_rsa_key.pub

Now send the output of the last 3 commands to him and tell him to enter the fingerprint of the algorithm (ecdsa or ed25519 or rsa) he is seeing in his screen and if it matches the host will be added to known_hosts (with the current host public key, so he will have to remove it later by following the above instructions) and the connection will happen.

GitHub: @ShobanChiddarth/openssh-server

Setting Up Pi-hole as a Custom DNS Server on my Home Lab

Shoban Chiddarth — Wed, 04 Mar 2026 14:14:02 +0000

Introduction

I'm building out a home lab and this post covers setting up Pi-hole as a custom DNS server so that internal hosts are reachable by name rather than IP address.

This is part of my Physical Network Engineering Home Lab series where I document building and configuring a physical home lab from scratch.

Reason for Choosing Pi-Hole as a custom DNS server

I needed a local DNS server where I could register internal hostnames and have them resolve across the network — so my server is reachable as server.local rather than 192.168.1.2. This becomes especially important as I add more services to the lab.

Pi-hole fits this requirement well. It is primarily a network-level DNS server that supports custom local DNS records, and it comes with a clean web interface for managing them. The fact that it also blocks ads and trackers at the DNS level for every device on the network is a useful side effect — the FBI has even recommended ad blockers as protection against malvertising scams, so having this enforced network-wide without configuring each device individually is a reasonable security baseline.

Setting up Pi-Hole

Pre-requisites

Refer my Physical Network Engineering Home Lab to understand what I already have and working with.

Installing Pi-Hole software on my server

My server runs headless Linux Mint, which is Ubuntu-based and officially supported for Pi-hole.

So I am going to manually download the installer and run it on my server.

wget -O basic-install.sh https://install.pi-hole.net
sudo bash basic-install.sh

The usual install process begins, and I get asked about choosing upstream DNS server.

I went with cloudflare, selected the default ad blocklist, enabled query logging, selected "show everything" because I am the only one using this home lab so there are no privacy issues, and waited for it to finish installing.

The installation is now complete and I get this popup

Post-installation

Pi-hole installs a web interface under /var/www/html/admin. I confirmed it was there after installation.

I visited my server's IP 192.168.1.2 on the browser and it worked fine, like usually.

I tried to access the admin panel at 192.168.1.2/admin and got a 403 error.

Then I remembered the admin panel works only over https. So I tried visiting https://192.168.1.2/admin and it never worked. So I came back to the terminal where I have ssh-ed into the server and ran ss -tulnp | grep :443 to check if the service was running, and the service was indeed running on 0.0.0.0 which means it is supposed to be accessible from the other hosts. That is when I remembered I enabled ufw and had to allow certain ports in the firewall.

I referred the pi-hole docs for the ufw commands and ran the following snippet in the terminal

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 53/tcp
sudo ufw allow 53/udp
sudo ufw allow 67/tcp
sudo ufw allow 67/udp
sudo ufw allow 123/udp
sudo ufw allow 546:547/udp

(Future me here, I just realised I don't need to allow port 67 as I did not setup DHCP server on the pi hole).

Now that I have allowed the ports, I tried visiting https://192.168.1.2/admin/ and got this warning, which I will be taking care of in the next part of my home lab series where I properly configure SSL and get HTTPS on browsers with no warning.

I clicked on "Proceed" and got the pi-hole admin login page, then I entered my admin password I got from the "Installation over" popup and logged in. Now I get this beautiful dashboard.

Note: You can change the default password by running pihole setpassword on the pi hole server.

Pointing Router's DHCP to use pi-hole as DNS

I opened my Tenda router's login page via its IP, went to "Internet Settings" and set the DHCP server to 192.168.1.2

Then I went into System Settings -> LAN settings and did the same

To refresh the DNS server config from the DHCP configuration, I manually turned off the wifi from my laptop and turned it on again.

The DNS server shows up as 192.168.1.2

Verifying Ad blocking at Network level

I checked if the DNS service was working, for both allowed and blocked hosts.

gray@OMEN-Slim-Gaming-Laptop-16:~$ nslookup google.com
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   google.com
Address: 142.251.222.78
Name:   google.com
Address: 2404:6800:4009:80b::200e

gray@OMEN-Slim-Gaming-Laptop-16:~$ nslookup ad-assets.futurecdn.net 
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   ad-assets.futurecdn.net
Address: 0.0.0.0
Name:   ad-assets.futurecdn.net
Address: ::

gray@OMEN-Slim-Gaming-Laptop-16:~$

It works perfectly fine. Ads are blocked in the network level.

Side note: If you are using Cloudflare WARP for privacy, all your internet traffic, including DNS queries are routed through Cloudflare's servers which means the DNS lookup never reaches your Pi-hole and the advertisements domains will be rendered fine. So if you want to access your home lab's hosts using DNS resolution from pi hole or any other DNS server or network level ad blocking for devices where cloudflare warp is not available, you must temporarily turn off Cloudflare WARP.

Setting Up Custom DNS records

pi.hole is a custom DNS entry in pi-hole by default and it works.

I want to add my own DNS records and check them, which is the entire purpose of this project. So I wanted another host with static IP on the same LAN.

Virtualbox VM with static IP in the LAN

I cloned an existing Mint VM, selected to create random MAC addresses for each interface and set it's network adapter to "Bridged" and bridged it with the real interface I use to connect to the LAN, and set "Promiscuous Mode" to allow all. For more information on Virtualbox networking see Virtualbox Manual - Chapter 6 : Virtual Networking.

When I booted it up, it had DHCP by default.

I went to settings and changed it to static IP 192.168.1.23 and turned the interface off and turned it on again and the static IP is available and accessible from the host as well as the server. I also turned off automatic DNS as DHCP will be disabled and manually added 192.168.1.2 as the DNS server.

Adding a custom DNS record in pi hole web GUI

I went to Pi hole admin page -> settings -> Local DNS records and added this entry

Side Note: I want this to be temporary that is why I didn't bind DHCP reservation to MAC address in the router.

Testing the Custom DNS record

DNS query works from both my laptop and the server. So I set up a nginx web server in the VM like usually

sudo apt-get update
sudo apt-get install nginx -y
sudo systemctl enable nginx --now

And edited the default index.html file.

Nginx web page as well as pinging is working from my laptop

as well as the server.

Changing default website on the pi-hole DNS server (not required)

This is the new website hosted on the root folder of the DNS server.

Minor Issues encountered

Cloudflare WARP conflict (as mentioned above)
Do not use a custom domain with TLD as .local because all .local domains are first processed through the host before sending it anywhere else and it is used for mDNS (multicast DNS, for when hosts need to discover each other without a central DNS server)
Make sure to allow the required ports in your firewall as mentioned above
Every client that is connected to the LAN and is using DHCP has to refresh by disconnecting and reconnecting for this update to work.

CONCLUSION

I have successfully setup pi-hole on an Ubuntu-based server for network wide ad blocking as well as local DNS resolution.

After this, I am going to set up fully local SSL for HTTPS (without browser warnings) on my physical network engineering home lab. I will also document setting up pi-hole in docker as well as a Virtualbox VM as a portable alternative when this pi-hole server is inaccessible.

How to clone all GitHub repos of multiple users at once?

Shoban Chiddarth — Thu, 26 Feb 2026 15:58:52 +0000

Repo Link

This script helps you clone all repositories of a given list of GitHub users (including organizations) at once, instead of cloning them manually one by one.

I built it after running into the need to archive and collect repositories from multiple accounts efficiently. The goal was simple: automate bulk cloning in a clean, repeatable way.

What It Does

Accepts multiple GitHub usernames
Fetches all accessible repositories via the GitHub API
Clones them into a structured local directory
Supports shallow clone (--depth 1) or full history
Skips repositories that are inaccessible or already cloned

Each user gets their own folder inside the target directory.

Requirements

Python 3.12+
git installed and available in PATH
A GitHub Personal Access Token with read access to repository contents

Setup

Generate a Personal Access Token:
- Go to GitHub → Settings → Developer settings → Personal access tokens
- Create a token with repository read access
Copy sample.env to .env
Replace the placeholder token value with your actual token
Install dependencies:

   pip install -r requirements.txt

Usage

Run:

python github-main.py

You’ll be prompted for:

A space-separated list of GitHub usernames
A target directory (default: mass_clone_output)
Clone depth (None for full history or 1 for latest commit only)

The script validates usernames, fetches repositories, and clones them sequentially with live git clone output shown in the terminal.

Repository

How to Enable MAC Address Randomisation in Linux Desktop

Shoban Chiddarth — Sat, 14 Feb 2026 17:01:13 +0000

Link to Project: https://github.com/ShobanChiddarth/randomised_mac_linux

Why a Persistent MAC Address Is a Problem

A persistent hardware address allows networks to consistently identify the same device across sessions. On:

Public Wi-Fi
Campus networks
Enterprise environments
Captive portals

this makes long-term tracking trivial, even if your IP address changes.

Many Linux desktops still use the permanent hardware address by default, which means your device can be passively identified every time it reconnects to a network.

How This Project Solves It

This project automates MAC address randomisation at boot.

On every system startup:

The interface is brought down
A new locally administered MAC address is generated
The interface is brought back up

A systemd service ensures this runs automatically, requiring no manual action after setup.

Installation

When you install macchanger, you may get a prompt to enable regular changing of MAC addresses. You should select "no" because we wan't complete control over when and how the MAC address randomisation is scheduled.

Debian based

Save this script and run it as sudo

sudo apt install macchanger git -y
git clone https://github.com/ShobanChiddarth/randomised_mac_linux.git
cd randomised_mac_linux
chmod +x ./randomise_MACs.sh
sudo cp randomise_MACs.sh /usr/bin/
sudo cp randomise_MACs.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable randomise_MACs

Now your MAC addresses of real network interfaces will automatically change to a random value on each boot. To verify it, you can run ifconfig to show MAC addresses before and after running sudo systemctl start randomise_MACs to compare values.

Other distros

Visit the GitHub repo and google your distro specific command for each command listed.

My Network Engineering Home Lab setup

Shoban Chiddarth — Tue, 10 Feb 2026 14:30:41 +0000

Introduction

A while ago, I built a home lab to gain hands-on experience with Linux server administration and network engineering. Using some old hardware, a ThinkCentre M81 desktop and a Tenda router, I set up a private LAN, configured a static IP and DHCP reservations, and deployed an SSH-accessible Linux server running an Nginx web server.

This project allowed me to apply concepts I had learned in college in a real-world scenario, practice network setup and IP management, and explore server configuration beyond the classroom. It’s also an example of repurposing older hardware to create a functional learning environment.

Below, I’ve documented the full technical process, step by step, so you can see exactly how I built this setup and replicate it if you want to create your own home lab.

Tenda Router Setup

The router I used is the Tenda AC1200 router: https://www.tendacn.com/product/ac6.html.

Turn on the router.
Connect to the router’s LAN port (1 or 2) via ethernet from a PC you are able to use.
Visit 192.168.0.1, the default router IP (written in the back of your router) from a web browser.
Enter the default login password (written in the back of your router).
Go to system settings and change the login password
Go to Wi-Fi settings and change the Wi-Fi name and password.
Go to system settings and upgrade the firmware if needed.

The router is ready for connection. Disconnect the ethernet from the router, you can now access it via Wi-Fi.

ThinkCentre M81 Server setup

Installing Linux Mint

Connect the ethernet port of the CPU to any the Tenda router’s LAN ports, and install linuxmint normally: https://linuxmint-installation-guide.readthedocs.io/en/latest/

But during the installation process, choose to erase the whole disk and install linux mint while asked about partitions.

Do not select to set up an encrypted LVM (full disk encryption) in the Advanced features. Using an LVM is okay but encrypted LVM for full disk encryption requires someone to type the password in the keyboard connected to the server every time it boots, and we want it to automatically boot and be ready for ssh login so it is not recommended.

And the authorized ssh keys stay in the home folder of the user, so if you encrypt it, logging in to the user account will be required for key based ssh to work. Logging in remotely strictly using ssh keys will not work then. So do not encrypt the home folder.

After the installation is complete, login and set the root password.

sudo passwd

Turning the desktop into a server

After that, we need to turn this into a server from a desktop.

Install openssh-server and configure it: https://wiki.debian.org/SSH#Installation_of_the_server
[Not required but highly recommended] Make the ssh server run on a port different from 22, for security (to prevent automated brute force scripts).
[Not required but highly recommended] Turn on firewall and allow the ssh. When the firewall is turned off, every port open on the system is open to the network. So turn it on to make sure only the ports you allow are accessible from the outside.

sudo ufw allow <ssh_port_number>
sudo ufw enable

Now we need static IP for the server instead of DHCP from the router. We will be using systemd-networkd for this.

sudo ifconfig

And remember the name of the ethernet port connecting to the router (usually eno1)

Now stop and disable NetworkManager, it is bound to the display manager so if we use primarily Network Manager, the server will not have networking when started headless.

sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager

Now enable systemd-networkd on boot

sudo systemctl enable systemd-networkd

Create a file /etc/systemd/network/10-eno1.network and put in the contents

[Match]
Name=eno1

[Network]
Address=192.168.0.2/24
Gateway=192.168.0.1
DNS=192.168.0.1

Where 192.168.0.1 is the IP address of your router and 192.168.0.2 is the IP address of the server, and eno1 is the name of the network interface of the ethernet port.

Reload systemd-networkd for the changes to take effect

sudo systemctl restart systemd-networkd

Now run sudo ifconfig again and the ip address should have changed on the ethernet port.
Now that we have static IP, go to router login page -> System Settings -> DHCP Reservation And manually bind the static IP to the MAC address of the server.

We have turned the desktop into a server. Now ssh into it from your PC to test if it works.

ssh -p <ssh_port_number> username@192.168.0.2

Making server headless

Once you have logged in to the server via ssh, you can easily turn it headless. You simply have to stop the display manager and disable it on boot so it always runs headless.

(after ssh into server)
sudo systemctl stop lightdm
sudo systemctl disable lightdm

After this, the monitor screen connected to the desktop goes blank. This is expected. If you are not sure if the system hanged or if the graphical manager has stopped, press Ctrl+Alt+F1 to enter virtual terminal 1. If you see the virtual terminal, it is working properly. Now you can safely remove the monitor and keyboard and mouse from the server’s CPU as you won’t need it anymore and will always access it by ssh.

Configuring Web Server

While you are still ssh-ed into the server, run

sudo apt install nginx
sudo systemctl start nginx
sudo systemctl enable nginx

To install, start and enable the web server on boot. It runs on port 80, the default port for HTTP. So allow it on the firewall for the website to be accessed from the LAN.

sudo ufw allow 80

You can leave it as it is to get the default nginx server page or create a file /var/www/html/index.html with your own website on the index.html file, or even host a react app by copying the build files into the /var/www/html folder.

Accessing the website

Connect to the Wi-Fi network of the Tenda router from any device that has Wi-Fi.

And then open the IP address of the server in a web browser. You will get a no HTTPS warning but you can ignore it and continue since we are in a controlled environment.

SUCCESS

That’s it. The home LAB has been set up successfully. You have a LAN on Wi-Fi and a server that you can ssh into and use as backup storage, and a web server you can host websites on your LAN.