PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : ssh-spez. frage: Verschlüsselung...



Seiten : [1] 2

pablovschby
05.07.03, 01:29
Hallo

SSH: Host A schickt Host B unverschlüsselt seinen Public Key.....
Host B schickt dem Host A wiederum seinen PK....auch unverschlüsselt...

grundlegend geht es darum, dass niemand eine falsche Identität vorgeben kann, oder....niemand hat von Host A oder B den private key....das ist alles klar...aber:

besteht ein "man in the middle" .... bin ich aufgeschmissen....... ist ssh nichts mehr wert...absolut unsicher...denn:da beide public key's zuerst unverschlüsselt verschickt werden (um etwas verschlüsselt zu schicken, braucht der empfänger den entschlüsselungs-schlüssel....klar...) ...kann der "man in the middle" alles abhören... das einzige was er nicht kann, ist.... sich als "Host A" oder "Host B" ausgeben........stimmt das so?somit ist ssh absolut unsicher......

....denn jeder "man in the middle" sieht alle passwörter und loggt sich nachher schnell selbst am ssh-server als "Host C" (ihr versteht schon) an.....oder???

hab ich das in etwa so richtig verstanden ?
gruss&danke für alle antworten
pablo

Thomas
05.07.03, 02:48
Das SSH-Protokoll ist sehr sicher, das Verfahren ist gut gegen Angriffe abgesichert.
Jeder Rechner der an der SSH-Session teilnimmt hat einen dauerhaft gültigen sogenannten Host-Key. Bei der allerersten Verbindungsaufnahme mit einem Host wird der Fingerprint des Host-Keys der Gegenseite angezeigt. Um die Verbindung aufbauen zu können muss die Korrektheit des Fingerprints bestätigt werden. Um Gewissheit zu haben dass der Fingerprint stimmt kann man zum Beispiel den Admin des entfernten Hosts anrufen und sich den Fingerprint vorlesen lassen, dann hat man eine nahezu 100%ige Gewissheit, dass der Host-Key tatsächlich vom gewünschten Host ist.
Der Fingerprint wird abgespeichert und bei jeder erneuten Verbindungsaufnahme mit dem Fingerprint des übermittelten Host-Keys verglichen, falls die Fingerprints nicht übereinstimmen wird die Verbindung nicht aufgebaut und eine Warnung ausgegeben.

Der Session-Key, mit welchem die Verschlüsselung der Daten-Verbindung erfolgt, wird unter anderem mit dem Host-Key verschlüsselt und dann übertragen. Somit ist ein man in the middle-Angriff ausgeschlossen.

Für nähere Infos zu SSH finden sich gute Seiten im Internet.


Thomas.

pablovschby
06.07.03, 11:17
Original geschrieben von TThomas
Das SSH-Protokoll ist sehr sicher, das Verfahren ist gut gegen Angriffe abgesichert.
Jeder Rechner der an der SSH-Session teilnimmt hat einen dauerhaft gültigen sogenannten Host-Key. Bei der allerersten Verbindungsaufnahme mit einem Host wird der Fingerprint des Host-Keys der Gegenseite angezeigt. Um die Verbindung aufbauen zu können muss die Korrektheit des Fingerprints bestätigt werden. Um Gewissheit zu haben dass der Fingerprint stimmt kann man zum Beispiel den Admin des entfernten Hosts anrufen und sich den Fingerprint vorlesen lassen, dann hat man eine nahezu 100%ige Gewissheit, dass der Host-Key tatsächlich vom gewünschten Host ist.
Der Fingerprint wird abgespeichert und bei jeder erneuten Verbindungsaufnahme mit dem Fingerprint des übermittelten Host-Keys verglichen, falls die Fingerprints nicht übereinstimmen wird die Verbindung nicht aufgebaut und eine Warnung ausgegeben....tut mir leid....was ist der fingerprint=???? ist das der public key....und der private key bleibt beim host, oder was????

sorry, aber ich kenn nur public und private key....
Der Session-Key, mit welchem die Verschlüsselung der Daten-Verbindung erfolgt, wird unter anderem mit dem Host-Key verschlüsselt und dann übertragen. Somit ist ein man in the middle-Angriff ausgeschlossen.das stimmt ja nicht.... um etwas zu entschlüsseln, braucht man dazu einen public key.... und es muss alles zuerst unverschlüsselt verschickt werden....is ja logisch.... das heisst, dass jedes passwort... alles, was von a nach b übertragen wird,-...... ist problemlos auszulesen,... wenn die public-key (egal ob des Host KEy's oder des Session Key's)'s ausgelsen werden können.... und das kann der "man in the middle" problemlos..... von der logik her ja schon

für alles, was irgendwann verschlüsselt wird... muss zuerst ein key geschickt werden (unverschlüsselt), damit dann eine "verschlüsselte" verbindung bestehen kann...

