AEONHOST / WISSEN

Satisfactory-Serverzugang und Authentifizierung verstehen

Bei einem Satisfactory Dedicated Server sind Adminzugang, Beitrittspasswort und HTTPS-Zertifikatsvertrauen getrennte Dinge: Das Admin Password schützt die Verwaltung, Player Password Protection begrenzt den Beitritt und bei einem selbstsignierten HTTPS-Zertifikat fragt der Spielclient manuell, ob du ihm vertraust. Halte Admin- und Spielerpasswort getrennt und bestätige eine solche Abfrage erst nach Prüfung des Servers.

Aktualisiert am 07.10.2026

Bei einem Satisfactory Dedicated Server sind Adminzugang, Beitrittspasswort und HTTPS-Zertifikatsvertrauen getrennte Dinge: Das Admin Password schützt die Verwaltung, Player Password Protection begrenzt den Beitritt und bei einem selbstsignierten HTTPS-Zertifikat fragt der Spielclient manuell, ob du ihm vertraust. Halte Admin- und Spielerpasswort getrennt und bestätige eine solche Abfrage erst nach Prüfung des Servers.

Server claimen und Passwörter trennen

Starte Satisfactory und öffne im Hauptmenü den Server Manager. Füge dort den Dedicated Server hinzu. Beim ersten Claim vergibst du einen Servernamen und ein Admin Password. Erst danach kannst du im Server Manager ein neues Spiel starten oder einen vorhandenen Spielstand verwalten. Die englischen Oberflächenbegriffe folgen der aktuellen Projektdokumentation; in einer übersetzten Spieloberfläche können sie anders lauten.

Das Admin Password ist für Verwaltungsrechte gedacht. Es erlaubt beispielsweise, Spielstände zu laden, Serveroptionen zu ändern oder ein neues Spiel zu erstellen. Es ist nicht das Passwort, das du an Mitspielende weitergibst. Verwende für die Gruppe stattdessen Player Password Protection. Laut Dedicated-Server-Dokumentation ist dieser Schutz standardmässig ausgeschaltet und lässt sich im selben Server-Manager-Bereich aktivieren. Das Spielerpasswort begrenzt, wer beitreten und Informationen zur laufenden Sitzung sehen kann.

Wenn der Server bereits geclaimt wurde, melde dich mit dem vorhandenen Admin Password an. Ein zweiter Claim ist nicht nötig. Wird das Passwort abgelehnt, prüfe zuerst, ob du gerade das Admin Password oder das separate Spielerpasswort eingibst. Frage bei einer verwalteten Instanz die zuständige Person nach dem Adminzugang; ändere keine Serverdateien auf Verdacht. Die Server-Einstellungsdatei enthält neben Passwörtern auch den Namen und weitere Verbindungsdaten. Sie zu löschen wäre kein gezielter Passwortwechsel.

Teile das Admin Password nicht im Gruppenchat. Wenn du Mitspielende einlädst, gib ihnen nur das Spielerpasswort, sofern Player Password Protection eingeschaltet ist. Bewahre Änderungen an beiden Passwörtern an einem geschützten Ort auf und verwende nicht dasselbe Passwort für weitere Dienste.

Zertifikat und Serveridentität prüfen

Die HTTPS-API des Dedicated Servers verwendet immer TLS. Falls der Betreiber kein eigenes Zertifikat eingerichtet hat, erzeugt der Server ein selbstsigniertes Zertifikat. Beim ersten Kontakt kann der Spielclient deshalb eine Vertrauensabfrage zeigen. Nach deiner Bestätigung merkt sich der Client das Zertifikat für diesen Server. Laut API-Dokumentation bleibt es dort vertraut, bis du es widerrufst oder der Server sein Zertifikat ändert.

Eine solche Abfrage ist eine Vertrauensentscheidung und kein Ersatz für das Admin Password. Adresse und Port helfen dir, die erwartete Instanz zu wählen, beweisen allein aber keine Zertifikatsidentität. Die Projektdokumentation beschreibt in der Spielabfrage weder einen angezeigten TLS-Fingerabdruck noch eine Hostnamenprüfung. Der angezeigte Server Name ist laut Dedicated-Server-Seite der Titel im Server Manager, kein dokumentierter TLS-Hostname. Bei einem erstmals oder unerwartet erneut angebotenen Zertifikat: Bestätige es nicht automatisch, sondern frage über einen bereits bekannten, getrennten Kontaktweg nach, ob genau diese Verbindung und ein allfälliger Zertifikatswechsel erwartet sind. Vergleiche einen TLS-Fingerabdruck nur, wenn der Betreiber ihn unabhängig bereitstellt und du denselben Fingerabdruck des verbundenen Serverzertifikats selbst mit einem vertrauenswürdigen Werkzeug sehen kannst. Der API-Token-Fingerprint eignet sich dafür nicht. Ohne unabhängige Bestätigung solltest du das Zertifikat nicht akzeptieren.

