Per SSH mit Ihrem Mailserver verbinden

Der Shell-Zugang zu einem cripta.to-Server erfolgt per SSH-Schlüssel, nicht per Passwort. Sobald Sie Ihren öffentlichen Schlüssel auf dem Server hinterlegt haben (über den Bereich SSH-Schlüssel im Dashboard oder mit dem SSH-Schlüsselgenerator im Browser), melden Sie sich mit dem passenden privaten Schlüssel an. Dieser Beitrag zeigt genau, wie das auf jedem Betriebssystem geht — und behandelt die zwei bis drei Fehler, über die beim ersten Mal fast alle stolpern.

Durchgehend nehmen wir an, dass die heruntergeladene private Schlüsseldatei cripta_ssh heißt und Ihr Server mail.ihredomain.de ist. Ersetzen Sie den Hostnamen durch Ihren eigenen (er steht auf der Serverkarte im Dashboard). Die Anmeldung erfolgt immer als root.

Der private Schlüssel ist ein Geheimnis. Wer ihn besitzt, kann sich an Ihrem Server anmelden. Bewahren Sie die Datei sicher auf, versenden Sie sie nie per E-Mail und fügen Sie sie nie in einen Chat ein — weitergeben dürfen Sie ausschließlich die öffentliche Hälfte (.pub).

macOS

macOS bringt OpenSSH mit, es ist also nichts zu installieren — das Terminal genügt.

1. Verschieben Sie den Schlüssel in Ihren SSH-Ordner und schränken Sie die Rechte ein. SSH weigert sich, einen privaten Schlüssel zu verwenden, den andere Benutzer der Maschine lesen könnten; der chmod-Schritt ist daher nicht optional:

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

2. Verbinden:

   ssh -i ~/.ssh/cripta_ssh root@mail.ihredomain.de

3. Optional — -i nicht jedes Mal tippen. Legen Sie einen Host-Eintrag in ~/.ssh/config an:

   Host mail.ihredomain.de
     User root
     IdentityFile ~/.ssh/cripta_ssh

   Danach genügt ssh mail.ihredomain.de.

Linux

Identisch zu macOS — OpenSSH ist entweder vorinstalliert oder ein Paket entfernt (apt install openssh-client, dnf install openssh-clients, …).

1. Schlüssel verschieben und Rechte einschränken:

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

2. Verbinden:

   ssh -i ~/.ssh/cripta_ssh root@mail.ihredomain.de

3. Optionaler Eintrag in ~/.ssh/config:

   Host mail.ihredomain.de
     User root
     IdentityFile ~/.ssh/cripta_ssh

Windows

Windows 10 und 11 enthalten den OpenSSH-Client, Sie können daher alles in der PowerShell erledigen — PuTTY ist nicht nötig.

1. Schlüssel in Ihren SSH-Ordner verschieben:

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

2. Rechte einschränken. Auch OpenSSH unter Windows prüft das — die Datei darf nur von Ihrem Konto lesbar sein:

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

3. Verbinden:

   ssh -i "$HOME.sshcripta_ssh" root@mail.ihredomain.de

Wenn Sie lieber PuTTY verwenden, wandeln Sie cripta_ssh mit PuTTYgen in eine .ppk-Datei um (Load der Datei, dann Save private key) und verweisen PuTTY unter Connection → SSH → Auth auf die .ppk.

Sparen Sie sich die Option -i mit ssh-agent

Wenn Sie sich häufig verbinden, laden Sie den Schlüssel einmalig in Ihren SSH-Agenten, und jeder ssh-Aufruf findet ihn automatisch:

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

Unter Windows starten Sie den Agenten einmalig (Start-Service ssh-agent) und führen dann ssh-add "$HOME\.ssh\cripta_ssh" aus.

Wenn es nicht funktioniert

Permission denied (publickey) — der Server hat Ihren Schlüssel nicht akzeptiert. Meist aus einem dieser Gründe:

• Der öffentliche Schlüssel ist noch nicht auf dem Server angekommen. Änderungen greifen beim nächsten geplanten Abgleich der Maschine; rechnen Sie daher mit bis zu etwa 15 Minuten nach dem Hinterlegen.
• Sie haben -i auf die falsche Datei gerichtet oder auf die .pub-Datei (öffentlich) statt auf die private. -i erwartet den privaten Schlüssel — die Datei ohne .pub.
• Sie melden sich mit dem falschen Benutzer an. Es ist immer root@….

Unprotected private key file / bad permissions — der Schlüssel ist für andere lesbar. Führen Sie chmod 600 (macOS/Linux) bzw. den icacls-Befehl (Windows) aus den Schritten oben erneut aus.

Host key verification failed / „REMOTE HOST IDENTIFICATION HAS CHANGED“ — Sie sehen einen anderen Server-Fingerabdruck als beim letzten Mal. Das ist erwartbar, wenn der Server unter demselben Hostnamen neu aufgesetzt wurde: Entfernen Sie den veralteten Eintrag und verbinden Sie sich erneut.

ssh-keygen -R mail.ihredomain.de

Falls Sie hingegen nicht mit einem Serverwechsel gerechnet haben, halten Sie inne und prüfen Sie die Ursache, bevor Sie yes eingeben — genau diese Warnung schützt Sie davor, sich mit einem Betrüger zu verbinden.

Wenn der Schlüssel verloren geht

Für einen privaten Schlüssel gibt es kein „Zurücksetzen“ — er lag immer nur auf Ihrer Maschine. Geht er verloren, erzeugen Sie ein neues Schlüsselpaar, hinterlegen den neuen öffentlichen Schlüssel im Dashboard und entfernen den alten. Solange der Support-Zugang von cripta.to noch aktiv ist (oder Sie einen anderen funktionierenden Schlüssel haben), sind Sie nie ausgesperrt — genau darum geht es beim zweiten Zugangsweg, bis der erste nachweislich funktioniert.