Hilfe & Dokumentation

Vom ersten Terminalfenster bis zur geprüften Verbindung. Diese Anleitung beschreibt den zur App-Prüfung eingereichten Stand 1.0.0. Die öffentliche Freigabe durch Apple steht noch aus.

Serverdienste einrichten und verstehen

Neu: Anleitungen zu SSH, systemd, Docker, Nginx, Apache, PostgreSQL, MySQL / MariaDB und Redis. Mit Vorbereitung, einzeln kopierbaren Befehlen und den tatsächlichen Servora-Schritten.

Dienste & Anleitungen öffnen

Schnell zum richtigen Abschnitt

• Erste Schritte
• SSH-Schlüssel am Mac erstellen
• Öffentlichen Schlüssel auf dem Server hinterlegen
• Verbindung am Mac testen
• Schlüssel auf iPhone oder iPad importieren
• Serveridentität prüfen
• Geänderte Serveridentität
• Zugang lokal speichern
• Servora im Alltag
• Fehler lösen
• Technische Details

Erste Schritte

Du brauchst Servora auf einem unterstützten Mac, iPhone oder iPad, einen eigenen erreichbaren Server und ein dort eingerichtetes Benutzerkonto. Für die iPhone-/iPad-Version ist iOS beziehungsweise iPadOS 18 oder neuer erforderlich. Der SSH-Dienst muss laufen und über dein Netz erreichbar sein. Im lokalen Netz oder über dein eigenes VPN kann dafür eine interne Adresse reichen. Öffne nicht pauschal alle Firewall-Ports.

SSH verschlüsselt die Verbindung zu deinem Server. Der Port ist die Eingangstür dieses Dienstes; üblich ist 22. Manche Betreiber verwenden einen anderen Port. Hostname/IP, Port und Benutzername erhältst du vom Serverbetreiber. Das ist kein WordPress- oder IONOS-Kundenkonto.

1. Öffne Servora und wähle Server hinzufügen.
2. Vergib einen freien Anzeigenamen, etwa „Buchhaltung“. Er ersetzt nicht die technische Serveradresse.
3. Trage Hostname oder IP ohne https://, SSH-Port und den Serverbenutzernamen ein.
4. Wähle Passwort oder SSH-Key. Beim Passwort ist das Passwort des Serverbenutzers gemeint. Bei SSH-Key benötigst du die private Schlüsseldatei und gegebenenfalls deren eigene Passphrase.
5. Verbinde dich. Prüfe vor Vertrauen & verbinden die angezeigte Serveridentität unabhängig wie unten beschrieben.
6. Nach erfolgreicher Anmeldung zeigt Servora verfügbare Systeminformationen. Du kannst den Server einem lokalen Projekt zuordnen.

SSH-Schlüssel am Mac erstellen

Das Terminal ist eine App, mit der du dem Mac geschriebene Befehle gibst. Du benötigst dafür keine Programmierkenntnisse. Lies jeden Befehl zuerst; drücke erst dann die Eingabetaste. Die folgenden Schritte erzeugen einen neuen Schlüssel auf deinem eigenen Mac. Wir benötigen diesen Schlüssel nicht.

1. Öffne den Finder → Programme → Dienstprogramme → Terminal. Alternativ drücke ⌘ Leertaste, tippe „Terminal“ und drücke Enter.
2. Für die Anzeige des Schlüsselordners kannst du open ~/.ssh verwenden. Ist der Ordner noch nicht vorhanden, kannst du ihn mit dem nächsten Befehl anlegen.
3. Prüfe vor dem Erstellen, ob bereits Dateien servora_ipad oder servora_ipad.pub vorhanden sind. Überschreibe keine vorhandenen Schlüssel. Verwende nötigenfalls einen anderen freien Dateinamen in allen folgenden Beispielen.

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Diese beiden sichtbaren Befehle legen den lokalen Ordner bei Bedarf an und beschränken dessen Zugriff auf deinen Benutzer. Danach erstellst du das Schlüsselpaar:

ssh-keygen -t ed25519 -f ~/.ssh/servora_ipad -C "servora-ipad"

-t ed25519 wählt den unterstützten Schlüsseltyp. -f legt den Dateinamen fest; ~ steht für deinen Benutzerordner. -C ist nur eine wiedererkennbare Beschriftung.

