Ihre erste SSH-Sitzung, mit einem Weg zurück.

Sammeln Sie die Zugriffsdetails und den Wiederherstellungspfad

Sie benötigen die tatsächliche Serveradresse, den SSH-Port, den Anmeldebenutzernamen, die anfängliche Authentifizierungsmethode und eine vertrauenswürdige Quelle für den Hostschlüssel-Fingerabdruck des Servers. Ein ausgewählter Hostname in einem Konfigurator begründet weder DNS noch ein Konto. Beziehen Sie diese Details aus dem tatsächlichen Service-Setup, nicht aus Annahmen über ein Linux-Image.

Bestätigen Sie, wie Sie eine Konsole oder eine Rescue-Umgebung erreichen und wer den Zugriff wiederherstellen kann. Prüfen Sie, dass Sie diesen Wiederherstellungspfad jetzt öffnen können; finden Sie nicht erst während einer Aussperrung heraus, dass Ihnen die Berechtigung oder Wiederherstellungsanmeldeinformationen fehlen. Wenn kein unabhängiger Wiederherstellungspfad verfügbar ist, lassen Sie die Zugriffseinstellungen unverändert, bis einer eingerichtet ist.

Die Beispiele verwenden ein Bash-Client-Terminal auf Ihrem eigenen Computer und einen Ubuntu/Debian-Server. Ersetzen Sie Ihre echten Details für builder, Port 22 und 192.0.2.10, eine reservierte Beispieladresse. Befehle sind Anweisungen, die Sie für Ihre Umgebung prüfen sollten; dieser Leitfaden hat keine Verbindung zu einem OffVPS-Server hergestellt oder ihn konfiguriert.

Erstellen Sie einen Client-Schlüssel, ohne einen vorhandenen zu ersetzen

Ihr privater Schlüssel bleibt auf dem Client-Computer. Der passende öffentliche Schlüssel kann in den autorisierten Schlüsseln des Serverkontos installiert werden. Keiner von beiden ist der Hostschlüssel des Servers: Dieser separate Schlüssel hilft, die Maschine zu identifizieren, die Sie kontaktieren. Halten Sie den privaten Schlüssel und seine Passphrase aus Support-Nachrichten, Repositories und Server-Uploads heraus.

ssh -V
ls -ld "$HOME/.ssh"
ls "$HOME/.ssh/offvps_first_vps" "$HOME/.ssh/offvps_first_vps.pub"

Prüfen Sie zuerst die Pfade. Wenn das SSH-Verzeichnis nicht existiert, erstellen Sie es mit der Berechtigung 700. Wenn eine der genannten Schlüsseldateien bereits existiert, wählen Sie einen anderen Namen oder verwenden Sie bewusst Ihren vorhandenen Schlüssel weiter; überschreiben Sie ihn nicht. Erzeugen Sie einen dedizierten Schlüssel mit einer Passphrase:

ssh-keygen -t ed25519 -f "$HOME/.ssh/offvps_first_vps" -C "first-vps"
ssh-keygen -lf "$HOME/.ssh/offvps_first_vps.pub" -E sha256

Der zweite Befehl zeigt den Fingerabdruck des öffentlichen Schlüssels an, nicht privates Schlüsselmaterial. Die ssh-keygen-Handbuchseite dokumentiert Schlüsseltypen, Ausgabedateien und Fingerabdrücke. Wo ein verwaltetes Gerät eine andere Schlüsselrichtlinie erfordert, folgen Sie dieser Richtlinie und verifizieren Sie die Serverunterstützung. Bewahren Sie eine angemessen geschützte Wiederherstellungskopie des privaten Schlüssels auf, wenn Ihr Wiederherstellungsplan darauf angewiesen ist.

Verifizieren Sie den Server vor der Authentifizierung

Beschaffen Sie über die vertrauenswürdige Konsole oder einen anderen authentifizierten Setup-Kanal den Fingerabdruck für den Ed25519-Hostschlüssel des Servers. Auf einem Server, der den Standardpfad OpenSSH verwendet, kann ein Administrator die öffentliche Datei einsehen mit:

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

Vergleichen Sie den vollständigen SHA256-Fingerabdruck und den Algorithmus mit der ersten SSH-Verbindungsaufforderung. Ein Fingerabdruck, der nur über dieselbe nicht verifizierte Netzwerkverbindung abgerufen wurde, ist keine unabhängige Verifizierung. Wenn der Server einen anderen Hostschlüsselalgorithmus anbietet, beschaffen Sie den Fingerabdruck dieses Schlüssels, anstatt ungleiche Werte zu vergleichen. OpenSSH’s Hostschlüssel-Verifizierungsanleitung erklärt diesen Vergleich.

Wenn sich der Schlüssel bei einem späteren Besuch unerwartet ändert, stoppen Sie. Ein Rebuild kann Hostschlüssel legitimerweise ersetzen, aber verifizieren Sie dieses Ereignis und den neuen Fingerabdruck über den Wiederherstellungskanal. Unterdrücken Sie die Warnung nicht und löschen Sie nicht den alten Known-Host-Eintrag, nur um die Verbindung erfolgreich zu machen.