schickt man nun ein passwort "verschlüsselt"..... kann der man in the middle problemlos alles auslesen, hier das passwort... ausserdem: wird ein "session key" verschlüsselt geschickt.... ist es ein witz.... (der public K der verschlüsselung musste bereits unverschlüsselt verschickt werden....)
Für nähere Infos zu SSH finden sich gute Seiten im Internet.....dann häng ich aber nicht am gleichen netz wie du...http://www.google.ch/search?hl=de&ie=UTF-8&oe=UTF-8&q=%22ssh+verschl%C3%BCsselung%22+informationen+abl auf&btnG=Google+Suche&meta=.....da findet man nix gscheites....nix aufschlussreiches...

wie gesagt: es ist mir klar....das es mit ssh absolut ausgeschlossen ist....... "einen falschen Host vorzumachen........das ist mir klar... der "man in the middle" bekommt ja NIE den private Key eines "host key's".,..............aber trotzdem....

.....es ist mir sehr unlogisch......... dass das "abhörsicher" sein sollte....

....das gegenteil ist eher logisch....denn für jede verschlüsselung... muss ich erst dem empfänger den "entschlüsselungs-key" unverschlüsselt .... schicken..... was zur folge hat... dass die einzige abhörsichere verschl. verbindung..... jene ist,.... wo ich meinem kollege... den public key meines hosts...per diskette .... übergebe
gruss&danke für alle antworten...leider findet man wiedermal nichts spezifisches zu dem thema übers netz
pablo

pablovschby
06.07.03, 11:22
ich schicke meinen public key des hosts A unverschlüsselt von a nach b..........host B schickt seinen public key unverschlüsselt von B nach A....dann schickt Host A den session key ...der session (is das public oder private???).........mit was verschlüsselt?????? mit dem private key des hosts A verständlicherweise......also hat der man in the middle auch den session key..... und mein passwort wird ausgelesen.... hab ich da was falsch verstanden?
gruss&danke
pablo

bitte versteht mich richtig...
Das SSH-Protokoll ist sehr sicher, das Verfahren ist gut gegen Angriffe abgesichert. das bestreite ich nicht....die frage ist nur: was mache ich für überlegungsfehler..... wo hat meine logik haken...? auch links sind natürlich hilfreich...da wirklich "gute sites" über ssh praktisch nirgens zu finden sind

also....infos gibts nirgens klare...und verständliche....
http://www.google.ch/search?q=%22ssh+verbindungsaufbau%22&hl=de&lr=lang_de&ie=UTF-8&oe=UTF-8&start=10&sa=N

HangLoose
06.07.03, 11:35
moin moin

kopier den key mittels scp, dann hast du eine verschlüsselte übertragung.

zu ssh gibt es doch reiflich infos im netz. nur mal ein beispiel

http://www.lrz-muenchen.de/services/security/ssh/


Gruß HL

pablovschby
06.07.03, 11:47
erstmal danke für die antwort, HL
Original geschrieben von HangLoose
moin moin

kopier den key mittels scp, dann hast du eine verschlüsselte übertragung.....sorry....aber ich kann damit nicht viel anfangen....anscheinend willst du mir damit sagen: jawohl, pablo...du hast recht..... ssh ist der letzte *******...und überhaupt nicht abhörsicher....tja..... ich wäre froh um eine solche antwort...
scp sei ein "programm", mir welchem man daten "sicher" übers netz kopieren könnte......mehr steht dazu auch net ...aber lassen wirs weg....es geht mal NUR ums ssh.... ausserdem
zu ssh gibt es doch reiflich infos im netz. nur mal ein beispiel

http://www.lrz-muenchen.de/services/security/ssh/ nach wie vor hänge ich glaubs immer noch am "Aminet" und nicht am "Internet"......???

tut mir leid...die site, .die du hier gepostet hat, sagt nichts grundlegendes, prinzipielles....verständliches zum verbindungsaufbau zu ssh aus...... (für leute, die nicht an der uni waren.... leute...die einfach logisch denken....)

ich suche eine site...die mir gaanz genau so die verbindung erklärt (bin noch net an der uni...sry):
1. pk des Host KEy's des Host A wird von da nach da verschickt...
2. ....das und dasy wird unverschlüsselt dort- und dorthin verschickt....
grundlegend gehts ja ums prinzip....in deinem betrag sagtest du eigentlich: jawohl, pablo, du hast recht.... jedes ssh-passwort ist so unsicher.... da wäre eine telnet-verbindung das gleiche
gruss&danke
pablo

pablovschby
06.07.03, 11:53
ich hab noch folgendes überlegt:
wenn host A dem host B seinen Public KEy unverschlüsselt schickt..... und Host B die Daten für Host A mit dem Public KEy des Host A verschlüsselt.....wäre die verbindung ja abhörsicher........denn Host B verschickt das Paket und nur der host mit dem private key kann das paket lesen!!! ....das wäre die lösung...also kann ja wohl meine version oben des ablaufes nicht ganz hinhauen, oder....? bei einem 128bit-schlüssel.....könnten pakete erst nach 3-4Jahren gelesen werden.....