• Enter file in which to save the key: Mit dem oben angegebenen -f ist der Speicherort bereits festgelegt; diese Frage erscheint daher normalerweise nicht. Ohne -f würde das Terminal nach dem Dateinamen fragen.
• Overwrite (y/n)? bedeutet, dass dort schon ein Schlüssel liegt. Antworte n und drücke Enter. Wähle einen anderen Namen und beginne erneut.
• Enter passphrase (empty for no passphrase): Wähle eine eigene, starke Passphrase für diese Schlüsseldatei. Wir empfehlen die Passphrase. Sie ist nicht automatisch dein Mac- oder Serverpasswort. Bewahre sie sicher auf.
• Enter same passphrase again: Gib dieselbe Passphrase zur Bestätigung erneut ein. Bei einer Abweichung wirst du nochmals gefragt.
• Beim Tippen der Passphrase erscheinen keine Punkte oder Zeichen. Das ist normal. Tippe weiter und drücke danach Enter.
• Die Meldungen über gespeicherte Identität, öffentlichen Schlüssel und Fingerprint bestätigen die Erstellung. Den angezeigten Benutzerschlüssel-Fingerprint nicht mit dem Host-Fingerprint des Servers verwechseln.

~/.ssh/servora_ipad.pub ist der öffentliche Schlüssel. Diesen darfst du auf deinem Server hinterlegen oder dessen Administrator geben. Die Endung .pub ist der wichtige Unterschied.

Öffentlichen Schlüssel auf dem Server hinterlegen

Ersetze mein-benutzer und mein-server.de durch deine eigenen Daten. Die Beispiele sind keine realen Servora-Zugänge. Verwende denselben Serverbenutzer, den du später in der App einträgst. Du brauchst bereits einen funktionierenden Zugang oder Unterstützung des Administrators.

ssh-copy-id -i ~/.ssh/servora_ipad.pub mein-benutzer@mein-server.de

Falls der Server beispielsweise Port 2222 nutzt, ergänze vor dem Ziel -p 2222. Bei der ersten Verbindung prüfe den Host-Fingerprint unabhängig. Ein angefordertes Loginpasswort ist das Passwort dieses Serverbenutzers.

Wenn macOS „command not found: ssh-copy-id“ meldet, kannst du stattdessen diese Alternative verwenden:

cat ~/.ssh/servora_ipad.pub | \
ssh mein-benutzer@mein-server.de \
'umask 077; mkdir -p ~/.ssh; touch ~/.ssh/authorized_keys; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys; cat >> ~/.ssh/authorized_keys'

Dieser Befehl sendet ausschließlich die .pub-Datei. Auf dem Server legt er das SSH-Verzeichnis mit Rechten 700 und authorized_keys mit Rechten 600 an beziehungsweise korrigiert deren Rechte. >> hängt den öffentlichen Schlüssel an und überschreibt keine bereits hinterlegten Schlüssel. Bei anderem Port ergänze -p 2222 in der Zeile mit ssh.

Genau diesen Schlüssel am Mac testen

ssh -o IdentitiesOnly=yes \
  -i ~/.ssh/servora_ipad \
  mein-benutzer@mein-server.de

Ersetze wieder Benutzer und Serveradresse. Bei anderem SSH-Port ergänze -p 2222 vor dem Ziel. IdentitiesOnly=yes begrenzt die angebotenen Identitäten auf konfigurierte beziehungsweise explizit gewählte Schlüssel und verhindert, dass beliebige weitere Schlüssel aus dem SSH-Agent angeboten werden. Falls deine persönliche SSH-Konfiguration zusätzliche Identitäten vorgibt, berücksichtige diese beim Test. Eine Schlüssel-Passphrase gehört zur Datei, eine Passwortabfrage für benutzer@server zum Serverkonto.

Für einen eindeutigen Test ohne persönliche SSH-Konfiguration und ohne Passwort-Fallback kannst du folgenden Befehl verwenden. Auch er behält die Host-Key-Prüfung aktiv:

ssh -F /dev/null -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -i ~/.ssh/servora_ipad mein-benutzer@mein-server.de

Wenn du die Server-Eingabeaufforderung siehst, ist die Anmeldung gelungen. Beende die Sitzung mit exit und Enter. Wenn du Servora auf iPhone oder iPad nutzt, übertrage den Schlüssel erst dorthin, wenn die Anmeldung mit ihm funktioniert.

Servora direkt auf dem Mac verwenden

