Common use case

Reach a private SSH server without a broad VPN

Keep port 22 private and use normal SSH commands against the server's real private hostname or IP.

Short answer

Run wireztna connect, then use ssh user@private-hostname. Add an effective restricted rule if access must cover only that server on TCP 22.

The problem

SSH access often starts with a public bastion or broad VPN. Both can be valid, but they add exposure or reachability when one private server is enough.

Choose and scope the connection model

Place the server behind a publisher and authorize the operator through a group. The full client installs WireGuard, routes, and split DNS for native SSH behavior.

  1. 1Deploy a publisher that can reach the server's private SSH port.
  2. 2Assign the operator through a group authorized for that publisher.
  3. 3Add an effective restricted AccessRule for the server /32 and TCP 22 when one-server enforcement is required.
  4. 4Run wireztna connect, then SSH to the private hostname or IP and verify its normal host key.

Example access flow

Consumer

Administrator with the full client

Client command

wireztna connect

Private destination

ssh admin@app-03.internal

Authorization boundary

Effective restricted rule: 10.50.1.168/32 and TCP 22

When this pattern fits

  • An administrator or developer needs native SSH to a private server.
  • The device can run the full WireZTNA client.
  • Port 22 must remain unavailable from the internet.
  • Existing SSH keys, MFA, sudo policy, and audit controls should remain in use.

Security boundary and limitations

  • Without an effective restricted rule, full-client reachability follows the publisher CIDRs authorized through the operator's groups.
  • WireZTNA does not replace host-key verification, SSH accounts, user keys, MFA, sudo controls, or command auditing.
  • A privileged SSH session may reach systems available from the server itself, so harden the destination against pivoting.

Frequently asked questions

Do I SSH to localhost?+

No. With the full client, connect to the private hostname or IP. Localhost is used only by the separate wzctl access-pass mode.

Does private DNS work?+

Yes. The full client configures split DNS, so authorized private names can resolve while it is connected.

Can I keep my existing SSH keys?+

Yes. WireZTNA provides network reachability; OpenSSH still verifies the host and authenticates the user with the existing controls.

Put this pattern into practice

→Read the Quick Start →Understand the architecture →Discuss your use case
← All use cases