feat: short living certificates

[OleksandrKucherenko]

Pre-flight checks

• I have searched the existing issues to ensure this feature has not already been requested.

Is your feature request related to a problem?

For secured environments it is common that each user need to request for a short living certificate (1h, 1d) and it is used for accessing a specific resource.

for that purpose used ROOT certificate, which is used for creating child-certificates. So between client and server shared ROOT certificate, but on configuration level allows only usage of the short-living certificates.

Describe the Solution You'd Like

have and option which instruct neossh how to obtain the SSH key (ask keyvault, or create a child certificate)

Alternatives Considered

No response

Additional Context

No response

[OleksandrKucherenko]

Problem

Security-sensitive environments commonly avoid permanent SSH credentials.

Instead of registering a user's long-lived SSH public key on every server, SSH servers trust an SSH Certificate Authority (CA). Users authenticate to a certificate service and receive a short-lived SSH user certificate, typically valid for a period such as 1 hour or 1 day.

OpenSSH certificates are different from X.509/TLS certificates. The SSH server directly trusts one or more SSH CA public keys through TrustedUserCAKeys. The CA private key remains inside a secure signing service such as HashiCorp Vault, an HSM/KMS-backed service, or a corporate certificate broker.

A typical authentication flow is:

1. User selects an SSH server in NeoSSH.

2. NeoSSH obtains or generates an SSH key pair.

3. NeoSSH authenticates the user to an SSH certificate provider.

4. NeoSSH sends the SSH public key to the provider.

5. The provider verifies the user's identity and authorization.

6. The provider signs the public key using the SSH CA private key and
   returns a short-lived OpenSSH user certificate.

7. NeoSSH invokes native OpenSSH using:

   IdentityFile   = private key
   CertificateFile = signed short-lived certificate

8. The SSH server verifies:
   - certificate signature against its trusted CA public key;
   - certificate validity period;
   - allowed principals;
   - certificate restrictions/options;
   - possession of the corresponding private key.

9. When the certificate expires, a new certificate must be requested
   before another SSH authentication can succeed.

Example server configuration:

PubkeyAuthentication yes
TrustedUserCAKeys /etc/ssh/user-ca.pub

For environments requiring certificate-only SSH authentication, normal persistent user keys can additionally be disabled, for example by not using AuthorizedKeysFile/AuthorizedKeysCommand for authentication.

A certificate may contain authorization information such as:

validity:
    1 hour

principals:
    ubuntu
    deploy

key-id:
    alice@example.com

critical options:
    source-address=10.0.0.0/8

extensions:
    permit-pty

The SSH CA private key must never be distributed to NeoSSH clients or SSH servers. NeoSSH should only request certificates from a signing service.

Requested NeoSSH functionality

Introduce support for dynamic SSH credential providers.

Before establishing a connection, NeoSSH should be able to:

1. Determine whether the selected server requires a short-lived certificate.
2. Check whether a currently cached certificate is still valid.
3. Obtain or generate the corresponding SSH key pair if necessary.
4. Authenticate with the configured certificate provider.
5. Submit the SSH public key for signing.
6. Receive the short-lived OpenSSH certificate.
7. Store it temporarily with the appropriate lifecycle/security controls.
8. Launch native OpenSSH using the private key and certificate.
9. Re-request the certificate automatically after expiration.

Possible providers could include:

- HashiCorp Vault SSH CA
- external command/script
- corporate HTTP/OIDC certificate service
- KMS/HSM-backed signing service
- other provider plugins

A generic provider interface is preferable to implementing a dependency on one particular CA product.

The basic provider contract only needs to resolve:

request:
    host
    ssh user/principal
    SSH public key
    requested TTL

response:
    OpenSSH user certificate
    valid-after
    valid-before

This would allow NeoSSH to support environments where no permanent SSH user credential is sufficient for access and a fresh short-lived certificate must be acquired before connecting.

[OleksandrKucherenko]

Yes. I would make this a first-class part of the proposal: NeoSSH should support both external certificate providers and a built-in lightweight CA provider.

For a young company, requiring Vault/Key Vault/Smallstep on day one creates exactly the kind of infrastructure dependency the feature is supposed to remove.

A practical maturity path could be:

Stage 1                       Stage 2                       Stage 3
────────────────────────────────────────────────────────────────────────

NeoSSH built-in CA            NeoSSH signing service       Vault / Smallstep /
+ SOPS + age                  on management host           Cloud KMS / HSM

1-5 admins                    small company                mature environment

encrypted CA key              centralized CA key           managed CA key
in private repo               automated issuing            policy / audit / MFA

        same OpenSSH certificate protocol throughout

Small-company setup

I would structure it approximately like this:

infra/
├── .mise.toml
├── .sops.yaml
├── ssh/
│   ├── user-ca.pub
│   ├── user-ca.key.sops
│   └── policy.yaml
└── mise-tasks/
    ├── ssh-ca-init
    ├── ssh-ca-install
    └── ssh-cert-issue

user-ca.pub is not sensitive and can live directly in Git.

The CA private key:

user-ca.key.sops

is encrypted with SOPS for one or several age recipients.

That works well with the current tooling. SOPS supports age recipients and encrypted repository files, while mise can pin/install sops and age and has direct SOPS/age integration. Mise's native SOPS/age features are currently marked experimental, so NeoSSH should probably support ordinary sops CLI integration as well rather than depend specifically on mise's experimental interface. ([mise-en-place]1)

For example:

[tools]
sops = "latest"
age = "latest"