Wenn du Servora auf demselben Mac verwendest, musst du die Schlüsseldatei nicht per AirDrop übertragen. Wähle beim Einrichten des Servers die lokale private Schlüsseldatei aus und gib gegebenenfalls ihre Passphrase ein. Prüfe auch am Mac die Serveridentität, bevor du der Verbindung vertraust. Die folgenden Übertragungsschritte brauchst du nur für ein zusätzliches iPhone oder iPad.

Schlüssel auf iPhone oder iPad importieren

open ~/.ssh

Der Finder öffnet den Schlüsselordner. Verwende einen nur für diesen Zweck erzeugten Schlüssel mit Passphrase und sende ihn ausschließlich an dein eigenes Gerät.

1. Wähle im Finder die Datei servora_ipad aus – nicht servora_ipad.pub.
2. Wähle Teilen → AirDrop und dein eigenes iPhone oder iPad. Beide Geräte müssen sich in der Nähe befinden; WLAN und Bluetooth müssen aktiv sein. Prüfe den Empfänger sorgfältig.
3. Nimm die Datei auf deinem Gerät an. Bei Geräten mit demselben Apple Account erfolgt die Annahme möglicherweise automatisch. Je nach Dateityp und iOS-Version unterscheidet sich der folgende Dialog.
4. Wähle, wenn angeboten, In Dateien sichern bzw. öffne den Teilen-Dialog und sichere die Datei dort. Wähle möglichst Auf meinem iPhone/iPad statt eines Cloudspeichers. Merke dir den Ordner. Falls diese Auswahl nicht angeboten wird, nicht an einen fremden Dienst weiterleiten; prüfe die Datei-App und den Empfangsweg.
5. Öffne Servora → Server hinzufügen. Trage Name, Hostname/IP, Port und Benutzer ein.
6. Wähle SSH-Key und den Import der privaten Schlüsseldatei. Öffne im Dateiauswahldialog den eben gewählten Ordner und wähle servora_ipad.
7. Gib die beim Erstellen gewählte Schlüssel-Passphrase ein. Wähle optional Zugang lokal sicher speichern.
8. Prüfe die Serveridentität wie unten beschrieben und verbinde dich. Die Datei im Dateien-Ordner bleibt nach dem Import eine separate Kopie; behandle sie weiterhin vertraulich.

AirDrop-Hinweise: Apple: AirDrop auf iPhone und iPad verwenden. Sende private Schlüssel nicht unverschlüsselt per Mail oder Chat. Entferne eine zusätzliche Übertragungskopie erst, wenn du den funktionierenden Zugang und eine sichere Wiederherstellungsmöglichkeit geprüft hast.

Host-Fingerprint unabhängig vergleichen

Ein Fingerprint ist eine kurze Prüfsumme des öffentlichen Server-Schlüssels. Beim ersten Kontakt weiß Servora noch nicht, ob die angesprochene Adresse wirklich dein Server ist. Prüfe den vollständigen SHA256:…-Wert und den Schlüsseltyp, bevor du Vertrauen & verbinden wählst.

1. Öffne eine bereits vertrauenswürdige Serverkonsole deines Providers oder frage den Administrator über einen unabhängig bekannten Kontaktweg. Nutze nicht einfach dieselbe noch ungeprüfte Verbindung als Beweis.
2. Auf einem Linux-Server mit ED25519-Host-Key kann der Administrator den folgenden Befehl ausführen. Er liest ausschließlich den öffentlichen Host-Key.
3. Vergleiche den vollständigen SHA256-Fingerprint mit Servora. Kürze den Vergleich nicht auf erste oder letzte Zeichen. Bei einem anderen Host-Key-Typ muss die passende öffentliche Host-Key-Datei geprüft werden.
4. Nur bei Übereinstimmung vertraust du dem Server. Falls der Wert abweicht oder du ihn nicht sicher überprüfen kannst, brich ab und kläre die Ursache.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Dieser Befehl gehört in die vertrauenswürdige Serverkonsole, nicht in das lokale Mac-Terminal. Keine private Datei wie /etc/ssh/ssh_host_ed25519_key auslesen oder verschicken.

Servora meldet eine geänderte Serveridentität