aber wo finde ich eine seite...die mir schön den verbindungsaufbau...den schlüsseltausch einer ssh-verbindung (wer schickt wann was .....ver- oder unver-schlüsselt?...usw)vom prinzip und der logik her einfach erklärt...?
gruss&danke für alle antworten
pablo

mehlvogel
06.07.03, 11:53
tut mir leid...die site, .die du hier gepostet hat, sagt nichts grundlegendes, prinzipielles....verständliches zum verbindungsaufbau zu ssh aus.


LIest du hier (Seite 5): http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html#publish4.0.0.0.0.0



# Der SSH-Client kann nun überprüfen, ob er den Server kennt, indem er in Tabellen von bekannten Public-Keys nach dem gerade erhaltenen Host-Public-Key sucht.
Ist dieser Key noch nicht bekannt, teilt der Client dies dem Benutzer mit und fragt nach, ob die Verbindung trotz der Unsicherheit (die Identität des Servers kann ja nicht überprüft werden) aufgebaut werden soll.
Bei einer positiven Antwort trägt der Client den Server-Public-Key außerdem in eine individuelle Liste des Benutzers ein; bei der nächsten Verbindung ist dann der Remote-Rechner schon bekannt und der Client muß nicht mehr nachfragen.
Bei einer negativen Antwort des Benutzers hört der Client an dieser Stelle wie gewünscht auf.

# Der Client schickt dem Server eine 256 Bit lange Zufallszahl, die sowohl mit dem Host- als auch mit dem Server-Public-Key des Remote-Rechners verschlüsselt wurde.

# Ab sofort werden alle Daten der Verbindung verschlüsselt.


hoffe das hilft dir weiter.

pablovschby
06.07.03, 12:03
Original geschrieben von mehlvogel Der Client schickt dem Server eine 256 Bit lange Zufallszahl, die sowohl mit dem Host- als auch mit dem Server-Public-Key des Remote-Rechners verschlüsselt wurde. tut mir leid....aber eure seiten setzen ein riesen-wissen voraus....-.....und das ist ja das priblem.....

der client schickt dem server also eine 256bit lange zufallszahl.... (das ist was?????????? der public-key des hosts...? der public key der session?????? .... oder was ganz anderes....das begreift doch niemand....).....

ausserdem wird die nachricht mit dem "host-key des servers" und dem "public-server-key" verschlüsselt......es tut mir sehr leid....aber folgendes:es gibt den HOST KEY.... eine public-host-key...sowie einen private-host-key....es gibt für alle key's einen public und einen private key...

.....ich bin nach wie vor für weitere links zu haben....aber diese sites müssen verständlich sein (ich weiss, dass es diese sites praktisch nirgens gibt...)....

...ich wär halt froh, wenn ihr beachten würdet....die key's eindeutig zu definieren......denn es wird NIE ein "Host-key" enfach so verschickt.....es wird höchstens der public-host-key (das ist der public-key des hosts...) vverschickt......tja....
ausserdem: wie wird der an der anderes site entschlüsselt-.....

suche die anleitung, ...die mir eine solche verschlüsselung verständlich und "idiotensicher" erklärt.....mit allen schlüsseln
gruss&danke
pablo

HangLoose
06.07.03, 12:10
....sorry....aber ich kann damit nicht viel anfangen....anscheinend willst du mir damit sagen: jawohl, pablo...du hast recht..... ssh ist der letzte *******...und überhaupt nicht abhörsicher....tja..... ich wäre froh um eine solche antwort...

jawohl, pablo du hast nicht recht und ssh ist nicht der letzte sch... ;). du hast verschiedene möglichkeiten der authentifikation bei ssh. da wären z.b mittels password oder eben mittels key, wenn du nicht bei jeder verbindung dein password eingeben willst. beide *verbindungsarten* laufen verschlüsselt ab.

beim keyverfahren hast du nur das problem, wie kriegst du den key sicher von einer kiste zur nächsten. zu fuß per diskette, wie du es schon angesprochen hast oder eben mit scp.


Gruß HL

Thomas
06.07.03, 12:13
ich hab noch folgendes überlegt:
wenn host A dem host B seinen Public KEy unverschlüsselt schickt..... und Host B die Daten für Host A mit dem Public KEy des Host A verschlüsselt.....wäre die verbindung ja abhörsicher........denn Host B verschickt das Paket und nur der host mit dem private key kann das paket lesen!!! ....das wäre die lösung...also kann ja wohl meine version oben des ablaufes nicht ganz hinhauen, oder....? bei einem 128bit-schlüssel.....könnten pakete erst nach 3-4Jahren gelesen werden.....

pablo


