If you've ever managed SSH access for a team, you know the drill: generate keys, copy them to servers, remember which key goes where, revoke access when someone leaves, and pray nobody puts their private key in a public GitHub repo. It's tedious, error-prone, and doesn't scale.
We built Pangolin to make private access simple and secure - whether you're accessing a web app through your browser or connecting directly to private resources. Today, we're taking that mission to the terminal.
Pangolin 1.16.0 introduces native SSH support with certificate-based authentication and PAM integration. No more managing SSH keys. No more ssh-copy-id. Just use your Pangolin identity to connect to any server, and let Pangolin handle the rest.
SSH the way it should be
Here's what SSH access looks like with the Pangolin CLI and any resource alias:
1$ pangolin ssh vm-01.prod.example.com23Welcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.14.0-1010-aws aarch64)45 System information as of Sat Feb 28 01:41:10 UTC 202667 System load: 0.0 Temperature: -273.1 C8 Usage of /: 23.9% of 29.95GB Processes: 1559 Memory usage: 48% Users logged in: 010 Swap usage: 0% IPv4 address for ens5: 10.30.0.2121112Last login: Mon Feb 23 19:36:15 2026 from 10.30.2.19913p-owen@vm-01.prod.example.com:~$14
Behind the scenes, Pangolin:
- Generates a temporary key pair on your machine
- Sends the public key to Pangolin's server along with your identity
- Verifies you have access to that resource
- Signs your public key with your organization's certificate authority
- Establishes the SSH connection using the short-lived certificate
The certificate is valid for just 5 minutes - long enough to establish a connection, short enough to limit blast radius if something goes wrong. Once you're connected, your session can stay open as long as you need it.
You need to be connected to the Pangolin network to make the SSH connection.
Identity-based access control
SSH access in Pangolin follows the same zero-trust principles as everything else in the platform. You create a private resource for each server you want to SSH into, grant access to specific users or roles, and ensure TCP port 22 is allowed in the resource's port restrictions.
No access granted on the resource? No SSH session. It's that simple.
This means your SSH access policies live in the same place as your web app and private network policies. One dashboard, one source of truth, one audit log.
Just-in-time user provisioning
Here's where it gets interesting. When you SSH into a server through Pangolin, we don't just authenticate you - we provision your user account on the fly.
Pangolin derives your username from your identity (the part before the @), creates a home directory, and sets up the account with the right permissions before your SSH session even starts. If the username is already taken in your organization, we add a numeric suffix to keep it unique.
This happens automatically through PAM (Privileged Access Management), the same authentication framework your Linux server already uses. No manual account creation and you dont need to pre-provisioning users across dozens of servers. User settings can be configured on a per-role basis:
Built into Newt, your site connector
The magic happens in Newt, Pangolin's site connector that already handles your private network connectivity. When you run Newt with the --auth-daemon flag, it becomes an SSH authentication daemon for the host it runs on:
1$ sudo newt --id <id> --secret <secret> --endpoint <endpoint> --auth-daemon2
Then configure your SSH server to trust Pangolin's certificate authority and use Newt to resolve principals. Add these lines to /etc/ssh/sshd_config:
1TrustedUserCAKeys /etc/ssh/ca.pem2AuthorizedPrincipalsCommand /usr/local/bin/newt auth-daemon principals --username %u3AuthorizedPrincipalsCommandUser root4
Restart SSH, and you're done. Your server now accepts certificate-based authentication from any Pangolin user with access to that resource. The OpenSSH server will check with Newt to see if the user is authorized, and if so, allow the connection.
For more complex setups: external auth daemons
If you need to SSH into multiple servers that don't run Newt themselves, Pangolin supports an external auth daemon architecture. One host runs Newt as a bastion, and each target server runs Pangolin's auth daemon. Newt proxies SSH connections through to the target servers, and the auth daemon handles user provisioning and certificate validation.
This is perfect for environments where you have a jump host or bastion pattern. We won't dive into the details here, but if that's your setup, check out our SSH documentation for the full configuration guide.
Short-lived certificates, long-term security
Traditional SSH key management is a mess because keys are long-lived. Someone generates a key, copies it to a server, and it sits there forever - or until someone remembers to remove it. With Pangolin's certificate-based approach, keys are ephemeral by design.
Each certificate is valid for just 5 minutes from the moment it's issued. That's enough time to establish your connection, but not enough time for an attacker to do much with a compromised certificate. And because certificates are signed by your organization's CA, you can revoke access instantly by removing a user from the resource - no need to hunt down keys scattered across servers.
Give it a try!
Pangolin 1.16.0 is live today. If you're tired of managing SSH keys and want terminal access that's as secure and simple as the rest of your Pangolin setup, this release is for you.
You can get started with a free account on Pangolin Cloud, or self-host with the Open Source Community or Enterprise Editions.
Also in this release:
- Add list of accessible private resources to non-admin/member landing page
- Add server side pagination, filter, sort, and search to major tables
- Add support pathname in logo URL for branding
- Add delete account from profile
- Add improved user prompt dialogs to installer script
- Other minor bug fixes and visual enhancements