Verwechsle den TLS-Fingerabdruck nicht mit dem Fingerprint eines API-Authentifizierungstokens. Die API-Dokumentation beschreibt diesen zweiten Fingerprint als Teil eines Tokens, mit dem der Server dessen Gültigkeit prüft. Er identifiziert nicht das Serverzertifikat und ist kein Wert, den du zur Zertifikatsabfrage verwenden solltest.

Spielclient und API-Zugriff unterscheiden

Für einen normalen Beitritt verwendest du den Server Manager im Spiel. Du brauchst dafür keinen selbst erzeugten API-Token. Die HTTPS-API liegt am Standardport unter /api/v1; die meisten API-Funktionen verlangen einen Bearer-Token. Die API-Dokumentation erklärt, dass der Spielclient für Spieleranmeldungen kurzlebige, an das Spielerkonto gebundene Tokens erhält. Drittanbieter-Anwendungen sollen dafür eigene Application Tokens nutzen und nicht das Admin Password einer Person wiederverwenden.

Ein Application Token wird auf einem Server mit autorisiertem Konsolenzugriff über server.GenerateAPIToken erstellt. Das setzt voraus, dass du den Server tatsächlich administrieren darfst und diese Konsole verfügbar ist. Bei einer verwalteten Instanz sagt der Artikel deshalb nichts darüber aus, ob dein Hosting-Panel API- oder Konsolenzugriff anbietet. Frage den Anbieter nach dem vorgesehenen Weg. Behandle einen ausgegebenen API-Token wie ein dauerhaftes Geheimnis und poste ihn nicht in Tickets oder Chats.

Die API ist laut Dokumentation erst verfügbar, wenn der Server gestartet ist und gerade weder einen Spielstand lädt noch die Karte wechselt. Ein vorübergehender API-Fehler während eines solchen Vorgangs ist daher kein Grund, Passwörter oder Zertifikate zurückzusetzen. Warte, bis der Vorgang beendet ist, und prüfe dann erneut.

Typische Fehler gezielt eingrenzen

  • Der Server lässt sich nicht hinzufügen: Prüfe Adresse und Spielport. Wenn der Server Manager keine Verbindung aufbaut, kann der Netzwerkpfad gestört sein; die Anleitung zu Satisfactory-Ports und Serververbindung erklärt die aktuelle Zuordnung.
  • Das Admin Password wird abgelehnt: Prüfe, ob du nicht versehentlich das Spielerpasswort verwendest. Wenn dein Adminzugriff wiederholt verloren geht, ist auch der Serverstand relevant: Coffee Stains Patch Notes zu 1.2.4.0 nennen einen Fehler, bei dem Adminzugriff ständig verloren gehen konnte und eine erneute Anmeldung nötig war. Frage bei einer gemieteten Instanz nach dem eingesetzten Stand, statt Dateien zu löschen.
  • Mitspielende kommen nicht hinein: Ist Player Password Protection aktiv, benötigen sie das dafür gesetzte Spielerpasswort. Das Admin Password bleibt privat.
  • Das Zertifikat hat sich geändert: Prüfe die Adresse erneut und frage die Serververwaltung über einen unabhängigen Kontaktweg nach dem Austausch. Ein TLS-Warnhinweis ist kein Anlass, eine Zertifikatsprüfung pauschal auszuschalten.

Der Zugriff ist sauber eingerichtet, wenn du den erwarteten Server im Server Manager erkennst, Verwaltungsfunktionen nur mit Adminrechten erreichst und die Gruppe bei aktiviertem Spielerschutz mit dem separaten Spielerpasswort beitreten kann. Für den sicheren Import einer vorhandenen Welt hilft Satisfactory-Spielstand auf einen Dedicated Server übertragen; bei einem ausdrücklich gemeldeten Versionskonflikt findest du den getrennten Ablauf unter Satisfactory Client und Dedicated Server auf gleiche Version bringen.

Quellen