[tasks."ssh:certificate"]
run = "neossh cert issue"

Then onboarding can become:

mise install
mise run ssh:certificate prod-server

instead of installing and configuring an entire Vault infrastructure.

But there is one critical security distinction

I would not give every developer an age identity capable of decrypting:

user-ca.key.sops

If Alice can decrypt the CA private key, Alice can mint:

principal = root
TTL       = 10 years
KeyId     = ceo@example.com

and the SSH servers cannot distinguish that from a legitimate certificate.

So:

              age recipient
                    │
                    ▼
        ┌──────────────────────┐
        │ SSH CA private key   │
        │ encrypted by SOPS    │
        └──────────────────────┘
                    ▲
                    │
          ADMIN/SIGNER access only


developers
    │
    │ public keys
    ▼
NeoSSH built-in signer
    │
    │ short-lived cert
    ▼
SSH servers

The CA decryption identities belong to signers/admins, not ordinary SSH users.

That remains true even for a 3-person startup.

NeoSSH built-in provider

This suggests a provider architecture like:

CertificateProvider
    │
    ├── builtin-ca
    │      ├── sops-age
    │      ├── raw encrypted key
    │      └── OS credential store
    │
    ├── command
    │
    ├── vault
    │
    ├── smallstep
    │
    └── HTTP/OIDC

And builtin-ca could support two modes.

Local signer mode

neossh
   │
   ├─ decrypt CA key
   ├─ sign certificate
   ├─ discard CA key from memory
   └─ start ssh

Suitable for founders/admins and very small teams.

Remote NeoSSH signer mode

Developer NeoSSH
      │
      │ public key + requested target
      ▼
neossh-ca
small VM / server
      │
      ├─ policy
      ├─ SOPS/age CA
      ├─ audit
      └─ signing
      │
      ▼
short-lived cert

That is already surprisingly close to a lightweight Vault SSH secrets engine, but with perhaps 5% of the operational complexity.

NeoSSH doesn't even need ssh-keygen for signing

Because NeoSSH is Go, the built-in implementation can keep the decrypted CA private key in memory instead of writing a plaintext temporary file and invoking:

ssh-keygen -s ...

golang.org/x/crypto/ssh directly supports OpenSSH certificate creation through ssh.Certificate and Certificate.SignCert(), including principals, validity ranges, certificate types, permissions and critical options. ([Go Packages]2)

Conceptually:

cert := &ssh.Certificate{
    Key:             userPublicKey,
    CertType:        ssh.UserCert,
    KeyId:           "alice@example.com",
    ValidPrincipals: []string{"ubuntu"},
    ValidAfter:      now - 300,
    ValidBefore:     now + 3600,
}

cert.SignCert(rand.Reader, caSigner)

Then only this leaves the process:

ssh-ed25519-cert-v01@openssh.com AAAA...

The decrypted CA private key never needs to touch disk.

Policy should be separate from the CA secret

I'd also add a simple declarative policy:

version: 1

defaults:
  ttl: 1h
  maxTTL: 8h

users:
  alice@example.com:
    principals:
      - developer
      - ubuntu

  bob@example.com:
    principals:
      - developer

targets:
  production:
    allowedPrincipals:
      - developer
    maxTTL: 1h

  administration:
    allowedPrincipals:
      - admin
    maxTTL: 15m

Then certificate generation is not:

sign whatever user asks for

but:

request
   │
   ▼
policy evaluation
   │
   ├── principal allowed?
   ├── target allowed?
   ├── TTL <= maxTTL?
   ├── source constraints?
   └── extensions allowed?
   │
   ▼
sign

That makes migration to Vault/Smallstep later much easier because the conceptual model remains identical.

Where mise + SOPS + age fits particularly well

I think your combination is strong because each tool has a very narrow responsibility:

mise
    tool versions
    installation
    tasks / commands
    developer bootstrap

SOPS
    structured encrypted configuration
    multiple recipients
    Git-friendly encrypted files

age
    simple developer/admin encryption identities

OpenSSH
    certificate format
    authentication
    server-side trust

NeoSSH
    orchestration
    policy
    certificate lifecycle
    UX

Mise itself can also decrypt SOPS/age-backed secrets, including multiple age identities, although its current SOPS functionality is documented as experimental. ([mise-en-place]1)

One thing I would avoid is passing the CA private key as an environment variable through mise. Mise's documentation explicitly notes that decrypted values can be exposed by commands such as mise env; environment variables are also generally a poorer place for a CA signing key than process memory. ([mise-en-place]1)

Better:

SOPS encrypted bytes
        ↓
NeoSSH decrypts
        ↓
memory
        ↓
Go ssh.Signer
        ↓
certificate
        ↓
zero/release sensitive buffer

I would therefore change the issue architecture to

NeoSSH short-lived certificate providers

                       ┌─ Built-in CA
                       │    ├─ SOPS + age
                       │    ├─ local signer
                       │    └─ NeoSSH signer service
                       │
NeoSSH ─ Provider ─────┼─ HashiCorp Vault
                       ├─ Smallstep
                       ├─ external command
                       └─ custom HTTP/OIDC

This makes the feature much more compelling. It is no longer merely “NeoSSH integrates with a corporate SSH CA”. It becomes:

NeoSSH can take a company from ordinary permanent SSH keys to short-lived certificate-based SSH authentication without requiring additional infrastructure, while retaining a migration path to Vault/KMS/HSM-backed signing later.

That is probably the stronger framing for #109.