DEV Community: Munir Ahmad

Use Multiple GitHub Accounts on One Machine (SSH)

Munir Ahmad — Sun, 14 Dec 2025 15:01:47 +0000

A step-by-step guide to seamlessly manage multiple GitHub accounts with SSH keys.

Managing Multiple GitHub Accounts on One Machine Using SSH

If you use both personal and work GitHub accounts on the same machine, authentication issues are almost inevitable. Commits go to the wrong account, pushes fail, or Git keeps asking for credentials.

The clean solution is simple: one SSH key per account, configured once, and reused forever. This guide shows how to do exactly that.

What You’ll Learn

Create separate SSH keys for each GitHub account
Configure SSH to automatically select the correct identity
Clone, push, and commit without account conflicts

Applies to: macOS and Linux (Windows users via WSL or Git Bash can follow the same steps)

Prerequisites

Git installed
Basic terminal knowledge
Access to multiple GitHub accounts

Step 1: Generate a Dedicated SSH Key

Create a new key for your work account:

ssh-keygen -t ed25519 -C "work@email.com" -f ~/.ssh/id_ed25519_work

This avoids overwriting existing keys and clearly separates identities.

When prompted, adding a passphrase is recommended for security.

Generated files:

id_ed25519_work — private key (keep secret)
id_ed25519_work.pub — public key (add to GitHub)

Step 2: Add the Key to the SSH Agent

Start the agent and load your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_work

This allows Git to authenticate without repeatedly asking for a passphrase.

Step 3: Add the Public Key to GitHub

Copy your public key:

cat ~/.ssh/id_ed25519_work.pub

Copy the entire output (starts with ssh-ed25519).

Navigate to: https://github.com/settings/keys
Click New SSH key
Add a title (e.g., “Work Laptop — 2024”)
Paste your public key
Click Add SSH key

Highlighting where to add your SSH key in GitHub settings.

Step 4: Configure SSH Host Aliases

Edit your SSH config:

nano ~/.ssh/config

Add:

# Here you can add multiple identities personal, work etc.
# Personal account
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

# Work account
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes

This tells SSH exactly which key to use for each account.

Step 5: Test the Setup

ssh -T github-work

If successful, GitHub will confirm authentication. Expected output:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

Using the Correct Account

Clone Repositories

# Work account
git clone git@github-work:company/repo.git

# Personal account
git clone git@github.com:username/repo.git

Fix an Existing Repository

git remote set-url origin git@github-work:company/repo.git

Set Commit Identity (Per Repository)

git config user.name "Your Name"
git config user.email "work@company.com"

This ensures commits are attributed correctly.

Final Thoughts

Managing multiple GitHub accounts doesn’t require hacks or workarounds.

With one SSH key per account and a clear SSH configuration , Git becomes invisible — and that’s exactly how tooling should behave.

Configure it once. Forget about it forever.

Secure Swagger & ReDoc in Django REST Framework with DRF Spectacular: Best Practices for API…

Munir Ahmad — Sun, 07 Dec 2025 17:56:18 +0000

Secure Swagger & ReDoc in Django REST Framework with DRF Spectacular: Best Practices for API Security

API documentation tools like Swagger UI and ReDoc make development easier, but they also expose every endpoint, schema, and request structure to anyone who can access the URL.

If you deploy your Django REST Framework project without protecting /api/docs/ or /api/schema/, you're unintentionally giving outsiders:

A complete map of all your APIs
All request/response structures
Authentication patterns
Internal admin/debug endpoints

This makes exploitation easier and increases your attack surface.

That’s why Swagger must never be public in production. In this guide, we’ll show a clean, secure way to protect your API documentation using DRF Spectacular in a Django REST Framework project.

A secure architecture for safeguarding Swagger and ReDoc in DRF using DRF Spectacular.

# Directory structure
core/
    docs/
        swagger_view.py
    urls.py
    settings.py

core/docs/swagger_view.py

from django.shortcuts import redirect
from drf_spectacular.views import (
    SpectacularAPIView,
    SpectacularSwaggerView,
    SpectacularRedocView,
)

class AdminOnlyMixin:
    """
    Restrict access to authenticated superusers.
    """

    def dispatch(self, request, *args, **kwargs):
        if not request.user.is_authenticated:
            return redirect(f"/admin/login/?next={request.path}")
        if not request.user.is_superuser:
            return redirect("/403/") # Make sure a 403 page exists
        return super().dispatch(request, *args, **kwargs)

