Admin over SSH and CLI

The SSH admin surface is the implemented Everlock control plane today.

It is provided by:

• frontend-ssh
• backend-admin-ssh

This is a line-based admin REPL, not a shell. Commands begin with / and act on Everlock resources such as users, groups, backends, sites, OCI registries, DNS zones and records, and mail domains.

When backend-ai-ssh is enabled, the same session also accepts free-text AI prompts:

• /... remains command input
• plain text becomes AI prompt input
• //... sends a slash-prefixed prompt to the model

Session model

Typical flow:

1. start Everlock with frontend-ssh and backend-admin-ssh
2. connect with ssh
3. authenticate as an Everlock user
4. use slash commands inside the admin session

The session accepts:

• /help
• resource commands such as /users ..., /site ..., /oci ...
• /quit or /exit

Access model

Two command tiers exist today:

• any authenticated user:
  • /help
  • /users list
  • /users grants <login>
  • /groups list
  • /git list
  • /site list
  • /calendar list
  • /contacts list
  • /oci list
  • /dns zones list
  • /dns records list [<zone>]
• access-path governed commands:
  • /dns ... uses ssh/dns/* and ssh/dns/<zone>
• system administrators only:
  • backend enable/disable
  • user and group changes
  • site, OCI, and mail configuration changes

System administrator here means Owner on */*/*.

Command layout

The currently implemented command families are:

• /help
• /users
• /groups
• /git
• /dns
• /site
• /calendar
• /contacts
• /oci
• /mail
• /jobs
• /backends
• /quit
• /exit

Bare scope commands show scope help where implemented:

• /site
• /calendar
• /contacts
• /oci
• /mail
• /git
• /dns

Command reference

Help and session

/help
/quit
/exit

Users

/users list
/users add <login> <password>
/users passwd <login> <password>
/users grant <login> <path> <role>
/users revoke <login> <path>
/users grants <login>

Notes:

• <role> is one of reader, writer, or owner
• <path> is an Everlock access path such as http/site/docs or http/oci/default

Groups

/groups list
/groups add <name>
/groups assign <group> <login>
/groups grant <group> <path> <role>
/groups revoke <group> <path>

Git

/git
/git list
/git create <name>

DNS

/dns
/dns zones list
/dns zones create <zone>
/dns zones delete <zone>
/dns records list
/dns records list <zone>
/dns records create <zone> name=<name> type=<type> value=<value> [ttl=<ttl>]
/dns records set <zone> <name> <type> value=<value> [ttl=<ttl>]
/dns records delete <zone> <name> <type>
/dns reload

Notes:

• /dns zones create <zone> requires Owner on ssh/dns/*
• zone inspection uses Reader on ssh/dns/<zone>
• zone mutation uses Writer on ssh/dns/<zone>
• zone deletion uses Owner on ssh/dns/<zone>
• /dns records list shows effective records and whether they are derived, explicit, or explicit-override

Sites

/site
/site list
/site create <name> [store=<name>] [mode=html|markdown] [auth=public|private] [vhost=<host>]
/site set <name> auth=public|private
/site set <name> mode=html|markdown
/site set <name> vhost=<host>
/site unset <name> vhost=<host>
/site delete <name>

Notes:

• store= defaults to the site name
• mode= defaults to the backend default if omitted at creation time
• auth=public grants Reader to anon on http/site/<name>
• auth=private revokes that anon grant
• multiple vhost= values can be added over time by repeated set

OCI

/oci
/oci list
/oci create <name> [store=<name>] vhost=<host> [vhost=<host>...]
/oci set <name> store=<name>
/oci set <name> vhost=<host> [vhost=<host>...]
/oci unset <name> vhost=<host> [vhost=<host>...]
/oci delete <name>

Notes:

• vhost= is required at creation time
• store= defaults to the registry name if omitted at creation time

Calendar

/calendar
/calendar list
/calendar create <name> [store=<name>] vhost=<host> [vhost=<host>...]
/calendar set <name> store=<name>
/calendar set <name> vhost=<host> [vhost=<host>...]
/calendar unset <name> vhost=<host> [vhost=<host>...]
/calendar delete <name>

Notes:

• vhost= is required at creation time
• store= defaults to the instance name if omitted at creation time
• calendars and events inside the instance are managed through CalDAV, not the admin shell

Contacts

/contacts
/contacts list
/contacts create <name> [store=<name>] vhost=<host> [vhost=<host>...]
/contacts set <name> store=<name>
/contacts set <name> vhost=<host> [vhost=<host>...]
/contacts unset <name> vhost=<host> [vhost=<host>...]
/contacts delete <name>

Notes:

• vhost= is required at creation time
• store= defaults to the instance name if omitted at creation time

Mail

/mail
/mail domains list
/mail domains list <domain>
/mail domains create <domain> [submission=on|off] [auth=on|off] [dkim=on|off] [hostname=<name>]
/mail domains set <domain> <key=value>...
/mail domains delete <domain>
/mail mailboxes list
/mail mailboxes list <domain>
/mail mailboxes list <domain> <mailbox>
/mail rules list

Currently documented mail domain settings:

• submission=on|off
• auth=on|off
• dkim=on|off
• hostname=<name>

Creation supports the same keys as set, so you can create a domain with its intended submission and DKIM settings in one command.

TLS visibility:

• /mail domains list includes the derived SMTP host plus TLS status and expiry summary
• /mail domains list <domain> shows the derived mail.<domain> hostname, certificate source and status, expiry and renewal timestamps, and the last ACME error when present

Jobs

/jobs
/jobs list
/jobs run <kind>
/jobs show <id>

Backends

/backends
/backends list
/backends enable <name> [<name>...]
/backends disable <name> [<name>...]

Known backend names currently include:

• ai-ssh
• git-ssh
• image-http
• dns-dns
• admin-ssh
• admin-http
• site-http
• mail-smtp
• calendar-http
• contacts-http
• oci-http
• oauth-http

Argument styles

Two argument styles are currently used.

Positional arguments

Examples:

/users add alice secret123
/users grant alice http/site/docs reader
/groups assign editors alice
/git create project-docs

key=value arguments

Examples:

/site create docs vhost=docs.example.com auth=private
/site set docs vhost=docs.internal.example.com
/oci create main vhost=registry.example.com store=everlock-oci-main
/mail domains set example.com submission=on auth=on

Current behavior notes

• site and oci changes currently persist to config files and may require a restart depending on the operation
• mail configuration is persisted in the system store and mail-store metadata
• backend enable/disable changes persist config and trigger restart behavior
• the SSH admin surface is the source of truth for current operator workflows in the public docs