Eine Neuinstallation, bewusst erneuerte SSH-Hostkeys oder ein Providerwechsel können legitime Gründe sein. Ebenso kommen ein falscher Server, eine falsche DNS-Zuordnung, Netzwerkprobleme oder ein Angriff in Betracht. Prüfe erst Serveradresse, Port, angekündigte Änderungen und den neuen Fingerprint über einen unabhängigen, vertrauenswürdigen Weg. Wenn das nicht gelingt, bleibt die Verbindung gesperrt. Bei Unsicherheit hilft dein Serveradministrator.

Zugang lokal sicher speichern

Nur wenn du Zugang lokal sicher speichern aktivierst, legt Servora die verwendeten Zugangsdaten in der lokalen Keychain ab. Der Speicher ist gerätegebunden (ThisDeviceOnly) und nur bei entsperrtem Gerät zugänglich. Servora lädt den Zugang nicht zu Oprivo hoch und synchronisiert ihn nicht über eine Oprivo-Cloud. Importierte Schlüsseldateien liegen dadurch nicht automatisch in der Secure Enclave.

Ohne diese Auswahl sind Passwort, importierter Schlüssel und Passphrase nur für die laufende Einrichtung verfügbar. Beim Verlassen oder Sperren werden temporäre Geheimnisse verworfen. Ein gespeicherter Entwurf enthält nur Serverangaben und Auswahloptionen, keine neuen Passwörter oder privaten Schlüssel. Ein bereits gespeicherter Zugang kann weiterverwendet werden, solange er zur Verbindung passt.

Die lokale App-Sperre ist optional und wird unter Einstellungen → App-Sicherheit eingerichtet. Sie ersetzt keine Serverberechtigung. Sichere auch das Gerät selbst mit einem Gerätecode und halte sein Betriebssystem aktuell.

Servora im Alltag

• Dashboard: Server und letzte Arbeiten öffnen. Ein begonnener Serverentwurf lässt sich über „Server hinzufügen“ wieder aufnehmen. Abbrechen bewahrt seine nicht geheimen Angaben; „Entwurf verwerfen“ entfernt ihn ausdrücklich.
• Projekte: Ein lokales Projekt erstellen, Notizen und Dokumentation darin pflegen. In der Infrastruktur einen bestehenden Server zuordnen oder einen neuen einrichten. Ein Server gehört derzeit höchstens zu einem lokalen Projekt; beim Verschieben die angezeigte Bestätigung lesen.
• Systemzustand: Gespeicherte Server öffnen und verfügbare Systeminformationen abrufen. Die Anzeige beruht auf den zuletzt abgerufenen Daten, nicht auf dauerhafter Hintergrundüberwachung.
• Dienste: Einen eigenen HTTPS-Check anlegen, Server auswählen und erwarteten HTTP-Status, Timeout und Prüfintervall festlegen. Der Check liest Antwort-Header; er prüft nicht den gesamten Anwendungsinhalt. Zugangsdaten gehören weder in die URL noch in deren Abfrageparameter.
• Gespeicherte Ergebnisse: Die Prüfzeit zeigt, von wann ein Ergebnis stammt. Ein alter Wert ist kein Beleg für die aktuelle Erreichbarkeit. Prüfe bei Bedarf erneut.
• Lokaler Arbeitsbereich: Projekte, Notizen und Server bleiben auf diesem Gerät. Eine Neuinstallation oder ein Gerätewechsel ist kein automatischer Oprivo-Cloud-Umzug. Bewahre Wiederherstellungsinformationen sicher und getrennt auf.

Wenn die Verbindung nicht klappt

Permission denied (publickey)

Kontrolliere den Serverbenutzernamen, die ausgewählte private Schlüsseldatei und den dazugehörigen öffentlichen Eintrag in authorized_keys dieses Benutzers. Teste genau den Schlüssel am Mac wie oben. Die .pub-Datei ist kein privater Schlüssel für den Import. Frage den Administrator, wenn der Server eine andere Anmeldemethode verlangt.

Connection refused

Der Zielrechner lehnt den Verbindungsaufbau ab. Prüfe Adresse und SSH-Port sowie über die Serverkonsole, ob der SSH-Dienst läuft. Eine Firewall kann Verbindungen ebenfalls ablehnen. Ändere Regeln nur gezielt für den benötigten Zugang.

Timeout / Zeitüberschreitung

Prüfe Internetzugang, eigenes VPN, Adresse, Port, Serververfügbarkeit und Firewall-/Provider-Regeln. Ein verlorenes Netz oder ein ausgeschalteter Server kann die Ursache sein. Wiederholungen ersetzen diese Prüfung nicht.