Natürlich funktioniert das so! Sonst hätten deine "man in the middle"-fragen ja keinen Sinn.
Eben bei dem versenden des Public-Key könnte ein Dritter die Verbindung überwachen, den pubkey von A abfangen und an B einen eigenen pubkey schicken. Verschlüsselt nun B, dann kann der Dritte die Daten entschlüsseln und mit dem pubkey von A wieder verschlüsseln. Somit kann der "man in the middle" alle Daten mitlesen, ohne dass A oder B dies merken.
Aus diesem Grund ist es wichtig, einen dauerhaft gleichbleibenden Key zu haben, den Hostkey. Anhand dieses Keys ist es mögllich, einen Host eindeutig zu identifizieren, da der Session Key mit diesem Hostkey und dem Pubkey verschlüsselt wird. Somit ist eine Entschlüsselung des Sessionkeys nur vom gewollten Host möglich.

Thomas.

pablovschby
06.07.03, 12:17
Original geschrieben von HangLoose
jawohl, pablo du hast nicht recht und ssh ist nicht der letzte sch... ;). du hast verschiedene möglichkeiten der authentifikation bei ssh. da wären z.b mittels password oder eben mittels key, wenn du nicht bei jeder verbindung dein password eingeben willst. beide *verbindungsarten* laufen verschlüsselt ab.

beim keyverfahren hast du nur das problem, wie kriegst du den key sicher von einer kiste zur nächsten. zu fuß per diskette, wie du es schon angesprochen hast oder eben mit scp.


