Zero trust

How Alpacon applies zero trust in practice, and how it differs from traditional SSH.

What is zero trust?

Zero trust is a security model based on the principle “never trust, always verify”. It doesn’t distinguish between internal and external networks: every access is verified, every time.

Limitations of traditional SSH

Security risks

Port 22 exposed to the internet

• Constant bot scans for SSH daemons (thousands per day)
• Automated brute force attempts
• Zero-day vulnerabilities in the SSH daemon
• Attack surface remains even with fail2ban and firewalls

Standing keys with full access

• SSH keys are all-or-nothing
• Read-only work still requires full access
• A leaked key gives an attacker complete, persistent control
• No built-in way to scope or time-limit access

Operational pain points

Key rotation nightmare

• 10 servers means 10 keys to manage
• Each repository needs its own copy of secrets
• Rotation means touching every server and repo
• No centralized view

No centralized audit trail

• Logs scattered across servers
• SSH logs show IP addresses, not who or which workflow
• Hard to answer “who deployed last Tuesday at 3pm?”

How Alpacon applies zero trust

Connect as yourself, not as a shared key

There are no SSH keys to distribute or leak. You authenticate with your Alpacon (IAM) identity, and file ownership, sudo, and the audit trail all resolve to you. Remove someone from IAM and their access goes away everywhere.

No standing access

Access is granted through a work session: you request the servers, tools, and time window you need, an admin approves it, and it expires on its own. Nothing stays open after the work is done, so there’s no standing credential to steal. See How Alpacon works.

No exposed ports

Servers open no inbound ports. The Alpamon agent makes an outbound connection to Alpacon, so there’s no SSH port to scan and no brute force to attempt.

• The server initiates the outbound connection
• No inbound ports on the server
• Not discoverable from the internet

Least privilege, including for automation

A work session is scoped to specific servers and tools. For automation, you issue a scoped token instead of a shared key. A token carries an access control list, so you limit exactly which scopes or commands it can use, and even if it leaks, only its permitted actions work. You revoke it in one place. See Tokens and Service tokens.

Verified at decision points

MFA confirms a person is present when it matters (a sensitive action, or a lapsed verification window), not on every command. See How Alpacon works.

A complete audit trail

Every session is recorded on a single timeline: commands, file transfers, sudo grants, and terminal recordings, plus an AI risk analysis after it ends. See Audit.

Security benefits summary