Ubuntu 26.04 / OpenSSH konfigurieren und Public-Key-Authentifizierung testen

Konfigurieren Sie SSH-Schlüssel, indem Sie den Server-Listener überprüfen, nur den öffentlichen Schlüssel des Clients registrieren und eine neue Verbindung testen. Beschränken Sie die Passwortauthentifizierung erst, nachdem der Schlüssel-Login und der administrative Zugriff funktionieren, während die bestehende Sitzung und Konsole verfügbar bleiben.

Dienst, Socket und Adresse überprüfen

sudo apt update
sudo apt install openssh-server
systemctl status ssh.socket ssh.service --no-pager
sudo ss -lntp
ip -br address

Überprüfen Sie den tatsächlichen Listener zusammen mit ssh.socket und ssh.service. Behalten Sie den bestehenden SSH-Port bei. Mit der NAT-Plus-Host-Only-Konfiguration in der VM-Erstellungsanleitung ist der Server .20 und der Linux-Client .10; führen Sie Schlüsselbefehle auf diesem Client aus. Eine inaktive Einheit kann je nach Socket-Aktivierung normal sein.

Ubuntus OpenSSH-Leitfaden erklärt Installation, Konfigurationspriorität und Validierung.

Überprüfen Sie auf dem Linux-Client den Befehl command -v ssh und command -v ssh-copy-id. Installieren Sie bei Bedarf openssh-client mit sudo apt update && sudo apt install openssh-client. Ersetzen Sie den normalen Benutzernamen, der während der Installation erstellt wurde, und stellen Sie einen autorisierten Erstlogin oder Konsolenweg her, bevor Sie den öffentlichen Schlüssel registrieren. Schwächen Sie die Authentifizierung in der Produktion nicht nur für die Übung.

Überprüfen Sie die Serveridentität und erstellen Sie einen Client-Schlüssel

Überprüfen Sie an der Serverkonsole den Host-Schlüssel-Fingerabdruck mit sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub und vergleichen Sie dann die erste Verbindung über einen vertrauenswürdigen Weg. Führen Sie die folgenden Generierungs- und Kopierbefehle auf dem Linux-Client aus, nicht auf dem Server.

ssh-keygen -t ed25519 -f "$HOME/.ssh/ubuntu-lab-ed25519"
ssh-copy-id -i "$HOME/.ssh/ubuntu-lab-ed25519.pub" labuser@192.168.56.20

Ersetzen Sie labuser und die Adresse durch reale Werte und überschreiben Sie keine bestehende Schlüsseldatei. Legen Sie eine Passphrase für den privaten Schlüssel fest und bewahren Sie sie sicher auf. Übertragen Sie nur den öffentlichen Schlüssel .pub; kopieren Sie niemals den privaten Schlüssel auf den Server. Das Kopierbeispiel geht von Linux aus, da die Standard-SSH-Tools von Windows ssh-copy-id möglicherweise weglassen.

Testen Sie eine neue Verbindung nur mit dem Schlüssel

ssh -i "$HOME/.ssh/ubuntu-lab-ed25519" -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no labuser@192.168.56.20

Eine Passphrase-Abfrage für einen privaten Schlüssel unterscheidet sich von einer Serverkonto-Passwortabfrage. Nach der Verbindung überprüfen Sie whoami und den erforderlichen sudo-Zugriff. Bei einem Fehler überprüfen Sie das Konto, Eigentum, Berechtigungen im Home-Verzeichnis und bei den SSH-Dateien sowie die Serverprotokolle; machen Sie sie nicht für alle Benutzer schreibbar.

Validieren Sie die beabsichtigte Authentifizierungsrichtlinie

Auf einem neuen Laborserver, der speziell für die Authentifizierung mit einem einzelnen Schlüssel vorgesehen ist, sichern Sie die SSH-Konfiguration und überprüfen eine separate Datei wie /etc/ssh/sshd_config.d/00-lab-auth.conf. Wenden Sie die unten stehende Richtlinie nicht unverändert auf einen Server mit bestehender MFA oder organisatorischer Authentifizierung an.

PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
PermitRootLogin no

OpenSSH verwendet den zuerst gelesenen Wert für viele Optionen; prüfen Sie die effektive Konfiguration, anstatt einem Dateinamen zu vertrauen. Regeln in Match-Blöcken müssen anhand der tatsächlichen Benutzer- und Clientbedingungen über sshd -T -C ausgewertet werden. Wenden Sie diese Lab-Richtlinie erst an, nachdem die Anmeldung mit dem privaten Schlüssel verifiziert wurde.

sudo sshd -t
sudo sshd -T | grep -E '^(pubkeyauthentication|authenticationmethods|passwordauthentication|permitrootlogin) '

Anwenden, neu starten und in der Reihenfolge wiederherstellen

Nach erfolgreicher Syntaxprüfung die Authentifizierungseinstellungen mit sudo systemctl reload ssh.service neu laden, wenn der Dienst tatsächlich läuft. Diese Übung ändert keine Ports. Port- oder ListenAddress-Änderungen unter Socket-Aktivierung erfordern eine separate Überprüfung der Socket-Erzeugung und des Daemon-Neuladungsverhaltens.

Bevor Sie die alte Sitzung schließen, testen Sie eine neue Schlüsselanmeldung, sudo und die Ablehnung unerwünschter Authentifizierungen. Wiederholen Sie dies nach einem geplanten Neustart. Wenn es fehlschlägt, stellen Sie nur die geänderte Konfiguration über die Konsole wieder her, überprüfen Sie sie und wenden Sie sie an. Untersuchen Sie geänderte Host-Schlüssel-Warnungen, anstatt Vertrauensaufzeichnungen blind zu löschen.