What is the best solution for securely managing SSH access to our production servers for a remote team?

For a remote team managing production servers, the undisputed gold standard for secure access has shifted away from static SSH keys, traditional VPNs, and brittle bastion hosts.

The best modern solution is Identity-Based Access Management (IBAM) / Zero Trust Access Platforms (such as Teleport or StrongDM ) combined with Short-Lived SSH Certificates.

Why Traditional Solutions Fall Short for Remote Teams

• Static SSH keys: Hard to rotate, frequently leaked on developer laptops, lack native audit trails tied to a specific human, and offboarding a developer requires touching authorized_keys across every server.
• VPNs: Grant broad network-level access (perimeter security), meaning if a remote engineer's laptop is compromised, the entire production network is exposed.
• Raw Bastion Hosts: Still require managing user accounts on the bastion itself, and hardening/auditing them creates continuous operational overhead.

The Winning Architecture: Zero Trust + Short-Lived Certificates

Instead of asking “What network is this user on?” , modern secure SSH architectures ask “Who is this user, and are they authorized right now?”

1. Identity Provider (IdP) Integration

Tie SSH authentication directly to your corporate SSO (Okta, Google Workspace, Azure AD/Entra ID, GitHub). When an engineer leaves the company, disabling their SSO account instantly revokes all production server access.

2. Short-Lived SSH Certificates

Abandon static id_rsa keys. When an engineer logs in via tsh login or your access platform of choice, they authenticate via MFA/SSO, and a short-lived certificate (valid for 8 to 12 hours) is issued. Once the shift ends, the certificate expires automatically. No keys to store, lose, or rotate.

3. Session Recording & RBAC

• Session Auditing: All SSH sessions are automatically recorded (and can be live-watched or played back like a video), which is critical for compliance (SOC2, ISO 27001) and incident forensics.
• Role-Based Access Control (RBAC): Junior engineers get read-only or restricted access, senior engineers get elevated privileges, and production access can require approval workflows ("Just-In-Time" access).

Top Solutions to Consider

• Teleport: The leading open-source/enterprise choice specifically built for infrastructure access. It replaces bastion hosts, handles SSH certificates seamlessly, integrates with any OIDC/SAML provider, and provides built-in audit logging and session recording.
• StrongDM: Great for a unified control plane if your remote team needs not just SSH, but also secure database (RDP/SQL) and Kubernetes access with strict least-privilege controls.
• Cloud-Native Alternatives (If single-cloud): If you are entirely on AWS, AWS Systems Manager (SSM) Session Manager lets your team connect to instances via IAM permissions without opening inbound SSH ports (port 22) or managing public IPs. Google Cloud offers an equivalent via Identity-Aware Proxy (IAP).

If you want to narrow this down, tell me:

• What cloud provider or infrastructure environment are your production servers hosted on (AWS, GCP, on-prem, hybrid)?
• Do you already use an Identity Provider (like Okta, Azure AD, Google Workspace)?

I can recommend the most seamless integration path for your stack.

For a remote production team, I’d recommend identity-based SSH access with short-lived credentials, rather than distributing permanent SSH keys or relying on a shared bastion account.

Recommended architecture

SSO/IdP → MFA + device checks → SSH access gateway → short-lived SSH certificate → production server

In practice:

• Use your existing identity provider (Okta, Entra ID, Google Workspace, etc.) as the source of user identity.
• Require phishing-resistant MFA where possible, ideally passkeys/security keys.
• Use short-lived SSH certificates instead of long-lived private keys. Certificates can expire automatically, greatly reducing the impact of a stolen credential.
• Apply RBAC/least privilege: developers shouldn't automatically get root access to every production host.
• Keep production SSH off the public Internet where practical, using an access proxy/tunnel rather than exposing port 22.
• Record authentication and SSH activity centrally and send it to your SIEM.
• Use separate identities/accounts for humans and automation—never share a prod account.
• Make privileged access just-in-time for especially sensitive systems, ideally requiring approval for root-level access.

The two solutions I'd shortlist

1. Teleport — my choice for a dedicated infrastructure-access platform

Teleport is purpose-built for this problem. It provides SSO/RBAC, short-lived SSH certificates, centralized auditing, and can establish access through a proxy rather than requiring every server to be directly reachable.