class SuperuserSchemaView(AdminOnlyMixin, SpectacularAPIView):
    pass

class SuperuserSwaggerView(AdminOnlyMixin, SpectacularSwaggerView):
    pass

class SuperuserRedocView(AdminOnlyMixin, SpectacularRedocView):
    pass

core/urls.y

from django.urls import path
from core.docs import (
    SuperuserRedocView,
    SuperuserSchemaView,
    SuperuserSwaggerView,
)

urlpatterns = [
    # API documentation (protected)
    path("api/schema/", SuperuserSchemaView.as_view(), name="schema"),
    path("api/docs/", SuperuserSwaggerView.as_view(url_name="schema"), name="swagger-ui"),
    path("api/redoc/", SuperuserRedocView.as_view(url_name="schema"), name="redoc"),
]

core/settings.py

REST_FRAMEWORK = {
    "DEFAULT_AUTHENTICATION_CLASSES": (
        # JWT for external API clients
        "rest_framework_simplejwt.authentication.JWTAuthentication",

        # Session auth so Swagger works automatically after admin login
        "rest_framework.authentication.SessionAuthentication",
    ),
    "DEFAULT_PERMISSION_CLASSES": (
        "rest_framework.permissions.IsAuthenticated",
    ),
    "DEFAULT_SCHEMA_CLASS": "drf_spectacular.openapi.AutoSchema",
}

SPECTACULAR_SETTINGS = {
    "TITLE": "Your API",
    "DESCRIPTION": "API documentation",
    "VERSION": "1.0.0",

    # Allow our custom view to control permissions manually
    "SERVE_PERMISSIONS": ["rest_framework.permissions.IsAdminUser"],

    # Use DRF’s normal authentication classes (Session + JWT)
    "SERVE_AUTHENTICATION": None,

    # Important: Do NOT expose schema automatically in unrestricted mode
    "SERVE_INCLUDE_SCHEMA": False,
}

Notes:

SessionAuthentication allows admin users to access protected docs easily.
SERVE_INCLUDE_SCHEMA = False ensures your schema isn’t automatically exposed.

And that’s the real value of securing your API documentation: you empower your team without empowering your attackers. When Swagger and ReDoc live behind proper authentication, your developers gain clarity, your system gains integrity, and your attack surface quietly shrinks. Secure the docs, protect the blueprint, and let your API evolve with confidence — exactly the way production-grade engineering should be. Appreciate your time. Until next time 👋.

Install the Latest PostgreSQL (psql 18) on Ubuntu 24.04 (Noble)

Munir Ahmad — Mon, 03 Nov 2025 17:40:16 +0000

Why I Wrote This

While setting up my development environment on Ubuntu 24.04 (Noble Numbat), I noticed the default PostgreSQL version in Ubuntu’s repository was outdated.

So I decided to document the clean, official way to install the latest PostgreSQL (v18) — straight from the PostgreSQL Apt repository.

If you’ve ever run into issues like:

“No cluster suitable as a default target”
or old versions like PostgreSQL 14 or 15 being installed instead of the latest then this guide will help you start fresh.

Step-by-Step Guide to Installing PostgreSQL 18

Step 1 — Update and Upgrade Your System

sudo apt update && sudo apt upgrade -y

Step 2 — Check Your Ubuntu Codename:

PostgreSQL’s official repo depends on your Ubuntu version codename.

Run the following to check yours:

. /etc/os-release
echo $VERSION_CODENAME

For Ubuntu 24.04, the output should be:

noble

Step 3 — Install Required Packages

We’ll install curl, ca-certificates, and postgresql-common:

sudo apt install -y curl ca-certificates postgresql-common

Step 4 — Add the PostgreSQL Apt Repository

Run the following command to automatically add the official PostgreSQL repository:

sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh

Step 5 — Update Package Lists & Install PostgreSQL 18

sudo apt update
sudo apt install -y postgresql-18

When prompted during installation:

Type Y to confirm.
If you see a purple configuration screen like this 👇 choose “install the package maintainer’s version” (This ensures a clean, default setup for PostgreSQL 18.)

Step 7 — Verify Installation

Check the installed version you should see:

psql --version
psql (PostgreSQL) 18.x

That’s it! You’ve successfully installed and verified PostgreSQL 18 on Ubuntu 24.04 (Noble).

Your system is now running the latest, officially supported PostgreSQL version, ready for use in production or local development.If you encounter any issues, check the PostgreSQL service logs with:

sudo journalctl -u postgresql

Otherwise — you’re all set to start building with PostgreSQL 18.