Gruß HL ja, ok,.....danke.....is ja klar......aber trotzdem:
wenn es so funktionieren würde.... dass Host B seine daten mit dem public key des Hosts A verschlüsselt.....kann ja nur derjenige mit dem private key......die daten lesen......klar```????

somit müsste der "man in the middle"....die verbindung aufzeichnen.... und bei meiner keygrösse (1024bit).....könnte er diese ausgelesenen daten erst nach etwa 10jahren lesen (erst dann konnte er den "private key" mit dem momentan schnellsten cluster der welt beider stationen knacken...)

....also wüsste der typ nach 10jahren, was ich heute für ein passwort hatte... was ich als "sicher" bezeichnen würde

funktioniert denn das so??????? gibts für den session-key auch en public und private key'???
gruss&danke
pablo

p.s: zur "authentifizierung":

entweder mit passwort oder host-key??????
was ist, wenn ich rsa aktiviert habe....und trotzdem ein pwd eingeben muss?????
welche option wäre in sshd_config zu setzen, damit die passwort-abfrage ausbleibt???
gruss&danke

HangLoose
06.07.03, 12:27
@pablo

dich kann ich mir richtig als kleines kind vorstellen => "papa warum ..." :D;)


so richtig tief bin ich in ssh auch noch nicht *hinab gestiegen* ;). soweit mir bekannt haben die beiden keys mit der verschlüsselten übertragung selbst nachher gar nichts mehr zu tun, sondern dienen nur der authentifikation.




entweder mit passwort oder host-key?????? was ist, wenn ich rsa aktiviert habe....und trotzdem ein pwd eingeben muss?????

du kannst den schlüssel nochmal zusätzlich mit einer passphrase schützen (hat nichts mit dem userpw zu tun)


welche option wäre in sshd_config zu setzen, damit die passwort-abfrage ausbleibt???

müßte ich auch erst nachsehen.


Gruß HL

pablovschby
06.07.03, 12:37
Original geschrieben von HangLoose
@pablo

dich kann ich mir richtig als kleines kind vorstellen => "papa warum ..." :D;) ja...ich weiss....aber eben...will halt alles genau wissen....hier:
Natürlich funktioniert das so! Sonst hätten deine "man in the middle"-fragen ja keinen Sinn....ok es funzt so...
Eben bei dem versenden des Public-Key könnte ein Dritter die Verbindung überwachen, den pubkey von A abfangen und an B einen eigenen pubkey schicken. Verschlüsselt nun B, dann kann der Dritte die Daten entschlüsseln und mit dem pubkey von A wieder verschlüsseln. Somit kann der "man in the middle" alle Daten mitlesen, ohne dass A oder B dies merken.
Aus diesem Grund ist es wichtig, einen dauerhaft gleichbleibenden Key zu haben, den Hostkey. Anhand dieses Keys ist es mögllich, einen Host eindeutig zu identifizieren, da der Session Key mit diesem Hostkey und dem Pubkey verschlüsselt wird. Somit ist eine Entschlüsselung des Sessionkeys nur vom gewollten Host möglich. HHHAAAAALLLLLLTTT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!! (will dich nicht beleidigen.....sondern stoppen.....vielleicht "ein bischen" anschreien.............aber "erhöre mich":erbitte erklärung...was der host-key ist....
erbitte erklärung..... was für einen public key du meinst....
denn...es gibt nach wie vor keinen "host-key"...es gibt zwei...also einen public und einen private....
ssession key=was?????? gibts da auch en pub und en priv-key???
gruss&danke
pablop.s.: um nochmals alles genau so zu schreiben, wie ichs verstanden habe....eine verständliche erklärung:a schickt b seinen host-public-key....unverschlüsselt
b schickt a seinen host-public-key verschlüsselt mit dem public-host-key des hosts A...
a entschlüsselt das paket mit seinem private key....

von jetzt an verschlüsselt a daten mit dem public-host-key von b
b entschlüsselt die daten mit seinem private key...
b verschl. daten mit dem public-host-key von host A....
host a entschlüsselt daten mit seinem private key....... diese beschreibung einer ssh-verschlüsselungh wäre meines erachtens "verständlich für jeder......also "idiotensicher"......"..... jheder begreits..

....aber wo kommt nun der "session key" ins spiel? (public- oder private-session-key----)

gruss&danke für alle tipps
pablo

HangLoose
06.07.03, 12:52
hier noch 2 links

http://www.informatik.uos.de/elmar/talks/SSH/09_Verbindung.rtfd/index.html#.0.
http://www.informatik.uos.de/elmar/talks/SSH/index.rtf.html


Gruß HL

Thomas
06.07.03, 13:02
Die Optionen in der sshd_config sind:
PubkeyAuthentication yes
PasswordAuthentication no

Jetzt, zum letzten Mal, der Verbindungsablauf:


SSH-Request an Host B (wir sind Host A)
Host B schickt seinen HostKey (den Public-Teil) sowie seinen ServerKey (den Public-Teil) an uns
der von Host B empfangene Hostkey wird überprüft: Ist der HostKey des Servers (Host B) schon in meiner known_hosts-Datei eingetragen? Sprich: Wurde die Korrektheit des Hostkeys dieses Servers schon überprüft? Falls JA geht es weiter, falls NEIN wird der Fingerprint (das ist ein Hash des empfangenen Keys) des Keys angezeigt, welcher z.B. per Telefon oder einem anderen sicheren Kommunikationskanal überprüft werden sollte. Wird der Fingerprint bestätigt, wird der Hostkey in die known_hosts-Datei eingetragen und es geht weiter, falls der Fingerprint nicht bestätigt wird, wird die SSH-Verbindung abgebrochen.
Ein Session-Key (eine 256-Bit Zufallszahl) wird bei uns (Host A) erstellt. Mit diesem Session Key wird die tatsächliche SSH-Verbindung nach der Verbindungsaufnahme verschlüsselt. Dieser Key ist für symmetrische Verschlüsselung (Performance-Gründe).
Der Session-Key wird mit dem vom Server (Host B) empfangenen Server-Key und mit dem Host-Key des Servers (Host B) verschlüsselt und dann an der Server (Host B) übertragen.
Nun hat sowohl der Server als auch wir den Session-Key, mit welchem die SSH-Verbindung ab jetzt verschlüsselt wird.


Also, nochmals zusammenfassend:
Der Host-Key des Servers bleibt immer gleich. Anhand dieses Keys kann eindeutig die Authentizität des entfernten Hosts nachgewiesen werden. Somit ist der "man in the middle"-Angriff ausgeschlossen, aber nur wenn man die Fingerpints gewissenhaft überprüft und nicht "mal eben" ein yes eintippt...


Ich hoffe dass das SSH-Protokoll für dich jetzt etwas durchsichtiger geworden ist!


Thomas.

pablovschby
06.07.03, 13:12
Original geschrieben von TThomas
Die Optionen in der sshd_config sind:
PubkeyAuthentication yes
PasswordAuthentication nodank dir......password hat also nix mit dem linux-shell-user-pwd zu tun, oder?
Jetzt, zum letzten Mal, der Verbindungsablauf:


SSH-Request an Host B (wir sind Host A)
Host B schickt seinen HostKey (den Public-Teil) sowie seinen ServerKey (den Public-Teil) an uns
der von Host B empfangene Hostkey wird überprüft: Ist der HostKey des Servers (Host B) schon in meiner known_hosts-Datei eingetragen?sry...aber hier redest du vom "hostkey des servers".....oben meintest du: ServerKey und Hostkey......na, ....welcher meinst du nun...?
Sprich: Wurde die Korrektheit des Hostkeys dieses Servers schon überprüft?...der hostkey des servers....mmhmh....ist das nun der hostkey oder der serverkey des hosts...mhmhm ...das weiss ich jetzt net..
Falls JA geht es weiter, falls NEIN wird der Fingerprint (das ist ein Hash des empfangenen Keys) des Keys angezeigt, welcher z.B. per Telefon oder einem anderen sicheren Kommunikationskanal überprüft werden sollte.....sorry...ich bin nur am internet angeschlossen...und einer, der über ISDN oder ADSL ans i-net angeschlossen ist.....hat auch nur eine leitung......wieder versteh ich nicht ganz....wird da schnell über das telefon dem anderen angerufen, oder wie???
Wird der Fingerprint bestätigt, wird der Hostkey in die known_hosts-Datei eingetragen und es geht weiter, falls der Fingerprint nicht bestätigt wird, wird die SSH-Verbindung abgebrochen......fingerprint=fingerabdruck eines keys....also wie eine md5-checksumme........
von wem wird der dann bestätigt??? von host b???
Ein Session-Key (eine 256-Bit Zufallszahl) wird bei uns (Host A) erstellt. Mit diesem Session Key wird die tatsächliche SSH-Verbindung nach der Verbindungsaufnahme verschlüsselt. Dieser Key ist für symmetrische Verschlüsselung (Performance-Gr...--....also nehm ich an, der (ssh-)server erstellt ihn...?

Der Session-Key wird mit dem vom Server (Host B) empfangenen Server-Keys und mit dem Host-Key des Servers (Host B) verschlüsselt und dann an der Server (Host B) übertragen.
Nun hat sowohl der Server als auch wir den Session-Key, mit welchem die SSH-Verbindung ab jetzt verschlüsselt wird.

Also, nochmals zusammenfassend:
Der Host-Key des Servers bleibt immer gleich. Anhand dieses Keys kann eindeutig die Authentizität des entfernten Hosts nachgewiesen werden. Somit ist der "man in the middle"-Angriff ausgeschlossen, aber nur wenn man die Fingerpints gewissenhaft überprüft und nicht "mal eben" ein yes eintippt..also wenn ich nein eingebe..... wird die "fingerprint"-checksum berechnet... und mit der empfangenen von host b verglichen, oder?

das ist ja keine sicherheit...wenn der key richtig übertragen wird, ...stimmt auch jede checksumme überein...
Ich hoffe dass das SSH-Protokoll für dich jetzt etwas durchsichtiger geworden ist! dank dir vielmals....aber eben

mir muss alles....prinzipiell erklärbar sein...sonst lass ich halt net locker.....
gruss&danke
pablo

Thomas
06.07.03, 13:17
Denk darüber nach was ich geschrieben habe und lese gegebenfalls im Internet nach, ich habe dir eine absolut vollständige und verständliche Erklärung geliefert.

Zum Server-Key des entfernten Hosts: Du verbindest dich via SSH zu einem SSH-Server. Jeder SSH-Server hat einen Hostkey, welcher sich nie verändert (ausser der Admin will das...). Der Server-Key ist ein stündlich neu erzeugter Key für asymmetrische Verschlüsselung (welcher am SSH-Server erzeugt wird), mit welchem der Session-Key verschlüsselt und übertragen wird.


Thomas.

pablovschby
06.07.03, 13:29
Original geschrieben von TThomas
Denk darüber nach was ich geschrieben habe und lese gegebenfalls im Internet nach, ich habe dir eine absolut vollständige und verständliche Erklärung geliefert.

Zum Server-Key des entfernten Hosts: Du verbindest dich via SSH zu einem SSH-Server. Jeder SSH-Server hat einen Hostkey, welcher sich nie verändert (ausser der Admin will das...). Der Server-Key ist ein stündlich neu erzeugter Key für asymmetrische Verschlüsselung (welcher am SSH-Server erzeugt wird), mit welchem der Session-Key verschlüsselt und übertragen wird.


Thomas. naja...für "ausgelehrnte" würd ich sagen....aber eben
ich dank dir...werd mal lesen....aber auch fragen
gruss&danke
pablo

pablovschby
06.07.03, 13:32
tatsache ist.....dass man besser zuerst an die uni oder sonstwo geht, als beispielweise zuerst zu lernen, was ein fingerprint sein soll

weltweit.....keine verständlichen info's:http://www.google.ch/search?q=fingerprint+einfach+erkl%C3%A4rung+ssh&hl=de&lr=&ie=UTF-8&oe=UTF-8&start=10&sa=N.....alle
reden auf einem niveau........was ein "normaler mensch" nur mit etlichen schulungen und ausbildungen verstehen könnte

...nirgens eine klare (einfache) erklärung, was ein firngerprint sein soll
gruss&danke
pablo

p.s.: das sollte hier an keinen ein vorwurf sein.... einige denken so, einige denken so....aber sicher isst der satz falsch: dass dazu (verständliche) info's auch findbar sind

mehlvogel
06.07.03, 13:36
So, nochmal ganz in Ruhe:

Stellen wir uns es gibt Rechner Bimmel und Rechner Bammel, du sitzt an Rechner Bimmel und ich an REchner Bammel. Du möchtest jetzt auf meinen Rechner per ssh zugreifen, das heißt Bimmel ist der CLient und Bammel der Server.

Also stellt dein Rechner eine Anfrage an meinen Rechner.
Mein Rechner sendet dir darauf hin den Hostkey und den Serverkey. (Zur erinnerung - Serverkey stündlich neu / Hostkey für die Ewigkeit).
Nun prüft dein Rechner ob er den Hostkey schon kennt (ob er in der Datei known_hosts ist). Ist er das nicht zeigt er dir den Fiungerprint an. Nun rufst du mich an (oder gehst zu mir rüber) und fragst mich ob der Fingerprint richtig ist. Ist er das tippselst du YES ein und es geht weiter. (Natürlich kannst du auch ohne mich anzurufen und zu fragen YES eingeben, dann weisst du aber nich 100%ig ob ein man in the middle dazwischen hockt).
Nun erstellt dein Rechner den sog. Sessionkey (diese 256bitlange Zufallszahl) verschlüsselt ihn mit host und serverkey (am anfang übertragen) und sendet ihn mir zu.

Ab jetzt wird die Verbindung mit dem Sessionkey verschlüsselt, den ja beide haben.

PS: Ich beschäftige mich auch erst seit diesem Thread genauer mit der Materie und erhebe deshalb keine ANspruch auf 100%ige Richtigkeit, evtl. könnte das geschrieben noch jemand bestätigen?


geschrieben von TThomas: Das ist soweit alles korrekt. By the way: Habe ich nicht das selbe geschrieben? :ugly:
geschrieben ovn Mehlvogel: Ja - aber so ein Beispiel find ich anschaulicher und evtl. versteht es pablo so besser? :ugly:

Thomas
06.07.03, 13:37
Wie schon geschrieben: Ein Fingerprint ist so etwas wie ein Hash.

Falls jetzt die Frage kommt: "Wie wird ein Hash erstellt?"
Siehe RFC 1321.

pablovschby
06.07.03, 14:03
Original geschrieben von mehlvogel
So, nochmal ganz in Ruhe:

Stellen wir uns es gibt Rechner Bimmel und Rechner Bammel, du sitzt an Rechner Bimmel und ich an REchner Bammel. Du möchtest jetzt auf meinen Rechner per ssh zugreifen, das heißt Bimmel ist der CLient und Bammel der Server.

Also stellt dein Rechner eine Anfrage an meinen Rechner.
Mein Rechner sendet dir darauf hin den Hostkey und den Serverkey. (Zur erinnerung - Serverkey stündlich neu / Hostkey für die Ewigkeit). alles klar bis hierhin....
Nun prüft dein Rechner ob er den Hostkey schon kennt (ob er in der Datei known_hosts ist). Ist er das nicht zeigt er dir den Fiungerprint an. Nun rufst du mich an (oder gehst zu mir rüber) und fragst mich ob der Fingerprint richtig ist. Ist er das tippselst du YES ein und es geht weiter. (Natürlich kannst du auch ohne mich anzurufen und zu fragen YES eingeben, dann weisst du aber nich 100%ig ob ein man in the middle dazwischen hockt). sorry.....habe noch nie einen "hash" auf den bil.dschirm bekommen, bevor ich "yes", "no" oder "cancel" wählen konnte... (beispiel: putty)........bei linux.-..ok,.....dort stimmts...
Nun erstellt dein Rechner den sog. Sessionkey (diese 256bitlange Zufallszahl) verschlüsselt ihn mit host und serverkey (am anfang übertragen) und sendet ihn mir zu.alles klaro...
Ab jetzt wird die Verbindung mit dem Sessionkey verschlüsselt, den ja beide haben. ....ok........also mit dem session key kann ver- und wieder ent-schlüsselt werden,...oder? .ist der sessionkey dann dafür gemacht? ....also beim sessionkey gibts keine public und keine private-keys mehr.....ein key zur ent- und de-schlüsselung....ok
PS: Ich beschäftige mich auch erst seit diesem Thread genauer mit der Materie und erhebe deshalb keine ANspruch auf 100%ige Richtigkeit, evtl. könnte das geschrieben noch jemand bestätigen?.....ok...danke..für den einssatz....

gruss&danke
pablo


p.s.: ....also........ich habe gesucht..und gefunden, was ich erwartete: NICHTS
http://www.google.ch/search?hl=de&ie=UTF-8&oe=UTF-8&q=rfc1321+hash+erkl%C3%A4rung&btnG=Google+Suche&meta=lr%3Dlang_de

auf deutsch findet man KEINE klare beschreibung, was ein "Hash" sein solll...tut mir leid.....wär um en link froh (du behauptest ja, das sei da irgendwo draussen "verständlich" beschrieben...)

wisnitom
06.07.03, 14:11
hi,

lese dir bitte mal die security reihe bei www.tecchannel.de durch.

grüsse,

pablovschby
06.07.03, 14:17
Hash-Funktionen sind in der Informatik seit langem bekannt. Sie dienen beispielsweise bei Datenbank-Anwendungen zur einfachen Indizierung und somit dem schnellen Wiederauffinden von Informationen. Dazu fassen sie umfangreiche Informationen - wie etwa Kundennamen - durch Bilden irgendeiner Art von Quersumme zu einer komprimierten, leichter verwaltbaren Information zusammen. Letztere nennt man den Hash-Wert der Information. Die verwendete Hash-Funktion muss natürlich sicherstellen, dass für verschiedene Eingangsinformationen auch hinreichend unterschiedliche Hash-Werte entstehen. war mir alles schon längst völlig klar
Solche Hashes lassen sich auch gut zur Authentifizierung und Signatur einsetzen, falls der verwendete Algorithmus zwei zusätzliche Kriterien erfüllen kann. Zum einen darf es nicht möglich sein, mit vertretbarem Aufwand aus dem Hash-Wert die Originalinformation zu rekonstruieren. Zum Zweiten muss es aus Gründen der Fälschungssicherheit ausgeschlossen sein, mit vertretbarem Aufwand aus einer gegebenen Originalinformation eine zweite Information zu generieren, die denselben Hash-Wert ergäbe ("Kollision").

Einweg-Hash-Funktionen werden unter anderem auch als Kompressionsfunktion, Message Digest, kryptographische Prüfsumme oder Message Integrity Check (MIC) bezeichnet. Schon daraus lässt sich das breite Einsatzspektrum ersehen. Da Einweg-Hash-Funktionen für jedermann berechenbar sein sollen, verwenden sie keine geheimen Schlüssel. Den Hash-Wert einer Einweg-Funktion bezeichnet man als Message Authentication Code (MAC). es wird nirgens erklärt........was ein "fingerprint" sein soll...is ja klar....die gehen auf die "biometrische" auth per fingerabdruck ein und nicht auf diesen fingerprint....aber....

ein hash ist... aus gewissen daten eine checksumme....das ist mir absolut klar
aber aus was ist denn der fingerprint ein hash===?????

aus der hardware des clients? aus den keys des clients?
aus was ist der fingerprint ein hash?
ich bedanke mich für alle links.....
gruss&danke
pablo

p.s.: ich habe bereits oben erwähnt, ....d ass ein fingerprint nix anderes ist, als eine "billige" md5-checksumme....tja.....dann hab ichs wohl begriffen und das falsche gefragt...

aus was für daten wird der hash "fingerprint" bei ssh erstellt?

Thomas
06.07.03, 14:24
Der Fingerprint ist der Hash, welcher sich aus dem Hostkey ergibt.

pablovschby
06.07.03, 14:26
Original geschrieben von TThomas
Der Fingerprint ist der Hash, welcher sich aus dem Hostkey ergibt. ok, danke......ich frage mich nur: was bringt das?????

das wär ja net sicher......(wie von mir schon erwähnt).....
nein....is klar...

.....da interessiert nur: der hash muss stimmen, sonst hat der nicht den hostkey....obwohl es ja auch der hoistkey, sowie der hash des "man in the middle3" sein könnte........
gruss&danke
pablo

Thomas
06.07.03, 14:31
Um auszuschließen, dass es der Hash des "man in the middle" ist, musst du einen vertrauenswürdigen Kommunikationskanal zur Verifizierung des Hashs benutzen, zum Beispiel das Telefon.

pablovschby
06.07.03, 14:37
von mir nun nochmals:

Rechner X und Rechner Y.....Rechner Y ist der ssh-client

1. Y schickt X eine Anfrage...
2. X schickt Host und ServerKey (Publi-teil)
3. Y checkt, ob der Hostkey des Servers schon in seiner known_hosts ist.....

3. ja, der key ist in "known_hosts"-->....weiter zu nummer 4
3. NEIN-->key ist nicht in known_hosts-->weiter zu 3.1

3.1. -->fingerprint des lokal gespeicherten HOSTKEY's (pub-teil) von Host X wird angezeigt....und weiter unten wird der fingerprint des (jetzt gerade) neu angefragten fingerprints des HOSTKEY's(pub-teil) von Host X angezeigt..... (konnte ich bisher noch nicht praktisch so testen...ob des wirklich so ist...)
3.2. -->fingerprint wird verglichen (mit auge) und wenn gleiche---> eingabe: yes....weiter zu 4
4. Host Y erstellt den asymetrischen (also gleicher schlüssel zum ver- und ent-schlüsseln)....SESSIONKEY
5. Host Y schickt Host X (mit HOSTKEY (pub-teil) des Host Y verschlüsselt) den 256bit-session key

von nun an ist die verbindung mit dem sessionkey verschlüsselt.....hurra!!!!

1. frage: also·....bekommt der ssh-server NIE den pub-teil des hostkeys des Host Y???
2. frage: werden somit also alle fingerprint's und auch der pub-teil des hostkeys des servers unverschlüsselt verschickt???
3. frage: wie kann ich dem sshd_config sagen, dass SESSIONKEY's mindestens 1024bit lang sein sollen?

4. frage: was zum geier soll der fingerprint für einen nutzen haben???????

wenn ein man in the middle besteht....schickt der einfach sein fingerprint rüber...und der istr gleich wie der fingerprint seines hostkey......also ich verstehe hier (noch) nicht, was das für einen sinn macht..
gruss&danke
pablo

pablovschby
06.07.03, 14:39
Original geschrieben von TThomas
Um auszuschließen, dass es der Hash des "man in the middle" ist, musst du einen vertrauenswürdigen Kommunikationskanal zur Verifizierung des Hashs benutzen, zum Beispiel das Telefon. du meinst....damit...dass der typ dir den hash gibt....übers telefon und du ihn dann an seiner stimme erkennen kannst.....meinst du das????? besser wäre noch eine diskette???
gruss&danke
pablo