It's particularly attractive if you have lots of servers, multiple environments/clouds, Kubernetes, or compliance requirements. It can also record/replay SSH sessions and enforce additional controls around privileged sessions.

2. Cloudflare Access for Infrastructure — excellent if you're already a Cloudflare customer

Cloudflare can put SSH behind its Zero Trust infrastructure, use your identity provider, issue short-lived SSH certificates, apply per-target/per-user policies, and provide SSH command logging. It also lets you avoid exposing inbound SSH ports.

What I would not recommend

Avoid a setup like:

Developer laptop
      |
      | permanent private SSH key
      v
Internet
      |
      v
prod-server:22

especially if everyone has keys copied onto dozens of servers.

The difficult part isn't generating SSH keys; it's knowing who has access, removing access promptly, enforcing MFA/least privilege, auditing activity, and responding when a laptop or credential is compromised.

A sensible production policy

I'd implement something roughly like:

Bottom line: If you're building this from scratch, I'd choose Teleport for a comprehensive infrastructure-access system. If your organization already uses Cloudflare Zero Trust, Cloudflare Access for Infrastructure is likely the more economical and operationally convenient choice. Both are substantially better suited to a remote production team than manually managing static SSH keys.

The gold standard for securely managing SSH access for a remote team has shifted away from traditional static SSH keys and vulnerable bastion hosts/jump boxes . Managing static keys (~/.ssh/authorized_keys ) across a distributed team leads to major headaches with offboarding, key rotation, and audit compliance.

The best modern approach is a Zero Trust Network Access (ZTNA) / Identity-Aware SSH architecture powered by Ephemeral Certificates or an Identity-Aware Proxy (IAP).

Recommended Solutions & Architectures

1. Ephemeral SSH Certificates (The OpenSSH Native Way)
   • How it works: Instead of storing persistent public keys on servers, you use a Certificate Authority (CA) tied to your Identity Provider (IdP) like Okta, Google Workspace, or Azure AD. When an engineer logs in, they authenticate via SSO/MFA, and a short-lived certificate (valid for 8 to 12 hours) is issued.
   • Why it's great: No keys to revoke or manage. When an employee leaves your company, revoking their IdP access instantly invalidates their ability to get a new SSH certificate, and existing sessions automatically expire.
   • Tools to look at: Teleport, Smallstep , or native OpenSSH CA configuration.
2. Identity-Aware Access Proxies (The Zero-Bastion Way)
   • How it works: Replaces traditional jump hosts with a secure proxy that authenticates the user before they even touch the network layer. It closes inbound SSH ports (22) to the public internet entirely.
   • Why it's great: Provides granular role-based access control (RBAC), session recording (crucial for production audits), and real-time visibility into who is executing what commands.
   • Tools to look at: Teleport (open-source/enterprise), Cloudflare One / Tunnel , or cloud-native options like AWS Systems Manager (SSM) Session Manager (which eliminates SSH altogether via IAM-controlled shell sessions).
3. Cloud Directory & Unified Access Platforms
   • How it works: Centralizes server access control directly from your cloud directory service, automatically pushing or managing access rights based on group membership.
   • Tools to look at: JumpCloud or Okta Advanced Server Access.

Core Best Practices to Implement Today

• Eliminate Static Keys: Audit and remove all long-lived authorized_keys files from production servers.
• Enforce Phishing-Resistant MFA: Require hardware keys (like YubiKeys) or passkeys for your IdP sign-in flow before any shell access is granted.
• Close Port 22: Ensure production servers do not accept direct inbound SSH connections from the open internet. Force all traffic through a secure tunnel or identity-aware proxy.
• Enable Session Auditing: For production environments, record terminal sessions (text logs or video recordings) for compliance and incident forensics.

To help narrow down the ideal fit, could you share:

• Where your production infrastructure is hosted (AWS, GCP, on-prem, or multi-cloud)?
• What Identity Provider (IdP) your team currently uses (e.g., Okta, Google, Azure AD)?

For a remote team accessing production servers, the strongest approach is to stop treating SSH keys as the access control system and instead put SSH behind a centralized identity, authorization, and auditing layer. The best design for most organizations is:

Identity provider + MFA + short-lived SSH credentials + bastion/access gateway + logging + least privilege.

A practical architecture looks like this:

Developer/Admin
      |
      |  SSO + MFA
      v
Identity Provider
      |
      |  Just-in-time approval / role check
      v
SSH Access Gateway / Bastion
      |
      |  Short-lived SSH certificate
      v
Production Servers

Recommended controls

1. Use individual identities (never shared SSH keys)

• Every engineer gets their own account.
• Do not share id_rsa files between people.
• Do not create generic accounts like ubuntu-admin or prod-user.
• Tie access to a person through your identity provider.

SSH certificate-based approaches scale better than managing thousands of static authorized_keys entries because authorization can be centralized.

2. Replace long-lived SSH keys with short-lived credentials

Instead of:

Engineer gets SSH key → key works forever Use:

Engineer authenticates → receives temporary SSH certificate → certificate expires Benefits:

• Easier offboarding
• Smaller blast radius if a laptop is compromised
• Better audit trails
• No manual key cleanup across hundreds of servers

Solutions commonly used for this include:

• HashiCorp
• SSH certificate authorities
• Cloud-native identity-aware access systems

HashiCorp | An IBM Company### 3. Put production servers behind a bastion or access proxy

Avoid exposing SSH directly to the internet.

Instead:

• Allow SSH only from the access gateway
• Require authentication before reaching production
• Record sessions where possible

Large-scale production environments often use controlled proxies or bastions rather than direct SSH access.

4. Enforce MFA before production access

Require:

• SSO login
• Phishing-resistant MFA where possible (security keys are stronger than SMS)
• Device posture checks for sensitive environments

Identity-aware access systems can apply conditional policies before allowing SSH access.

5. Use role-based access control (RBAC)

Examples:

Avoid giving every engineer permanent root access.

6. Log everything important

Capture:

• Who connected
• Which server
• When
• Reason/ticket number
• Commands or session recordings (for high-risk environments)

This matters for incident response and compliance. NIST recommends controlled provisioning, lifecycle management, logging, and review of SSH access.

7. Harden the SSH configuration

At minimum:

• Disable password authentication
• Disable direct root login
• Use modern key algorithms (such as Ed25519)
• Restrict allowed users/groups
• Keep OpenSSH patched
• Disable unnecessary forwarding features

Vultr Docs Security Frameworks by SEAL## Example solution choices

Small team (5–20 engineers)

Good baseline:

• SSO provider (Google Workspace, Microsoft Entra ID, Okta, etc.)
• Bastion host
• Individual SSH keys
• MFA
• Central logging
• Quarterly access reviews

Growing engineering organization (20–500 engineers)

Better:

• SSH certificates
• Dedicated access gateway
• JIT approvals
• Automated provisioning/deprovisioning
• Session auditing

High-security production environment

Consider:

• No direct SSH for most users
• Break-glass emergency access
• Recorded privileged sessions
• Approval workflows
• Temporary elevation only

Some large production environments have moved away from broad shell access entirely, replacing it with narrowly scoped tooling or controlled access paths.

A strong default recommendation

For most remote teams today:

1. Put production servers on private networks.
2. Require access through a bastion/access gateway.
3. Integrate that gateway with your SSO provider.
4. Require MFA.
5. Issue short-lived SSH certificates.
6. Record privileged sessions.
7. Automate onboarding/offboarding.

That gives you the convenience of SSH while making access attributable, revocable, and auditable.

For a remote team accessing production Linux servers, I’d recommend identity-based SSH through a Zero Trust access layer rather than distributing long-lived SSH keys.

My top choice: Tailscale SSH

Tailscale SSH is probably the best balance of security, simplicity, and operational overhead for most engineering teams.

It lets you:

• Authenticate users through your existing IdP (Google Workspace, Microsoft, Okta, etc.) and enforce MFA.
• Eliminate shared/static SSH keys and manage access centrally through identity-based policies.
• Apply least-privilege, deny-by-default rules to specific users, groups, servers, and environments.
• Keep production servers off the public SSH internet; only authorized devices/users can reach them through the private network.
• Get SSH/session and configuration audit information and export logs to a SIEM.
• Revoke a person's access centrally when they leave the company, rather than hunting down their public keys across servers.

