Zero Trust Server Access: Replacing traditional root SSH access with Tailscale, SSH certificates, and short-lived credentials.

Running a public-facing server in India requires a balance between accessibility and security. Traditional root SSH access—whether protected by a static password or a long-lived key—creates a single point of failure. If that credential is compromised, an attacker gains unrestricted control of the system.

Zero-trust server access removes that implicit trust. By combining Tailscale (a WireGuard-based mesh VPN), SSH certificates issued by a short-lived Certificate Authority (CA), and time-bound credentials, you can enforce “never trust, always verify”. The following sections describe the architecture, required tools, and step-by-step configuration for both Debian/Ubuntu (apt) and AlmaLinux/Rocky/RHEL (dnf) environments.

1. Understanding the Zero-Trust Model for SSH

In a zero-trust setup, every connection is authenticated and authorized on a per-session basis, regardless of network location. The core ideas are:

• Never expose root directly to the Internet. All inbound traffic is routed through a trusted overlay network.
• Use short-lived credentials. Even if a key is stolen, it expires quickly.
• Leverage identity-based access. Permissions are tied to a user’s identity (e.g., an email address or SSO account) rather than a static key.

Integrating Tailscale creates a private, encrypted mesh that only your devices can join. SSH certificates replace the traditional ~/.ssh/id_rsa key pair, allowing you to issue a new certificate for each login session. The result is a dynamic, auditable, and revocable access method.

2. Setting Up Tailscale on Your Server

Tailscale runs on any modern Linux distribution. Installation steps differ slightly between Debian-based and RHEL-based systems.

Debian / Ubuntu (apt)

# Install the official Tailscale repository
curl -fsSL https://tailscale.com/install.sh | sh

# Install the package
apt-get update && apt-get install -y tailscale

# Start and authenticate the node (replace with your auth URL)
tailscale up --authkey=YOUR_TAILSCALE_AUTHKEY

The curl … | sh script adds the Tailscale APT source, installs the daemon, and enables it. tailscale up registers the server to your Tailnet and creates a WireGuard interface (tailscale0) with a stable 100.x.x.x address.

AlmaLinux / Rocky / RHEL (dnf)

# Add the Tailscale repository
curl -fsSL https://tailscale.com/install.sh | sh

# Install the package
dnf install -y tailscale

# Enable and start the service
systemctl enable --now tailscaled

# Authenticate the node
tailscale up --authkey=YOUR_TAILSCALE_AUTHKEY

On RHEL-based systems the daemon is called tailscaled. The --authkey can be generated from the Tailscale admin console and should have an expiration date that matches your security policy.

3. Creating an SSH Certificate Authority (CA)

An SSH CA signs short-lived certificates that clients present during login. The CA’s private key never leaves the signing host (often a bastion or CI runner).

Generate the CA key pair (common to both OS families)

# Create a directory for the CA
mkdir -p /etc/ssh/ca && chmod 700 /etc/ssh/ca

# Generate a 4096-bit RSA key (ed25519 is also an option)
ssh-keygen -t rsa -b 4096 -f /etc/ssh/ca/ssh_ca -N ""

The private key (ssh_ca) stays on the signing host; the public key (ssh_ca.pub) is distributed to every server that should trust certificates signed by this CA.

Distribute the CA public key to your servers

# Append the CA public key to sshd's trusted list
echo "TrustedUserCAKeys /etc/ssh/ca/ssh_ca.pub" >> /etc/ssh/sshd_config

# Reload the SSH daemon
systemctl reload sshd

Now any certificate signed by /etc/ssh/ca/ssh_ca will be accepted for authentication.

4. Issuing Short-Lived SSH Certificates

Certificates are generated on demand, typically by a CI pipeline, a password-less sudo script, or a dedicated signing service. The example below shows a simple local script; adjust the validity period to suit your risk tolerance (e.g., 5–15 minutes).

Certificate signing script (run on the CA host)

#!/bin/bash
# Usage: ./sign_cert.sh user@example.com

USER_ID=$1
if [[ -z "$USER_ID" ]]; then
  echo "Provide a user identifier (e.g., email or username)"
  exit 1
fi

# Create a one-time key pair for the session
ssh-keygen -t ed25519 -f /tmp/${USER_ID}_key -N "" -q

# Sign the public key, valid for 10 minutes
ssh-keygen -s /etc/ssh/ca/ssh_ca \
  -I "${USER_ID}-$(date +%s)" \
  -V +10m \
  -z $(date +%s) \
  -n "${USER_ID}" \
  /tmp/${USER_ID}_key.pub

# Output the private key and certificate
cat /tmp/${USER_ID}_key
echo "-----BEGIN SSH CERTIFICATE-----"
cat /tmp/${USER_ID}_key-cert.pub
echo "-----END SSH CERTIFICATE-----"

The script:

1. Creates a one-time key pair.
2. Signs the public key with the CA, embedding a -V +10m validity window.
3. Prints the private key followed by the certificate, ready for use with an SSH client.

Using the certificate on a client

# Save the output as two files
cat > ~/.ssh/id_ed25519_cert
cat > ~/.ssh/id_ed25519_cert.pub

# Set correct permissions
chmod 600 ~/.ssh/id_ed25519_cert

# Connect via the Tailscale address
ssh -i ~/.ssh/id_ed25519_cert -o CertificateFile=~/.ssh/id_ed25519_cert.pub user@100.x.x.x

The -o CertificateFile option tells SSH to present the certificate alongside the private key. Because the certificate expires after 10 minutes, any compromised key becomes useless after that window.

5. Enforcing Policy: Disallow Direct Root Login and Passwords

With the CA in place, tighten sshd_config to block traditional entry points.

# /etc/ssh/sshd_config additions
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile /dev/null   # Prevent static key files
PermitRootLogin no
AllowUsers alice bob            # Optional: limit to known identities

After editing, reload the daemon:

systemctl reload sshd

Only users presenting a valid, time-bound certificate can log in, and they must do so over the Tailscale network, which already encrypts traffic and restricts access to devices you have explicitly authorized.

6. Automating Credential Distribution for Developers

Running the signing script manually for each login is impractical. Integrate it with a password-less workflow:

• CI/CD pipeline. Store the CA private key in a secret manager (e.g., HashiCorp Vault, AWS Secrets Manager). A pipeline step generates a certificate just before deployment.
• Local helper. Provide a small Go or Python utility that contacts a signed-URL endpoint, fetches a fresh certificate, and stores it in ~/.ssh.
• Windows note. On Windows Server, use OpenSSH with the same -i and -o CertificateFile flags. Only the path syntax changes.

Because the certificates are short-lived, they can be rotated automatically each time a developer pushes code, runs a script, or opens a new terminal session. If a device is lost or a user leaves the organization, revoking the Tailscale auth key or removing the user from the Tailnet instantly stops all future certificate issuance.

Conclusion

Replacing static root SSH access with a zero-trust stack—Tailscale for network isolation, an SSH CA for identity-based certificates, and short-lived credentials for limited exposure—dramatically reduces the attack surface of your Indian VPS or dedicated server. The approach works across Debian/Ubuntu and AlmaLinux/Rocky/RHEL environments, requires only standard system packages, and integrates cleanly with existing CI pipelines.

Implementing this workflow takes a few hours of setup, but the security payoff is ongoing: compromised keys become useless after minutes, and every login is traceable to a specific certificate and Tailscale identity. For teams that manage web applications, APIs, or critical backend services, zero-trust server access is a practical, cost-effective step toward a more resilient infrastructure.