Bestellung und erster Zugang

Der Root-Zugang wird genau einmal ausgeliefert, beim ersten Boot, als öffentlicher SSH-Schlüssel in /root/.ssh/authorized_keys. Es gibt kein Passwort, keine Zugangsdaten per E-Mail und keinen zweiten Kanal. Alles auf dieser Seite folgt daraus.

Hinterlege zuerst einen SSH-Schlüssel

Deine Schlüssel liegen im Portal unter Kontoeinstellungen → SSH-Schlüssel. Leg den öffentlichen Schlüssel dort ab, bevor du bestellst, denn im Bestellformular kannst du nur bereits gespeicherte Schlüssel auswählen.

Jeder öffentliche Schlüssel, den OpenSSH akzeptiert, wird auch hier akzeptiert, in authorized_keys-Form:

cat ~/.ssh/id_ed25519.pub

Du kannst bis zu 50 Schlüssel pro Konto speichern. Ein Schlüssel muss aktiv sein, um beim Checkout auswählbar zu sein: Ein inaktiver wird noch vor der Zahlung abgelehnt, mit ssh_key_invalid.

Ohne Schlüssel zu bestellen ist erlaubt, und genau das ist die Falle

Das Feld für den SSH-Schlüssel beim Checkout ist optional. Bestellst du ohne, wird der Server ganz normal bereitgestellt und gestartet, ohne hinterlegten Schlüssel und ohne Root-Passwort. Niemand kann sich einloggen.

Das lässt sich beheben, aber nur über den Gast-Agenten (siehe Wenn du ohne Schlüssel bestellt hast unten), und nur solange der Server läuft. Wähl beim Checkout einen Schlüssel aus, wenn du keinen konkreten Grund dagegen hast.

Die Bestellung

Im Portal unter Shop → VServer. Du wählst Hostname, Image, SSH-Schlüssel und Tarif, und der Server landet wie jedes andere Produkt im Warenkorb.

Der Hostname ist optional. Lässt du ihn leer, wird einer erzeugt. Er ist außerdem nur ein Name, in dem Sinne, dass er den Server im Portal, in Warnungen und in der Fertig-E-Mail bezeichnet. Im Betriebssystem wird er beim ersten Boot gesetzt, aber ihn später umzubenennen ändert den Hostnamen in einem laufenden Server nicht.

Zwei Dinge werden geprüft, bevor deine Karte belastet wird, damit eine Bestellung, die wir nicht erfüllen können, abgelehnt statt angenommen wird:

insufficient IPv4 addresses available
insufficient node capacity (memory or disk) for the requested size

Beides kommt als Fehler beim Checkout zurück, nicht als kaputter Server hinterher. Ein Tarif ohne Bestand ist im Shop zusätzlich als Ausverkauft markiert. Kommt stattdessen vserver capacity temporarily unavailable, please retry, ließ sich der Bestand in dem Moment nicht ermitteln und die Bestellung wurde absichtlich abgelehnt; versuch es erneut.

Während der Bereitstellung

Der Server taucht im Portal unter VServer mit dem Status Wird bereitgestellt und noch ohne IP-Adresse auf. Er bekommt eine Adresse, wird gebaut, gestartet, und springt auf Aktiv.

Du bekommst eine E-Mail, sobald er läuft, mit IPv4-Adresse, IPv6-Block und den Eckdaten. Hast du mit Schlüssel bestellt, steht der Login-Befehl gleich mit darin.

Endet es in Fehlgeschlagen, wird die Bereitstellung automatisch bis zu dreimal wiederholt. Danach bleibt der Server fehlgeschlagen, die Abrechnung dafür wird gestoppt, und der Fall landet bei uns für eine Rückerstattung oder einen manuellen Neuaufbau. Das Portal zeigt dir den Grund nicht an. Wenn ein Server also in Fehlgeschlagen stehen bleibt, wende dich an den Support, statt neu zu bestellen.

Der erste Login

ssh root@<deine-ip>

Mehr ist es nicht: Benutzer root, der Schlüssel, den du gewählt hast, die IPv4-Adresse aus dem Portal oder der E-Mail. Ein Root-Passwort ist nicht gesetzt, es gibt also nichts einzutippen.