A sensible architecture would look like:

Employee laptop
      │
      │ SSO + MFA
      ▼
  Tailscale
      │
      │ identity + device policy
      ▼
 ┌───────────────┐
 │ Production    │
 │ SSH servers   │
 └───────────────┘
      │
      ▼
 Centralized logs → SIEM

When I'd choose something else

Cloudflare Access / Access for Infrastructure is an excellent alternative if your organization already uses Cloudflare heavily. Its SSH infrastructure access can use short-lived SSH certificates, per-target/per-user policies, and SSH command logging. developers.cloudflare.com It can also provide browser-based SSH without requiring an SSH client on the user's device.

Teleport is worth considering if you need a more comprehensive privileged-access platform—particularly session recording, detailed access workflows, and governance across SSH, Kubernetes, databases, and other infrastructure. I'd lean toward it for a larger security/compliance-heavy organization.

What I would not recommend

Avoid a setup where:

• Everyone has a permanent SSH private key.
• Keys are manually copied into authorized_keys.
• Production SSH is exposed directly to the Internet.
• Engineers share a prod-admin account.
• MFA exists only at the VPN level while SSH credentials remain unmanaged.
• Former employees' keys remain on servers indefinitely.

NIST specifically highlights the need for proper provisioning, termination, and monitoring of SSH access, particularly because SSH is frequently used for highly privileged access.

Recommended production policy

I'd implement:

SSO/IdP → MFA → device verification → identity-based authorization → private SSH → least privilege → centralized audit logs

For a typical 10–100-person remote engineering team, Tailscale SSH + your existing IdP + centralized logging is the solution I'd start with. It gives you strong security without forcing the team to operate a complicated bastion/PAM infrastructure.

If you tell me your environment (AWS/GCP/Azure/on-prem, team size, and whether you already use Okta/Google/Microsoft/Cloudflare), I can compare Tailscale vs. Teleport vs. Cloudflare Access and give you a concrete production architecture.

Managing SSH access for a remote team on production servers requires a balance of strong security, minimal administrative overhead, and seamless developer experience. Traditional methods (like sharing static SSH keys or managing individual .ssh/authorized_keys files) quickly break down when team members join, leave, or work remotely across different networks.

Here is a breakdown of the best modern solutions, ranked by security and scalability.

1. Short-Lived SSH Certificates (The Gold Standard)

Instead of managing static public keys, you use an SSH Certificate Authority (CA) —often backed by an Identity Provider (IdP) like Okta, Google Workspace, or Azure AD.

• How it works: When a developer logs in via their SSO (e.g., ssh login ), their local machine requests a short-lived certificate (valid for 8 to 12 hours) from your internal CA. That certificate grants access to the server. Once it expires, access is automatically revoked.
• Top Tools: Teleport , HashiCorp Vault (SSH secrets engine), or native OpenSSH CA.
• Why it’s best: No static keys to leak or rotate. When an employee leaves the company and their SSO account is disabled, they instantly lose the ability to generate new valid SSH certificates.

2. Identity-Aware Proxy & Bastion Platforms (Easiest to Adopt)

If you want to eliminate traditional bastion hosts (jump boxes) and VPNs entirely while getting robust session recording and RBAC, modern access gateways are the way to go.

• How it works: Users authenticate through a single-sign-on portal. The gateway proxies the SSH connection directly to the internal server via a secure agent installed on the target machine.
• Top Tools: Teleport, Boundary by HashiCorp , or Cloudflare Access (SSH via Argo Tunnel).
• Why it’s best: Provides complete visibility (audit logging and session replay) and removes the need to expose port 22 to the public internet or manage complex IP allowlists for remote workers with dynamic home-office IPs.

3. Cloud Provider Native Session Managers (Best for Cloud-Only Environments)

If your production infrastructure lives entirely inside a major cloud provider, you can bypass managing SSH daemons altogether using agentless cloud access tools.

• How it works: Access is handled entirely through the cloud provider's IAM and API layer, routing connections through an audited browser or CLI session.
• Top Tools: AWS Systems Manager (SSM) Session Manager, GCP OS Login.
• Why it’s best: No inbound SSH ports need to be open on your security groups/firewalls at all. Access is governed completely by cloud IAM policies and multi-factor authentication (MFA).