Installieren Sie nur den öffentlichen Schlüssel und öffnen Sie die erste Sitzung

Wenn Ihr öffentlicher Schlüssel bereits über den autorisierten Setup-Prozess installiert wurde, verbinden Sie sich direkt. Andernfalls verwenden Sie die vorhandene verifizierte Zugriffsmethode, um den öffentlichen Schlüssel zum vorgesehenen Konto hinzuzufügen. Auf einem Client mit ssh-copy-id, und nur wenn diese anfängliche Anmeldemethode funktioniert, hängt dieser Befehl den ausgewählten öffentlichen Schlüssel an:

ssh-copy-id -i "$HOME/.ssh/offvps_first_vps.pub" -p 22 [email protected]

Ubuntu’s OpenSSH-Anleitung beschreibt die Installation öffentlicher Schlüssel und die Berechtigungsanforderungen. Ersetzen Sie nicht eine gesamte authorized_keys Datei oder ändern Sie nicht die Einträge eines anderen Administrators. Öffnen Sie dann die schlüsselbasierte Sitzung:

ssh -o IdentitiesOnly=yes -i "$HOME/.ssh/offvps_first_vps" \
  -p 22 [email protected]

Prüfen Sie nach der Anmeldung id und hostname. Bestätigen Sie, dass das Konto den Setup-Details entspricht; ein Hostname allein ist keine Hostschlüssel-Verifizierung. Wenn Ihre Aufgaben Administration erfordern, führen Sie sudo -v aus und stellen Sie fest, dass dieses Konto den vorgesehenen Privilegienpfad hat. Lassen Sie diese erste Sitzung geöffnet.

Weisen Sie eine wirklich separate zweite Anmeldung nach

Öffnen Sie ein weiteres Client-Terminal und fordern Sie eine neue Verbindung an, die keinen SSH-Connection-Sharing-Socket wiederverwenden kann. Beschränken Sie diesen Test auf Public-Key-Authentifizierung, damit ein Passwort-Fallback ein defektes Schlüssel-Setup nicht verdeckt:

ssh -o ControlMaster=no -o ControlPath=none \
  -o IdentitiesOnly=yes -o PreferredAuthentications=publickey \
  -i "$HOME/.ssh/offvps_first_vps" -p 22 [email protected]

Prüfen id, hostname und, wo nötig, sudo -v auch in dieser zweiten Sitzung. Ein neues Terminal allein ist unzureichend, wenn der Client eine bestehende Verbindung wiederverwendet. ControlPath=none deaktiviert diese Freigabe; siehe OpenSSH-Clientkonfiguration. Schließen Sie die ursprüngliche Sitzung erst, nachdem diese unabhängige Verbindung erfolgreich war und der Wiederherstellungspfad weiterhin verfügbar ist.

Vor jeder späteren Zugriffsänderung

Lassen Sie für diese erste Sitzung den SSH-Port, die Authentifizierungsmethoden und die Firewall-Regeln unverändert. Bevor Sie sie später ändern, speichern Sie die aktuelle Konfiguration und dokumentieren Sie, wie Sie sie über die vertrauenswürdige Konsole wiederherstellen. Bestätigen Sie eine funktionierende Schlüsselanmeldung, bevor Sie eine andere Methode deaktivieren. Lassen Sie die erste Sitzung geöffnet, während Sie jeweils eine überprüfte Änderung vornehmen.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

Auf Systemen mit diesem OpenSSH-Executable-Pfad -t prüft die Konfigurationssyntax und die Hostschlüssel-Konsistenz; -T meldet auch effektive Einstellungen. Verbindungsspezifische Match Regeln können -C Parameter für das getestete Konto und die Adresse erfordern. Diese Prüfungen testen nicht die Firewall-Erreichbarkeit und beweisen nicht, dass eine neue Anmeldung funktioniert. Siehe sshd-Testmodi. Beheben Sie Fehler, bevor Sie eine Dienstkonfiguration anwenden oder neu laden, und wiederholen Sie dann die unabhängige Anmeldeprüfung.

Nutzen Sie den Fehler, um die nächste Prüfung auszuwählen

• Timeout: Bestätigen Sie die Adresse, den Port, die Anbieterregeln und die Host-Firewall über den Wiederherstellungspfad.
• Verbindung verweigert: Prüfen Sie, ob SSH auf der erwarteten Adresse und dem erwarteten Port lauscht.
• Berechtigung verweigert: Prüfen Sie Benutzername, ausgewählten öffentlichen Schlüssel und die Berechtigungen der Kontoschlüsseldatei aus der noch geöffneten Sitzung.
• Host-Identifikation geändert: Verifizieren Sie die Maschine und den neuen Fingerabdruck unabhängig, bevor Sie fortfahren.

Dokumentieren Sie den verifizierten Hostschlüssel-Fingerabdruck, das Konto, den Port und das Wiederherstellungsverfahren in Ihren Betriebsnotizen. Halten Sie Schlüsselmaterial privat. Sobald der Zugriff wiederholbar ist, fahren Sie fort mit Ihrer ersten API-Veröffentlichung oder einem Ressourcenbudget für die Anwendung.