Ich möchte eine SFTP-Verbindung zwischen meinem Computer und einem Server einrichten.
Ich habe auf meinem Computer ein Schlüsselpaar generiert und meinen öffentlichen Schlüssel in die Datei „authorized_keys“ auf dem Server geschrieben. Ich bin sicher, dass es funktioniert, denn wenn ich versuche, mich von einem Computer aus zu verbinden, der meinen privaten Schlüssel nicht hat (ich weiß, niemand sonst sollte ihn haben), wird ein Passwort abgefragt.
Entsprechenddieses Bild, mein Server ist Bob und mein Computer ist Alice. Wenn der Server eine Nachricht sendet, verwendet er meinen öffentlichen Schlüssel zum Verschlüsseln und ich verwende meinen privaten Schlüssel zum Entschlüsseln. Aber wenn ich eine Nachricht an den Server sende, ist sie nicht verschlüsselt, oder? Wenn doch, wie wird sie verschlüsselt?
So wie ich die asymmetrische Kryptografie verstanden habe, muss ich, wenn ich die von mir gesendeten Nachrichten verschlüsseln möchte, ein Schlüsselpaar auf dem Server generieren und den öffentlichen Schlüssel in die Datei „authorized_keys“ meines Computers einfügen, richtig?
Wie kann ichverifizierendass die Verbindung in beide Richtungen (Senden und Empfangen) gesichert ist?
Danke!
Antwort1
Bei SSH-Verbindungen passieren zwei wichtige Dinge:
Serverauthentifizierung und -verschlüsselung
Der Server sendet Ihnen seinen öffentlichen Schlüssel und Sie müssen ihm vertrauen. Sie könnten ihn vorher manuell abrufen und in einer idealen Sicherheitsumgebung würden Sie sich nie mit einem SSH-Server verbinden, BEVOR Sie wissen, dass sein öffentlicher Schlüssel korrekt ist. Dafür sind CAs da, sie signieren den öffentlichen Schlüssel eines Servers. In den meisten SSH-Umgebungen akzeptieren Sie als Client einfach den öffentlichen Schlüssel des Servers. Dies ist die anfängliche „Möchten Sie diesem Server vertrauen und ihn zu Ihrer Liste hinzufügen?“-Frage.Der Server-Pubkey wird auf dem Client in Linux-Systemen unter .ssh/known_hosts gespeichert.
Die eigentliche Verschlüsselung der Verbindung ist nicht asymmetrisch. Dies ist ein großes Missverständnis, das viele Leute über die Verschlüsselung mit privatem/öffentlichem Schlüssel haben. Sie wäre VIEL zu langsam. Was wirklich passiert, ist, dass Server und Client ein gemeinsames Geheimnis (auch bekannt als langes Passwort) generieren, dassymmetrische Verschlüsselungfür diese eine Sitzung. Client und Server verwenden asymmetrische Verschlüsselung, bis sie sich auf ein gemeinsames Geheimnis einigen. Danach wechseln sie zur symmetrischen Verschlüsselung mit diesem gemeinsamen Geheimnis als Schlüssel.
Diese Art der Verschlüsselung ist die gebräuchlichste und wirdHybrid-Verschlüsselung, obwohl es fast jeder (fälschlicherweise) asymmetrische Verschlüsselung nennt.
Ein Beispiel für „echte“, rein asymmetrische Verschlüsselung ist die Mailverschlüsselung mit PGP, da JEDE Nachricht asymmetrisch verschlüsselt wird.
Außerdem: Das gemeinsame Geheimnis wird nicht dauerhaft gespeichert, bei jeder neuen Sitzung wird ein neues gemeinsames Geheimnis ausgehandelt.
Client-Authentifizierung
Dies ist eine ganz andere Sache, dies kann eine passwort- und/oder schlüsselbasierte Authentifizierung sein. Der öffentliche Schlüssel des Clients (unter ~/.ssh/id_rsa.pub) muss in der Datei authorized_keys des Servers vorhanden sein (z. B. für root: /root/.ssh/authorized_keys). Bevor es ssh-copy-iddas gab, machten die Leute so etwas wie
cat ~/.ssh/id_rsa.pub | ssh root@server "cat >> ~/.ssh/authorized_keys"
um Ihren Schlüssel an die autorisierten Schlüssel des Servers anzuhängen.
Das Client-Zertifikat wird NICHT zur Verschlüsselung, sondern nur zur Authentifizierung verwendet.
WICHTIGE Bearbeitung:Der Beitrag wurde klarer formuliert, ssh-copy-idum Missverständnissen vorzubeugen.
Derzeit ssh-copy-idist dies die beste Vorgehensweise, um den öffentlichen Schlüssel eines Clients zu einem Server hinzuzufügen. Ich habe gerade die catMethode gepostet, um zu zeigen, welche Dateien auf beiden Seiten manipuliert werden, um die Verbindung zwischen privaten und öffentlichen Schlüsseln und deren Speicherung aufzuzeigen.
Bei der Verwendung von cat besteht die Gefahr, dass beispielsweise ein ">" vergessen wird.überschreibenIhre authorized_keys-Datei (unter Linux bedeutet ">>" anhängen, ">" bedeutet überschreiben). Gehen Sie verantwortungsvoll vor, wenn Sie Konfigurationsdateien direkt bearbeiten. Danke, @Rallph, für den Hinweis.
Antwort2
Der Server hat sein eigenes Schlüsselpaar. Wenn Sie sich zum ersten Mal mit einem SSH-Server verbinden, sollten Sie von Ihrem SSH/SFTP-Client gefragt werden, ob Sie dem Hostschlüssel (=öffentlicher Schlüssel) des Servers vertrauen.
Erst wenn Sie sorgfältig überprüft haben, dass es sich tatsächlich um einen legitimen öffentlichen Schlüssel des Servers handelt, ist Ihre Verbindung sicher. SieheMeinArtikelWo bekomme ich den SSH-Hostschlüssel-Fingerabdruck zur Autorisierung des Servers?
Beachten Sie auch, dass weder Ihr Schlüsselpaar noch das Schlüsselpaar des Servers tatsächlich zum Verschlüsseln der Daten verwendet werden. Das ist viel komplizierter.
Siehe auch: