Owning a mail server should mean owning the door to it. On a cripta.to server, shell access (SSH) is separate from your mailbox login, and you decide who holds a key to it. By default that’s two parties — you and our support team — but you can narrow it to just you, at any time, from the dashboard.
This post explains exactly who can log in, how to add your own key, and how to remove our access when you want the box to answer to you alone.
Two kinds of key
There are two independent ways to have shell access to your server:
- The cripta.to support key. By default we place our own admin key
(
remote-admin@cripta.to) on the box. It exists so our team can log in to diagnose problems and help when something goes wrong. It’s on unless you turn it off. - Your own keys. You can authorize your own SSH public keys so you can log in
as
root. These are entirely yours; we never see the private half.
The two are independent. Turning ours off doesn’t touch yours, and adding yours doesn’t require turning ours off. You choose the combination you’re comfortable with.
Adding your own key
From your dashboard, open a running server’s SSH keys screen and paste an SSH public key (a name is optional). It’s authorized for root login. A few
things worth knowing:
- Only the public key ever leaves your machine. The private half stays with you. Anyone asking for a private key is either mistaken or hostile.
- Changes apply within about 15 minutes. Your server checks for updates on a schedule rather than instantly, so give it a few minutes to take effect.
- You can remove a key at any time, and you’ll see each key’s fingerprint so you can confirm which is which.
If you don’t already have a key pair, cripta.to has an in-browser SSH key generator that creates one locally in your browser — nothing is transmitted. Once your key is added, see Connect to your mail server over SSH for step-by-step login instructions on macOS, Windows, and Linux.
Switching off our access
When you want the server to be reachable by you and no one else, disable support access. From the dashboard, open the server’s actions menu (⋯) and choose Disable support access. This removes the cripta.to admin key from the box, so our team can no longer log in. As with any access change, it applies on the next scheduled check — up to about 15 minutes.
You can re-enable it in one click whenever you’d like our help again. It’s a switch, not a one-way door.
The one rule: add your own key first
There’s a single important consequence to keep straight. Support access and your own keys are the only two ways in. If you disable ours and you haven’t added a key of your own, then no one can SSH into the server — including you.
So the safe order is always:
- Add your own SSH key.
- Confirm you can log in with it.
- Then disable support access.
On a BYO (assisted) server — one running in your own hosting account — we don’t just warn you: we won’t remove our key until you’ve proven you can get in. When you choose Disable support access, the dashboard sends you to verify first. You add your key, we drop a one-time token onto the server, and you read it back over SSH to show the login works. Only then does the disable go through. It’s the same check we run before handing a server over when you cancel, and it exists because on a box we don’t otherwise control, removing our key with no working login is unrecoverable.
On a managed server (running in cripta.to’s hosting account) the dashboard warns you but lets you proceed, because a lockout is always recoverable: re-enable support access from the dashboard to restore a way in. If you disable ours with no key of your own on an assisted server and still manage to lose access, your hosting provider’s console is the last resort.
Losing your only key on a server with support access already off is the one genuinely unrecoverable state — treat your private key accordingly: keep it backed up, and protect it with a passphrase.
Why it’s built this way
Support access defaults to on because most people want help available when a mail server misbehaves, and off-by-default would strand anyone who hit trouble on day one. But it’s yours to revoke, precisely because “you own the server” should be literally true.
The end state is simple and honest: the list of who can log in contains exactly the keys you decided on. Keep ours for a safety net, or switch it off and hold the only key yourself. Either way, the door is yours.