Skip to main content

SSH Accounts

Everything on nixomatic.com works without an account. into.nixomatic.com is where an account comes from: an SSH server that hands you one and shows you what it will hold. There is nothing to install and no password — the SSH key you already have is the credential.

Creating an account​

Connect with an empty username, so SSH does not send your local login name, on port 2003 — the year Nix was created:

ssh -l '' -p 2003 into.nixomatic.com

The server creates an account, prints its id — a UUID — along with the two ways back into it, and closes the connection.

The account id is worth keeping, but it is not a secret to guard: the key that created the account is what holds it, and the id alone opens nothing.

Coming back​

Two ways, and both land on the same account:

  • Anonymously again. ssh -l '' -p 2003 into.nixomatic.com looks up the key you present. If it already holds an account, you get that account and its id back rather than a second one — connecting twice never leaves you with two accounts.
  • By id. ssh -p 2003 <account-id>@into.nixomatic.com opens the interactive interface, and ssh -T -p 2003 <account-id>@into.nixomatic.com <command> runs a single command and exits.

Naming an account only works from the key that created it. A connection presenting a different key closes without an explanation — that feedback would be for whoever is guessing, not for you. An id that belongs to no account is told how to create one.

Only public-key authentication is accepted; password and keyboard-interactive attempts are refused. The username must be either empty or an account id, so a stray local login name is rejected outright rather than quietly creating something.

What an account holds​

The interactive interface lists four sections — substituters, packages, flake settings, and domains — navigated with j/k (or Ctrl-n/Ctrl-p), Ctrl-a/Ctrl-e for first and last, and q to quit. The same four are subcommands of the non-interactive CLI, which takes --json for machine-readable output:

ssh -T -p 2003 <account-id>@into.nixomatic.com packages list --json
{"forced":[],"defaults":[]}

These four sections are a preview of what an account will configure, not settings that take effect yet. Nothing said to them is stored: a packages add reports the package it was given and forgets it, and a list always comes back empty. Flakes served from nixomatic.com are identical whether or not you have an account. What is real today is the account itself — its id, and the key that holds it.

Coming soon​

Personalising what you are served is what comes next. An account will apply what it holds to the flakes it answers with — substituters to fetch from, packages present in every shell, flake settings layered on top — so a shell comes out configured without any of it repeated on the command line.

Domains are how that reaches past a single account. A domain added to an account and pointed at nixomatic with a CNAME is served by nixomatic, and some of what the account holds will apply to that whole domain rather than to you alone: a request arriving through that name is answered with the domain's configuration, whoever made it. That is the point — a domain is how a team or a project shares one configuration — but it also means adding a domain is a decision on behalf of everyone who uses it.

All of this is work in progress. Adding a domain and configuring it correctly changes nothing about what is served today; the sections are there so the shape is visible before the behaviour is. Coming soon.

What is recorded​

Two things are counted for each account, alongside the pageviews the websites count: account_created when a key that held no account gets one, and account_accessed each time an existing account is reached (with identified_by saying whether the connection was recognised by its key alone or named the account id). Both carry the account id, the SSH key fingerprint, and the address connected from. Neither is sent anywhere else, and analytics failing is never allowed to fail a connection.