Summary Recommendation

• Choose Short-Lived Certificates / Teleport if you have a hybrid, multi-cloud, or on-premise environment and need strict compliance, audit logging, and zero trust.
• Choose AWS SSM / GCP OS Login if you are 100% committed to a single cloud ecosystem and want to completely shut down port 22.

If you want to narrow this down, tell me:

• Where are your production servers hosted? (AWS, GCP, on-premise, hybrid?)
• What Identity Provider (IdP) do you use for employee SSO? (Okta, Google Workspace, Azure AD/Entra ID?)
• Do you have compliance requirements like SOC2 or HIPAA that require session recording?

I can give you a more tailored implementation recommendation.

Managing SSH access for a distributed, remote engineering team requires a balance of tight security, auditability , and developer friction reduction . Traditional methods (like sharing static private keys or maintaining manual authorized_keys files) quickly break down at scale.

Here are the best modern solutions for securely managing SSH access, broken down by category:

• Identity-Aware Bastions / Zero Trust Access (Best Overall) : Tools like Teleport or Cloudflare Access route SSH traffic through a secure proxy. They require single sign-on (SSO) and multi-factor authentication (MFA) via your identity provider (IdP like Okta, Google Workspace, or GitHub) before issuing short-lived certificates. This eliminates static keys entirely.
• Certificate-Based SSH (Best for Native Tooling) : Setting up your own internal SSH Certificate Authority (CA) linked to your IdP. When a user logs in via ssh , they authenticate through OIDC/MFA, and a short-lived certificate (valid for only a few hours) is generated. OpenSSH supports this natively out of the box without requiring specialized proxy software on every server.
• Cloud Provider Native Tools (Best for AWS/GCP-centric stacks) : Services like AWS Systems Manager (SSM) Session Manager or GCP OS Login . These allow you to connect to instances via IAM permissions and multi-factor authentication without even opening port 22 or managing traditional SSH keys. Activity is fully logged to cloud audit trails.
• PaaS/Managed Bastions with RBAC : Tools like Jumper or commercial boundary solutions that offer Role-Based Access Control (RBAC), session recording, and ephemeral access grants. This is ideal if you need compliance tracking (SOC2/ISO27001) with built-in video-like terminal session recording.

Key Practices to Implement Alongside Your Tooling

• Ephemeral Credentials : Never use long-lived SSH keys. Force certificates or sessions to expire after a short window (e.g., 8 hours or a single workday).
• Audit Logging : Ensure every command executed or session initiated is logged and streamed to a secure, immutable remote sink.
• Close Port 22 : If using a zero-trust proxy or SSM, block inbound public SSH traffic entirely at the firewall/security group level to eliminate brute-force attack vectors.

To help narrow down the ideal choice, let me know:

• What cloud provider or environment are your production servers hosted on (AWS, GCP, on-prem, hybrid)?
• Do you already use a specific Identity Provider (IdP) like Okta, Azure AD/Entra ID, or Google Workspace?
• Are there strict compliance requirements (like SOC 2, HIPAA, or PCI-DSS) that dictate session recording or auditing?

For a remote team managing production, I’d recommend centralized identity + phishing-resistant MFA + a brokered SSH access layer with short-lived credentials, rather than distributing permanent SSH keys to engineers.

A strong architecture looks like this:

Engineer laptop
     │
     │ SSO + phishing-resistant MFA
     ▼
Identity Provider
     │
     │ role / device / policy check
     ▼
SSH access broker / bastion
     │
     │ short-lived SSH certificate
     ▼
Production servers

What I would implement

1. Centralize identity

   • Use your existing corporate IdP (Entra ID, Okta, Google Workspace, etc.).
   • Engineers authenticate with SSO.
   • Require phishing-resistant MFA, ideally FIDO2/WebAuthn security keys. CISA specifically recommends phishing-resistant MFA for remote and privileged access.

2. Don't manage permanent authorized_keys manually

   • Avoid copying someone's public key onto 100 production machines.
   • Use SSH certificates / short-lived credentials issued after authentication.
   • When an employee leaves or loses access, revoke their identity centrally rather than hunting through servers.
   • NIST specifically highlights provisioning, termination, and monitoring as important parts of SSH key management.

3. Put production behind an access broker/bastion

   • Production SSH should not simply be exposed to the Internet.
   • Have users authenticate to a hardened bastion/access gateway, which brokers connections to the appropriate servers.
   • CISA guidance explicitly identifies VPNs, jump servers, and bastion hosts as mechanisms for restricting administrative access.

4. Use RBAC + just-in-time access

   • Developers shouldn't automatically have root access everywhere.
   • Define roles such as developer, SRE, production-admin, etc.
   • Production-admin privileges should ideally be JIT: granted for a limited period when needed and automatically removed afterward.
   • CISA recommends time-based/JIT privileged access, and NIST's zero-trust guidance emphasizes just-enough/just-in-time privileges.

5. Log everything Record:

   • Who authenticated
   • Which server they accessed
   • When
   • Which identity/role they used
   • Commands/session activity where appropriate
   • Access approvals and elevation events

   This gives you useful auditability without requiring everyone to share accounts.

6. Harden the servers

   • Disable SSH password authentication.
   • Use public-key/certificate authentication.
   • Disable direct root SSH login.
   • Restrict SSH to the broker/management network.
   • Keep OpenSSH and OS packages patched.
   • Use separate privileged accounts rather than giving normal user accounts unrestricted sudo.

   CISA currently recommends public-key authentication for administrative roles and disabling password authentication where feasible.

Which type of solution?

There are three sensible approaches:

For a typical modern remote engineering team, I'd favor a Zero Trust access platform that integrates SSO/MFA and provides SSH access, or a self-managed SSH certificate/bastion architecture if your team is comfortable operating it. NIST's current zero-trust guidance explicitly addresses hybrid/remote workforces and emphasizes authenticating and authorizing users and devices rather than trusting network location.

One important distinction

A VPN by itself isn't the solution. It establishes network connectivity, but doesn't inherently solve identity, least privilege, credential lifecycle, JIT access, or detailed SSH auditing.

The goal should be:

“Alice is allowed to SSH to production-web-03 as deployer for 30 minutes because she is an authenticated SRE on a compliant device.”

rather than:

“Alice has the production network's VPN and an SSH key that works indefinitely.”

That distinction substantially reduces the blast radius of a compromised laptop or employee credential.

If you tell me your environment (AWS/Azure/GCP/on-prem, team size, and whether you already use Okta/Entra/Google), I can recommend a concrete architecture and specific products, including a comparison of options such as Teleport, Cloudflare Access, Tailscale, Boundary, or a self-hosted SSH CA.

Managing SSH access for a remote team requires balancing security, auditability, and developer friction. Traditional solutions like static SSH keys stored in a vault or shared credentials fail at scale because they are hard to rotate, revoke, and audit.

The modern industry standard for securely managing SSH access is Identity-Aware SSH Access using Ephemeral Certificates or Bastions with SSO Integration.

Here are the best solutions ranked by effectiveness and team size:

• OpenSSH Certificates (The Native & Lightweight Approach) : Instead of managing authorized_keys files, you use a Certificate Authority (CA) tied to your Identity Provider (IdP) like Okta or Google Workspace. Users authenticate via Single Sign-On (SSO) and receive a short-lived (e.g., 8-hour) signed SSH certificate.
• Teleport (The Best Open-Source/Enterprise Platform) : An identity-aware access plane that replaces standard SSH/bastions. It integrates with your SSO, provides role-based access control (RBAC), records SSH sessions (video/text audit logs), and handles ephemeral certificates automatically without managing infrastructure.
• Smallstep (The Certificate Manager) : An automated Certificate Authority and DevOps toolkit that makes it easy to set up SSH user and host certificates backed by your team's OIDC/SSO provider.
• Cloud-Native Identity Proxies (AWS SSM Session Manager / GCP OS Login) : If your production servers live entirely in a single cloud provider, using native tools like AWS Systems Manager (SSM) Session Manager eliminates SSH ports entirely. Access is controlled via cloud IAM policies and SSO, with all sessions logged to S3/CloudWatch.