Falscher Benutzername oder Port

Verwende den Linux-/Serverbenutzer und den SSH-Port, nicht deinen IONOS-Kundenlogin, die WordPress-Anmeldung oder einen HTTPS-Port. Bei vorkonfigurierten Servern ist der richtige Benutzer oft vom Betriebssystem und Provider abhängig.

Schlüssel abgelehnt oder Format nicht unterstützt

Aktuell werden ED25519-Schlüssel im privaten OpenSSH-Format unterstützt. RSA, PuTTY-PPK, öffentliche .pub-Dateien und zusätzliche Schlüsseltypen sind damit nicht automatisch kompatibel. Prüfe außerdem die unten dokumentierte Verschlüsselung und Größenbegrenzung. Ein bestehender Schlüssel wird nicht automatisch konvertiert.

Falsche Passphrase

Gemeint ist die beim Erstellen dieses privaten Schlüssels gewählte Passphrase, nicht dein Mac-Passwort und nicht das Serverpasswort. Prüfe Tastaturlayout und Groß-/Kleinschreibung. Eine verlorene Passphrase lässt sich nicht aus dem Schlüssel wiederherstellen; verwende einen anderen berechtigten Zugang und richte einen neuen Schlüssel ein.

Host-Key geändert

Nicht blind bestätigen und nicht die Prüfung abschalten. Gehe nach dem Abschnitt „Geänderte Serveridentität“ vor.

HTTPS-Dienstprüfung schlägt fehl

Verwende einen direkt antwortenden öffentlichen HTTPS-Endpunkt mit gültigem Zertifikat. Weiterleitungen, HTTP ohne TLS, Zugangsdaten und Query-Parameter sind nicht zugelassen. Prüfe erwarteten Antwortstatus und ob dein Endpunkt HEAD unterstützt. Lokale HTTPS-Ziele fallen nicht in diesen Check; direkter SSH-Zugang ist davon getrennt.

Bleibt das Problem bestehen, kontaktiere den Support. Sende nur eine bereinigte Fehlermeldung ohne Schlüssel, Passwörter oder Tokens.

Technische Details zum aktuellen Stand

• SSH-Protokoll 2, Passwortauthentifizierung oder ED25519 im Format OPENSSH PRIVATE KEY. Unterstützt sind unverschlüsselte Schlüssel sowie bcrypt mit AES-128-CTR oder AES-256-CTR; bcrypt-Arbeitsfaktor 1–256. Empfehlung: passphrasegeschützter Schlüssel.
• Maximal 65.536 Bytes pro importierter Schlüsseldatei; Passwort und Passphrase maximal 4.096 UTF-8-Bytes. Ein einzelner Schlüssel pro OpenSSH-Datei.
• Standardverbindungsfrist: 25 Sekunden für Aufbau, Anmeldung und Inventar; TCP-Aufbau bis 12 Sekunden. Gesamtausgabe der Inventarabfrage maximal 131.072 Bytes.
• Strenge Host-Key-Prüfung vor der Anmeldung. Erstkontakt braucht bewusste Bestätigung; geänderte Host-Keys werden nicht automatisch angenommen.
• Feste lesende Inventarbefehle für Hostname, Betriebssystem, Kernel, Architektur, Benutzer, Laufzeit, CPU, RAM und Root-Dateisystem. Das Vorhandensein von sudo wird lediglich erkannt; es wird kein sudo ausgeführt und keine Adminberechtigung getestet.
• Keine interaktive Shell, kein Port Forwarding, kein SSH-Agent und keine Eingabe beliebiger Remote-Befehle. Die App bietet keine beliebige Remote-Code-Ausführung.
• HTTPS-Checks: HEAD, keine Cookies oder gespeicherten HTTP-Zugangsdaten, keine Weiterleitungen, normale TLS-Prüfung. Intervalle 60, 300, 900 oder 3.600 Sekunden; Timeout 2–30 Sekunden. Automatische Prüfungen nur bei aktiver und entsperrter App.

Grundlagen: OpenSSH: ssh-keygen · OpenSSH: SSH-Konfiguration. Die oben genannten App-Grenzen stammen aus dem aktuellen Servora-Code; sie sind enger als der Funktionsumfang von OpenSSH insgesamt.