Connect to your mail server over SSH

Shell access to a cripta.to server is by SSH key, not a password. Once you’ve added your public key to the server (from the dashboard’s SSH keys screen, or via the in-browser SSH key generator), you use the matching private key to log in. This post walks through exactly how, on each operating system — and through the two or three errors nearly everyone hits the first time.

Throughout, we assume the private key file you downloaded is named cripta_ssh and your server is mail.yourdomain.com. Substitute your own hostname (it’s shown on the server’s card in the dashboard). You always log in as root.

The private key is a secret. Anyone who holds it can log into your server. Keep the file somewhere safe, never email it or paste it into a chat, and only ever share the public half (.pub).

macOS

macOS ships with OpenSSH, so there’s nothing to install — just Terminal.

1. Move the key into your SSH folder and lock its permissions. SSH refuses to use a private key that other users on the machine could read, so the chmod step is not optional:

   mkdir -p ~/.ssh
   mv ~/Downloads/cripta_ssh ~/.ssh/cripta_ssh
   chmod 600 ~/.ssh/cripta_ssh

2. Connect:

   ssh -i ~/.ssh/cripta_ssh root@mail.yourdomain.com

3. Optional — stop typing -i every time. Add a host entry to ~/.ssh/config:

   Host mail.yourdomain.com
     User root
     IdentityFile ~/.ssh/cripta_ssh

   Now ssh mail.yourdomain.com is enough.

Linux

Identical to macOS — OpenSSH is either preinstalled or one package away (apt install openssh-client, dnf install openssh-clients, …).

1. Move and lock down the key:

   mkdir -p ~/.ssh
   mv ~/Downloads/cripta_ssh ~/.ssh/cripta_ssh
   chmod 600 ~/.ssh/cripta_ssh

2. Connect:

   ssh -i ~/.ssh/cripta_ssh root@mail.yourdomain.com

3. Optional ~/.ssh/config entry:

   Host mail.yourdomain.com
     User root
     IdentityFile ~/.ssh/cripta_ssh

Windows

Windows 10 and 11 include the OpenSSH client, so you can do everything from PowerShell — no PuTTY required.

1. Move the key into your SSH folder:

   mkdir "$HOME.ssh" -Force
   Move-Item "$HOMEDownloadscripta_ssh" "$HOME.sshcripta_ssh"

2. Restrict its permissions. OpenSSH on Windows enforces this too — the file must be readable only by your account:

   icacls "$HOME.sshcripta_ssh" /inheritance:r /grant:r "$($env:USERNAME):R"

3. Connect:

   ssh -i "$HOME.sshcripta_ssh" root@mail.yourdomain.com

If you’d rather use PuTTY, convert cripta_ssh to a .ppk with PuTTYgen (Load the file, then Save private key) and point PuTTY at the .ppk under Connection → SSH → Auth.

Save yourself an -i flag with ssh-agent

If you connect often, load the key into your SSH agent once and every ssh command finds it automatically:

ssh-add ~/.ssh/cripta_ssh      # macOS / Linux

On Windows, start the agent once (Start-Service ssh-agent) then ssh-add "$HOME\.ssh\cripta_ssh".

When it doesn’t work

Permission denied (publickey) — the server didn’t accept your key. Usually one of:

• The public key hasn’t landed on the server yet. Changes apply on the box’s next scheduled check, so allow up to ~15 minutes after adding it.
• You pointed -i at the wrong file, or at the .pub (public) file instead of the private one. -i wants the private key — the file without .pub.
• You’re logging in as the wrong user. It’s always root@….

Unprotected private key file / bad permissions — the key is readable by others. Re-run the chmod 600 (macOS/Linux) or the icacls command (Windows) from the steps above.

Host key verification failed / “REMOTE HOST IDENTIFICATION HAS CHANGED” — you’re seeing a different server fingerprint than last time. This is expected if the server was rebuilt at the same hostname; remove the stale entry and reconnect:

ssh-keygen -R mail.yourdomain.com

If you didn’t expect the server to change, stop and check why before typing yes — this is exactly the warning that protects you from connecting to an impostor.

Losing the key

There’s no “reset” for a private key — it was only ever on your machine. If you lose it, generate a new keypair, add the new public key from the dashboard, and remove the old one. As long as cripta.to support access is still enabled (or you have another working key), you’re never locked out; that’s the whole point of keeping a second way in until you’ve proven the first one works.