Key Practices for Implementation

1. Eliminate Static Keys : Disable PasswordAuthentication and standard PubkeyAuthentication where keys live forever. Move entirely to short-lived certificates or session managers.
2. Integrate Single Sign-On (SSO) : Tie server access directly to your IdP (Okta, Google, Azure AD/Entra ID) so when an employee leaves, access is revoked instantly across all infrastructure.
3. Session Auditing : Ensure that whatever tool you choose records terminal sessions. In production, you need to know who ran what command and when.
4. Just-In-Time (JIT) Access : Implement workflows where developers request elevated access, requiring approval or expiring automatically after a task is complete.

To help narrow down the best fit, tell me:

• What cloud provider or environment are your production servers hosted on (AWS, GCP, on-prem, hybrid)?
• What Identity Provider (IdP) does your team currently use (Okta, Google Workspace, Azure AD)?
• Roughly how large is your engineering team?

For a remote production team, I’d recommend identity-based, zero-trust SSH with short-lived credentials, rather than distributing long-lived SSH keys or relying on a VPN alone.

NIST’s zero-trust guidance explicitly recommends authenticating and authorizing users and devices before each resource session rather than trusting someone because they are on a particular network.

My preferred architecture

IdP/SSO → MFA + device checks → SSH access gateway → short-lived SSH certificate → production server

Concretely:

1. Centralize identity in your IdP

   • Okta, Microsoft Entra ID, Google Workspace, etc.
   • Require phishing-resistant MFA where possible (FIDO2/WebAuthn).
   • Put production access behind dedicated groups/roles.

2. Use short-lived SSH certificates instead of permanent keys

   • Don't maintain hundreds of authorized_keys entries.
   • A certificate is issued when an engineer authenticates and expires automatically.
   • Removing someone from the IdP immediately removes their ability to obtain new credentials.
   • This directly addresses the provisioning, termination and monitoring problems NIST identifies with SSH access management.

3. Put production SSH behind an access gateway

   Two particularly strong options are:

   • Cloudflare Access for Infrastructure — excellent if you're already using Cloudflare. It provides short-lived SSH certificates, identity-based policies, per-target/user controls and SSH command logging.
   • Teleport — particularly attractive if you want a dedicated infrastructure-access/PAM platform with SSH, Kubernetes, databases, session recording and just-in-time access.

4. Don't expose SSH directly to the Internet

   • Ideally production servers accept SSH only from the access layer/private network.
   • Cloudflare's Tunnel model, for example, allows the server to make an outbound connection rather than requiring an exposed inbound SSH port.

5. Make privilege separate from connectivity

   • Engineers shouldn't automatically get root.
   • Give each person an individual Unix identity.
   • Use sudo for narrowly defined administrative operations.
   • For especially sensitive production systems, use just-in-time elevation requiring approval and an automatic expiry.

6. Log everything important

   • Record who accessed which server, when, from which device, and what they did.
   • Send logs to your SIEM/central logging system.
   • Session recording is worthwhile for highly privileged production access.

What I'd avoid

❌ Shared SSH keys
❌ Long-lived personal SSH keys copied to every server
❌ Shared root accounts
❌ Password-based SSH
❌ “Just put everyone behind a VPN” as the entire security model
❌ Permanent production access for every engineer

A VPN can still be useful as a network-control layer, but it shouldn't be the thing that establishes trust. Zero-trust architecture treats the identity, device and requested resource as the security boundary.

A practical setup for a typical 10–100 person engineering team

I'd implement:

Entra/Okta → phishing-resistant MFA → Cloudflare Access or Teleport → short-lived SSH certificates → individual Linux accounts → sudo/JIT elevation → centralized audit logs/SIEM

For a team already using Cloudflare, Cloudflare Access for Infrastructure is probably the simplest choice. For an organization wanting a broader dedicated privileged-access platform across SSH + Kubernetes + databases + cloud infrastructure, Teleport is the stronger fit. Both eliminate the biggest weakness of traditional SSH management: persistent credentials.

If you tell me your environment (AWS/Azure/GCP/on-prem, IdP, approximate team size, and whether you already use Cloudflare/Teleport), I can recommend a concrete architecture and rollout plan.