If your network team manages device access by distributing SSH keys, you're already in technical debt. Not "legacy system that works fine" debt. "Every departing engineer could have taken a copy of every device key they ever received" debt.
SSH key management at scale breaks down into predictable stages that every team goes through:
Stage 1: "Just add my public key to authorized_keys on the jumpbox." This works for three engineers across ten devices. Then you get to eleven.
Stage 2: "We need a shared key management system." Someone sets up a script that pushes keys from a central list. It works until someone leaves and you need to rotate all their keys across every device. That's a weekend project.
Stage 3: "We need certificates." Someone reads about SSH CAs and it makes perfect sense. Sign once, trust everywhere. Expire automatically. Principals and extensions for fine-grained control. It's the right solution. Nobody implements it because the infrastructure is complex and the migration from key-based access is painful.
Stage 4: "We have SSH CAs now." This is what happens when the platform handles certificate issuance, signing, and distribution transparently. Engineers connect through the platform, get short-lived certificates, and never manage keys directly. This is where most teams want to be and very few actually are.
The SSH CA Model That Actually Works
The certificate-based approach should look like this from the engineer's perspective: they open their terminal, select a device, and connect. Behind the scenes, the platform requests a short-lived SSH certificate from an internal CA, the CA signs a certificate scoped to the engineer's identity and the target device, and the SSH connection uses that certificate. No key management, no authorized_keys files, no rotation projects.
The certificate should be short-lived. Hours, not months. If an engineer's access is revoked, their existing certificates expire naturally — no forced key rotation across every device. The CA should enforce principal restrictions. An engineer authorized only for the spine layer shouldn't be able to certificate-scoped access to core routers.
What NetStacks Does Here
NetStacks implements the SSH CA pattern at the platform level. The Controller acts as the certificate authority, issuing short-lived certificates scoped to the engineer's identity, role, and authorized device scope. Credentials never leave the server. Engineers authenticate to the Controller, which issues the certificate and proxies the connection.
This means:
- No SSH keys on engineer laptops. Zero. The Controller handles authentication and certificate issuance. Every connection is authenticated, authorized, and audited through the platform. RBAC determines who can connect to which devices, when, and with what privileges. Audit logging captures every session — not just the connection event, but the full session transcript.
When an engineer leaves, you revoke their platform access. Their certificates expire. There are no device-side keys to rotate.
The Multi-Vendor Complication
Here's where the SSH CA gets complicated: every vendor implements SSH differently. IOS-XR has different SSH server behaviors than Juniper, which differs from Arista's EOS, which differs from Linux-based NOSes. Certificate validation, key exchange algorithms, and cipher preferences all vary.
The SSH CA needs to understand these differences. A certificate that works on IOS-XR might fail on Juniper because of different key algorithm expectations. The CA needs to issue certificates that each platform's SSH server will accept. This is invisible to the engineer but critical for the platform.
The Team That Should Adopt This
Any team with more than 10 engineers and more than 50 devices should be on certificate-based SSH access. If you're still using key-based authentication, you're one departing engineer away from a key rotation project that nobody wants to do.
The migration path: keep the SSH CA alongside existing key-based access during the transition. Engineers authenticate through the platform, the CA issues certificates, and the old keys remain as a fallback. Once everyone is using the platform, disable key-based access entirely. Audit the transition. Confirm no device still has engineer keys in authorized_keys.
This is the security model that scales. Not because it's complex, but because it eliminates the thing that makes SSH access unmanageable at scale: the exponential growth of key-device relationships that no one can track or audit.