SSH, was genau sind private und public keys?
Hallo,
Ich habe mir letztens mehrere Beschreibungen von SSH-Keys angesehen und dort ständig etwas von "private" und "public" gelesen. Aber wofür genau braucht man beide keys?
Ich verstehe das System nicht so ganz trotz der ganzen Beschreibungen.
Hätte jemand eine gute Beschreibung für mich was genau der Unterschied zwischen public und private keys sind und warum genau man zwei benötigt.
Danke schon mal im voraus.
LG
Endivie02
7 Antworten
ssh bietet die Möglichkeit, Computer über ein Netzwerk zu koppeln.
So gehört auch scp dazu.
scp User@IP-Adresse:/home/us
Hallo Endivie,
Bei diesem System werden die Daten besonders sicher verschlüsselt mit private und public Key.
Den privaten Key darf niemand außer Dir bekommen, weil damit DEINE Daten sicher verschlüsselt werden und entschlüsselt werden können.
Den public Key musst Du hingegen allen Leuten zur Verfügung stellen, damit diese DIR verschlüsselte Daten/Email schicken können.
Wenn also ich Dir verschlüsselt schreiben möchte, brauche ich Deinen public Key. 😊
Umgekehrt, wenn Du an mich verschüsselt schreiben willst, muss ich Dir erst meinen public Key geben.
unsinn , SSH heist secure shell , wie auch bei https secure und dazu brauch es die ganz normalen paare . wenn man von einem SSH Login via Key redet ist das der nächste schritt . tut aber auch nicht nötig bei genug langen passwörtern . und ein minecraft server ist jetzt erstmal nix was einem dazu verleiten tut. ist ein kann aber schon gar kein muss .
SECURE = VERSCHLÜSSELTER KANAL
erst danach kann man auch ein Login mit einem KEY machen der dann zur Authentifizierung dient .
Die SSH Public/Private Keys dienen wirklich alleine der Authentisierung (um z.B. Man-in-the-Middle-Angriffe abzuwehren).
Die Kanalverschlüsselung erfolgt über symmetrische Verschlüsselung (z.B. AES-Chiffre), der dafür verwendete Schlüssel wird z.B. über Diffie-Hellman-Schlüsselaustausch ausgewürfelt.
D.h. der SSH-Client und der SSH-Server einigen sich zuerst auf einen zufälligen Schlüssel (Diffie-Hellman-Verfahren) und reden dann (z.B.) AES-gesichert über dieses verschlüsselten Kanal. Darin wird dann geklärt (über die Public/Private Keys) ob der Server wirklich der echte Server ist (und nicht ein MITM-Angreifer) und ob der Client zugangsberechtigt ist (Passwort oder Public Key).
Stimmt , obwohl die übergabe des symetrischen ist ja auch schon ein sicherer Kanal , nur wird danach der aufwand reduziert . Ich war irgendwie bei der identitätsprüfung , bin zu weit im PGP gewesen . Danke für die korrektur . entschuldige ich mich mal bei barnim.
Der symmetrische Schlüssel wird ja erst gar nicht übertragen, sondern von beiden Kommunikationspartnern so trickreich ausgehandelt, dass der jeweils andere und auch potentielle Lauscher die Geheimnisse nicht erfahren.
Nur die identität des Partners ist noch nicht sicher.
jo weiss ich , dennoch tritt sofort die verschlüsselung ein , auch beim PGP wird der symetrische mit verschlüsselt und dann auch noch für jeden empfänger :) nur das verfahren wird gändert , cryptisch ist es in jedem fall , nur halt nicht die ganze aushandlung aber immerhin der inhalt :) und in einem paket sind dennoch die start und ziel adresse lesbar. also so ganz geheim ist es auch wieder nicht :) immer nur der inhalt, was aber auch logisch ist :)
Ja ich habs mir sogar mathemtisch angegugt allerdings dann RSA , weil mich die schlüssel herstellung interressierte https://www.youtube.com/watch?v=ynp1NPlXKQE
Neben der Einwegfunktion entwickelten Whitfield Diffie und Martin Hellman auch das Konzept der Falltür (englisch trapdoor). Das ist eine „versteckte Abkürzung“ durch eine Zusatzinformation, mit der die ansonsten schwierige Umkehrung einfach gemacht wird. Auf der Basis von Falltürfunktionen lassen sich asymmetrische Verfahren entwickeln, bei denen die Übertragung eines geheimen Schlüssels nicht mehr notwendig ist. Damit leisteten sie auch wichtige Vorarbeiten zur Entwicklung des RSA-Kryptosystems. Ronald L. Rivest, Adi Shamir und Leonard Adleman versuchten eigentlich zu beweisen, dass es ebensolche Falltürfunktionen nicht geben kann. Bei den Beweisversuchen stießen sie jedoch tatsächlich auf eine solche Einwegfunktion mit Falltür. Das führte 1977 zur Entwicklung des berühmtesten Public-Key-Algorithmus, des nach den Initialen seiner Erfinder sogenannten RSA-Kryptosystems. [12]
ssh (scp) bieten die Möglichkeit, Verbindungen zwischen Computern aufzubauen, ohne das Passwort des anderen Users zu kennen.
Beide müssen dafür aber Keys vorher austauschen und die im Verzeichnis ~/.ssh speichern. Der private Key verbleibt beim "Quell-User" , der öffentliche erhält der "Ziel-User".
Wenn Quelle und Ziel getauscht werden, geht das dann auch bidirektional.
Wie man das genau einrichtet, kann ich erst in 4 Wochen sagen, da habe ich wieder Zugang zu meinen PC's
Das hat nicht speziell was mit SSH zu tun, sondern ist ganz allgemein eine Eigenart von Public-Key-Kryptographie.
Die Besonderheit dabei ist, dass hierbei immer Schlüsselpaare verwendet werden. Eine "Hälfte" des Schlüssels ist öffentlich (public key) und braucht nicht weiter geschützt zu werden. Die andere ist geheim (private key).
Der Trick ist nun, dass der Besitzer des privaten Schlüssels beweisen kann, dass er den zu einem öffentlichen Schlüssel gehörenden privaten Schlüssel besitzt. Und zwar ohne dabei seinen privaten Schlüssel herausgeben zu müssen! D.h. es geht dabei um die Authentisierung (den Beweis, dass jemand der ist, der er vorgibt zu sein).
Damit das funktioniert werden die beiden Schlüssel gemeinsam erzeugt, und zwar so, dass sie mathematisch gesehen die beiden Primfaktoren einer sehr großen Zahl darstellen. Große Primzahlen zu finden ist mathematisch effizient umsetzbar, die Primfaktorzerlegung großer Zahlen hingegen nicht.
Die symetrische verschlüsselung kennst du schon , das ist wenn zum verschlüsseln und entschlüsseln das selbe passwort benutzt wird .
das problem ist aber das wenn du was verschlüsselst und andere wollen das entschlüsseln das du dann das passwort dem anderen geben musst, sonst kann der es ja nicht entschlüsseln.
das problem ist aber das bei der übergabe des passwortes ein angreifer das passwort im schlechtesten fall mitbekommt , und es ist auch extrem nerfig ständig passwörter mit zu geben. zumal du dann ja einen anderen kanal nehmen musst, als den auf dem du das verschlüsselte schickst, also bei z.b. dateien , z.b. via SMS das passwort schicken.
nun haben sich mathematiker überlegt das es doch viel cooler wäre wenn man gar kein passwort mit geben muss um eine z.b. nachricht zu entschlüsseln .
der mathematische trick besteht daraus das man 2 passwörter erzeugt die von einander abhängen , das eine behälst du für dich und das ist dein privates passwort das du zum entschlüsseln nimmst und ein passwort was zu dem privaten passwort passt und öffentlich verteilt werden kann damit andere sachen für dich verschlüsseln können , also ein öffentliches "passwort" .
jeder der nun dieses öffentliche passwort nimmt um etwas für dich zu verschlüsseln kann das damit tun , die mathematik dahiner ist aber soooo cool, das das verschlüsselte nun nur noch mit deinem privaten passwort entschlüsselt werden kann, ergo nur du kannst das wieder entschlüsseln. das öffentliche passwort ist also nicht dazu gedacht etwas zu entschlüsseln, sondern nur zum verschlüsseln. und dein privates passwort ist nur zum entsschlüsseln und nicht zum verschlüsseln.
der vorteil ist du brauchst in diesem fall gar kein passwort mitgeben , der andere muss nur wissen wie dein öffentliches passwort heisst , das kann ruhig jeder wissen , weil damit kann man ja nur verschlüsseln und nicht entschlüsseln.
ergo muss jeder beteiligte so ein paar erzeugen. willst du ihm schreiben brauchst du seinen öffentlichen , will er dir schreiben brauch er auch nur deinen öffentlichen . jeder nutzt dann sein privaten um die nachricht zu entschlüsseln .
ob man das ding nun schlüssel oder passwort nennt ist für das verständnis egal . aber ich glaub passwörter ist einfacher zu verstehen .
es ist also ein mathematischer trick der das möglich macht . und damit da auch keiner mal eben so etwas durchprobieren kann sind diese passwörter extrem lang :)
genauso funktioniert das bei HTTPS oder SSH , damit du geheime nachrichten hin und her schicken kannst, brauchst du halt diese schlüsselpaare . ohne den jeweiligen geheimen "privaten" schlüssel wirst du nix entschlüsseln können und halt auch kein anderer der die verschlüsselte nachricht bekommt kann sie entschlüsseln , weil dazu brauch er dein privaten schlüssel..
Ok, wie genau wirkt sich das dann aber bei SSH auf die Anmeldung aus?
Dann braucht man beide, oder?
Also ich meine, wenn ich mich jetzt per SSH bei einem Linux Server verbinden möchte um z.B. einen Minecraft Server dort zu starten.
Ansonsten richtig gute Erklärung, vielen Dank. Das ist die einzige Frage, die mir noch geblieben ist :)
beim installieren deines SSH clients wird das schlüsselpar erzeugt , dein SSH server hat auch so ein paar erstellt.
wenn du also den client startest , schickt der sein öffentlichen schlüssel zum server und schickt dann schon mit deinem öffentlichen eine verschlüsselte antwort und schickt natürlich auch sein öffentlichen schlüssel .
da die meist selber erstellt wurde und keine prüfstelle genutzt wird , wird man darauf hingewiesen das der öffentliche schlüssel nicht verifiziert werden kann , da musst du das dann als ausnahme akzeptieren , kommt halt darauf ob das schlüsselpar von einer prüfstelle signiert wurde und verrifiziert werden kann , also das es einen 3 server gibt der sagt, ja dieser öffentliche schlüssel ist tatsächlich von dem server :) könnte ja sonst irgendein router etc dazwischen sonst den schlüssel einfach tuaschen und sich für den server ausgeben :)
faktisch wird aber nur das symetrische "eine" passwort mit der assymetrischen technik (also passwort paare) übertrage, und dann mit dem symetrischen weiter gearbeitet , den ein problem hat die asymetrische verschlüsselung , sie ist extrem langsam :) und erst wenn der Sichere KANAL besteht erst dann folgt der Login , das ist aber User / Passwort und hat nix mit der verschlüsselung für den kanal zu tun.
Das beschriebene ist Host Key Signing.
Ok, wie genau wirkt sich das dann aber bei SSH auf die Anmeldung aus?
Auf die Anmeldung wirkt sich das wie folgt aus:
Du hast deinen Pubkey am User des entfernten Servers hinterlegt; darum kannst du dich mittels deines privaten Keys (im SSH Connection String/Command mitzugeben) ohne Passwort am entfernten Server mit eben jenem User anmelden.
Dann braucht man beide, oder?
Du selbst brauchst technologisch erstmal nur den Private Key.
Vorteil und Sinn der ganzen Sache ist, dass man am SSH Daemon z.B. keine Passwort Logins mehr erlaubt. Passworte koennen erraten oder brute-forced werden. Ein private Key nicht *
also das SSH via KeyLogin ist mal was gaaanz anderes :) Und benötigt dann halt schon die übertragung des öffentlichen in den server .... das macht eigenlich kein provider . Hier ging es erstmal um das SSH secure protokoll , erst danach kann man so spezial dingens machen und dazu brauch es halt noch konfig am server . <
ich glaub da reden wir jetzt nicht von piffige minekraftserver die einfach nur via USER / Passwort erreicht werden , was aber beiden gemeinsam ist , der SECURe Kanal , der hat nix damit zu tun .
SSH unterstützt verschiedene Authentifizierungsmethoden. Du kannst dich also auch ganz herkömmlich per Passworteingabe anmelden.
Wenn du auf dem Server deinen Pubkey hinterlegst (bzw. der Admin das für dich tut), dann geht es eben auch ohne Passwort, über die Kenntnis des Private Keys (der auf deinem PC hinterlegt ist).
Aber: Sicherheitshalber sollten Private Keys auch passwortgeschützt sein. Dann musst du bei der ersten Verwendung einmalig das Paswort für die Key-Entschlüsselung eingeben, der Key wird dann im Arbeitsspeicher gehalten und muss erst nach einem Rechnerneustart erneut eigegeben werden.
und bei den meisten servern gibt es halt das fallback zu user/passwort . haha ich habs bei meinem mal ausgeschaltet und hatte mein key nicht gesichert , das war die zeit den server neu aufzusetzen :)
Und genau dafuer sind SSH Keys da ¯\_(ツ)_/¯
das macht eigenlich kein provider
Intern und bei managed machen das sogar die meisten Provider; man moechte einfach keine Passphrase Auth; vor allem nicht bei Usern mit administrativen Rechten.
Dazu kommt, dass die meisten IT Zertifizierungen das voraussetzen.
SSH Keys dienen der Authentifizierung; nicht dem Verschluesseln von Daten.