SSH certificate access and host-based access control - both zero-infrastructure, both enforced locally on each host.
Dirless issues short-lived SSH certificates to your users so they can SSH into
any enrolled host without managing authorized_keys files. There is
no certificate authority to run - Dirless generates a per-account SSH CA
automatically, and the agent distributes it to every enrolled host.
dirless-connect is the end-user CLI. Each user installs it once on their
local machine (not on the servers).
curl -Lo /usr/local/bin/dirless-connect \
https://github.com/dirless/dirless-connect/releases/latest/download/dirless-connect-x86_64
chmod +x /usr/local/bin/dirless-connect
The user runs dirless-connect ssh register once. It prompts for the
account name (from the portal), their email address, and their Linux username. It
then generates keypairs locally and sends a magic link to their email.
dirless-connect ssh register
After clicking the link in the email, registration is complete. The user can now
run dirless-connect ssh login to obtain their first certificate.
To obtain or renew a certificate, the user runs:
dirless-connect ssh loginThis performs a challenge-response exchange with the Dirless control plane - the server encrypts a nonce to the user's age public key, the client decrypts it locally and sends back the plaintext, and the server returns a signed certificate. The plaintext nonce is never stored.
If the existing certificate is still valid for more than an hour,
ssh login skips the exchange and exits immediately - safe to run
in a shell profile or cron job. How often a renewal is actually needed depends
on the certificate TTL, which is configurable per account in the portal.
Add the following to ~/.ssh/config so SSH picks up the certificate
automatically:
Host *
IdentityFile ~/.config/dirless-connect/ssh/id_ed25519
CertificateFile ~/.config/dirless-connect/ssh/id_ed25519-cert.pubThen SSH into any enrolled host as usual:
ssh alice@your-server.example.comdirless-connect ssh login more frequently.
By default, every user in your directory can resolve on every enrolled host. Host-based access control lets you restrict which groups are allowed on which hosts - so your database administrators don't appear as valid Linux users on your web servers, and vice versa.
Enforcement happens locally on each host at sync time. A user not authorized for a given host is simply absent from the local identity snapshot - they cannot log in even if the control plane is unreachable.
You configure two things in the portal:
| Setting | What it does |
|---|---|
| Enable host enforcement | Turns on group-based filtering. Without this flag, all host-group rules are ignored. |
| Host-group rules | A list of group → hostname pairs. A user must be a member of at least one authorized group to be present on that host. |
The agent receives these rules as part of its authorization config from the backend.
On each sync, it filters the identity snapshot using the host's own hostname
(hostname command output). Users not authorized for this host are
excluded from the local database - NSS lookups, getent, and SSH
authentication all see only the users that belong here.
Suppose you have two groups - backend-team and ops-team -
and three hosts:
| Group | Allowed on host |
|---|---|
backend-team |
backend-prod |
backend-team |
backend-staging |
ops-team |
bastion |
With these rules active, a member of backend-team can log into
backend-prod and backend-staging, but does not exist as
a Linux user on bastion at all. A member of ops-team
can only log into bastion.
Log into the Dirless portal, go to Directory → Access Control, enable host enforcement, and add your host-group rules. Changes propagate to all enrolled hosts within one sync cycle (60 seconds by default).