Wer sieht Ihr SSH-Passwort in einem nicht vertrauenswürdigen VPN wirklich?

Leiten Sie eine SSH-Sitzung über ein VPN, das Sie nicht betreiben, und das Passwort gehört weiterhin dem SSH-Server, nicht dem Netz dazwischen. Wenn der Transport zu einem verifizierten Host ordentlich geschützt ist, erhält ein passiver Beobachter auf diesem Weg das Passwort nicht in lesbarer Form. Ändern Sie jedoch eine Bedingung, und die Antwort ändert sich: ein unverifizierter Host, eine geschwächte Cipher-Liste oder eine kompromittierte Workstation führen zu unterschiedlichen Ergebnissen. Führen Sie die folgenden Prüfungen der Reihe nach aus und behandeln Sie jede als Abbruchbedingung.

Benennen Sie den Empfänger, bevor Sie etwas eintippen

Das Passwortfeld reist innerhalb einer Authentifizierungsnachricht, und diese Nachricht reist innerhalb des verschlüsselten Transports. Vertraulichkeit ist eine Eigenschaft des Transports, was bedeutet, dass sie davon abhängt, dass Schutz ausgehandelt wurde und dass er mit dem Host ausgehandelt wurde, den Sie im Sinn hatten. Genau diese zweite Hälfte lassen die Leute aus. Eine Verbindung, die zu einem Betrüger verschlüsselt ist, ist gleichzeitig vertraulich und nutzlos. Der VPN-Login beweist nichts über den SSH-Host, und der Ruf des Anbieters ersetzt die Schlüsselprüfung nicht.

Halten Sie die beiden Richtungen im Kopf getrennt. Der Hostschlüssel beantwortet, welchen Server Sie erreicht haben. Passwort- oder Schlüsselauthentifizierung beantwortet, welchen Benutzer der Server akzeptiert. Die Verbesserung des zweiten repariert nie das erste.

Prüfen Sie Hostidentität, Eintrag und Aushandlung

Beginnen Sie auf dem Client mit dem Eintrag, den Sie bereits haben. Ein veröffentlichter Fingerabdruck, der mit einer vertrauenswürdigen Quelle verglichen wird, und ein known_hosts-Eintrag, der noch übereinstimmt, liefern Ihnen den einzigen Beweis, der vor Beginn der Authentifizierung zählt.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

Geben Sie auf der Serverseite die Fingerabdrücke aus, die Sie veröffentlichen wollen, statt sie aus dem Gedächtnis zu kopieren. Sie außerhalb des Kanals zu verteilen ist der ganze Punkt; ein Fingerabdruck, der aus demselben Chatkanal eingefügt wurde wie der Hostname, beweist nur, dass beides von derselben Stelle kam.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

Die ausgehandelten Algorithmen ergeben sich aus der Schnittmenge beider Seiten. Wenn eine Client-Konfiguration einen veralteten Schlüsselaustausch festnagelt, um ein altes Gerät zu erreichen, gilt diese Wahl für jeden Host, mit dem er spricht, also beschränken Sie sie auf diesen Host statt global.

Lesen Sie, welche Methoden der Server tatsächlich akzeptiert

Zu wissen, welche Authentifizierungsmethoden ein Server erlaubt, sagt Ihnen, wofür das Passwort überhaupt da ist. Ein Host, der nur öffentliche Schlüssel akzeptiert, hat keinen Passwortaustausch zu schützen, und ein Host, der weiterhin Passwörter akzeptiert, verdient eine bewusste Entscheidung statt einer geerbten Vorgabe.

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Einen Benutzer auf Schlüsselauthentifizierung umzustellen entfernt das Passwort dieses Benutzers aus diesem Austausch. Es macht eine kompromittierte Workstation nicht sicher und eine nicht vertrauenswürdige Remote-Sitzung nicht harmlos. Das sind unterschiedliche Risiken mit unterschiedlichen Kontrollen. Entscheiden Sie auch über Agent-Weiterleitung. Einen Agent an einen nicht vertrauenswürdigen Host weiterzuleiten gibt diesem Host die Möglichkeit, Ihre Schlüssel zu benutzen, solange die Sitzung dauert, und das ist eine größere Exposition als die Passwortfrage, mit der alles begann.

Behandeln Sie eine Hostschlüsselwarnung als Incident-Schritt

Wenn der Client warnt, dass sich die Hostidentifikation geändert hat, halten Sie an und prüfen Sie über einen Kanal, der nicht denselben Netzwerkpfad nimmt. Vergleichen Sie den Fingerabdruck mit der Serverkonsole oder mit der Person, die ihn neu aufgebaut hat. Den alten Eintrag zu löschen, um die Warnung zum Schweigen zu bringen, ist die eine Handlung, die Sie verweigern sollten. Sie verwirft den Beweis und verwandelt eine mögliche Abfangaktion in einen normalen Login.

Wenn der Host rechtmäßig neu aufgebaut wurde, entfernen Sie den veralteten Eintrag erst, nachdem der neue Fingerabdruck bestätigt ist, verbinden Sie sich dann erneut und prüfen Sie die Aushandlung noch einmal. Halten Sie die Änderung mit Datum und Grund fest, denn die nächste Person wird dieselbe Warnung sehen und muss wissen, dass sie geklärt ist.

Was dieses Runbook nicht abdeckt

Ein VPN-Betreiber, der Verkehr beobachtet, ist nicht dasselbe wie Software mit lokalen Rechten auf Ihrem Rechner. Endpunkt-Kompromittierung, eine feindliche Browsererweiterung oder ein Keylogger liegen unter allem, was SSH aushandeln kann, und kein Tunnel ändert das. Wenn die Workstation verdächtig ist, folgen Sie dem Incident-Prozess, statt Geheimhaltung zu testen, indem Sie sich über einen anderen Ausgang neu verbinden. Ein neues Verbinden beweist, dass sich der Netzwerkpfad geändert hat, und nichts über den Endpunkt.

Schließen Sie mit dem Normalfall ab: verifizierter Host, geschützter Transport, die bewusst gewählte Authentifizierungsmethode und keine Weiterleitung, die Sie nicht brauchten. Diese Kombination ist die Antwort auf die Frage im Titel, und es sind vier Entscheidungen statt einer.