Die IPv6-Adresse funktioniert genauso und ist die erste Adresse aus dem Block, den dir das Portal zeigt, nicht der Block selbst. Siehe Netzwerk.

Wenn du ohne Schlüssel bestellt hast

Das Portal zeigt am Server einen Hinweis: Noch kein Zugang eingerichtet. Zwei Wege hinaus, beide unter Einstellungen, und beide brauchen einen laufenden Server und einen antwortenden Gast-Agenten:

• SSH-Schlüssel einspielen schreibt einen deiner gespeicherten Schlüssel in /root/.ssh/authorized_keys auf dem laufenden Server. Standardmäßig wird angehängt; mit Alle vorhandenen Schlüssel ersetzen wird die Datei durch genau diesen Schlüssel überschrieben.
• Root-Passwort zurücksetzen setzt ein frisches Zufallspasswort und zeigt es einmalig an.

Beides lässt den Hinweis verschwinden.

Das Root-Passwort ist für die Konsole

Das Passwort aus Root-Passwort zurücksetzen wird genau einmal angezeigt, im Dialog. Es wird nirgends gespeichert, wo du es nachlesen könntest, und wir können es dir nicht erneut zeigen. Kopier es, bevor du den Dialog schließt; wenn es weg ist, setz es einfach noch einmal zurück.

Benutz es im Tab Konsole, der Tastatur und Bildschirm an der Maschine ist und dem egal ist, ob das Netzwerk im Server funktioniert. Ein SSH-Login ist es nicht: In den Images ist die Passwort-Authentifizierung für SSH abgeschaltet, und das in der sshd_config einzuschalten wäre etwas, das du dir selbst antust, nicht etwas, das wir empfehlen.

Der Gast-Agent

Einen Schlüssel in einen laufenden Server einzuspielen und das Root-Passwort zurückzusetzen laufen beide über einen kleinen Agenten im Gast, den das Image beim ersten Boot installiert. Sein Zustand steht im Tab Übersicht unter Gast-Agent.

Antwortet er nicht, scheitern diese beiden Aktionen wörtlich mit:

This action needs the QEMU guest agent running inside your server, but it
isn't responding.

Installier ihn im Server nach, dann funktionieren die Aktionen wieder:

apt install qemu-guest-agent && systemctl enable --now qemu-guest-agent

Lass ihn installiert. Neben den beiden Rettungswegen ist er es, der ein sauberes Herunterfahren sauber macht und der die Warnung bei voller Festplatte speist.

Flatcar Container Linux hat keinen Gast-Agenten

Flatcar verarbeitet die Konfiguration nicht, die ihn installiert. SSH-Schlüssel einspielen und Root-Passwort zurücksetzen funktionieren auf einem Flatcar-Server also nicht. Bestell ihn mit SSH-Schlüssel, und hinterleg einen zweiten Schlüssel darauf.

Ein gelöschter Schlüssel liegt weiter auf dem Server

Einen Schlüssel unter Kontoeinstellungen → SSH-Schlüssel zu löschen entfernt ihn aus deinem Schlüsselspeicher. Damit wird er beim Checkout und bei SSH-Schlüssel einspielen nicht mehr angeboten. Auf einem Server, auf dem er schon liegt, ändert das nichts.

Es gibt keinen Widerruf aus der Ferne

Sobald ein Schlüssel in den authorized_keys eines laufenden Servers steht, kannst du ihn nur dort entfernen, im Server selbst. Dasselbe gilt für ein zurückgesetztes Root-Passwort: Nichts im Portal nimmt es zurück.

Wenn also ein privater Schlüssel oder ein Root-Passwort abhandenkommt, bearbeite /root/.ssh/authorized_keys und ändere das Passwort auf jedem Server, den es erreicht hat. Kommst du selbst nicht mehr hinein, bleibt nur eine Neuinstallation, die die Festplatte löscht.

Behandle deshalb beides als langlebige Zugangsdaten. Halte private Schlüssel von geteilten Rechnern fern, und nimm beim Wechseln lieber Alle vorhandenen Schlüssel ersetzen statt anzuhängen.

Wie es weitergeht

• Server verwalten für Strom, Konsole und Snapshots
• Netzwerk für die Adressen und was sie erreicht