staging.inyokaproject.org

lubux schrieb:

Nein, es ist der öffentliche Schlüssel des Clienten, denn:

Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte...> 

Der Abschnitt, den Du zitierst, bezieht sich auf die Authentifizierung des Nutzers mit public-key.

Der Satz, den ich für falsch halte, steht im Abschnitt deutlich weiter oben im Artikel, in dem es um die Identifizierung des Servers gegenüber dem Nutzer geht. Hier geht's damit los:

Woher weiß man nun aber, dass man tatsächlich mit dem richtigen Rechner verbunden ist, und nicht ein Angreifer die Verbindung umgeleitet hat? 
Dafür gibt es den Host-Schlüssel, der jeden SSH-Server eindeutig identifiziert. ...

Der Server gibt beim ersten Kontakt seinen öffentlichen Schlüssel raus (gespeichert in ~/.ssh/known_hosts des Nutzers) und bei weiteren Kontakten identifiziert er sich mittels digitaler Signatur mit seinem privaten Schlüssel.

Unabhängig davon erfolgt die Authentifizierung des Nutzers über Passwort oder Public-Key:

Der (oder die) öffentliche(n) Schlüssel des Benutzers befindet sich dabei in der Datei ~/.ssh/authorized_keys des Zielsystems, 
der private Schlüssel in einer Datei (meist id_rsa) im Verzeichnis ~/.ssh auf dem lokalen System ...

Einmal geht es also um das Schlüsselpaar des Servers, einmal um das des Nutzers. Und in beiden Fällen gibt der Besitzer natürlich nur seinen öffentlichen Schlüssel heraus und behält den privaten bei sich.

Happy Penguin schrieb:

lubux schrieb:

Nein, es ist der öffentliche Schlüssel des Clienten, denn:

Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte...> 

Der Abschnitt, den Du zitierst, bezieht sich auf die Authentifizierung des Nutzers mit public-key.

Der Abschnitt den ich zitiert habe, hat etwas mit deinem Beitrag vom 27. Oktober 2015, 21:51 Uhr in diesem Thread zu tun.

Happy Penguin schrieb:

Dafür gibt es den Host-Schlüssel, der jeden SSH-Server eindeutig identifiziert. ...

Wo steht es, dass dieser Host-Schlüssel (des Servers) ein öffentlicher Schlüssel ist?

Happy Penguin schrieb:

Der Server gibt beim ersten Kontakt seinen öffentlichen Schlüssel raus ...

Einmal geht es also um das Schlüsselpaar des Servers, einmal um das des Nutzers. Und in beiden Fällen gibt der Besitzer natürlich nur seinen öffentlichen Schlüssel heraus und behält den privaten bei sich.

Wie und wo generiert man das Schlüsselpaar des Servers und wo bzw. wie werden welche Schlüssel des Servers abgelegt?

lubux schrieb:

Der Abschnitt den ich zitiert habe, hat etwas mit deinem Beitrag vom 27. Oktober 2015, 21:51 Uhr in diesem Thread zu tun.

Insofern, als er im selben langen Wiki-Artikel steht ...

In meinem ursprünglichen Beitrag zitiere ich den Satz, der mir falsch erscheint, und der in einem völlig anderen Abschnitt steht und ein gänzlich anderes Thema behandelt (Identifikation des Servers, nicht Authentifizierung des Nutzers).

Wo steht es, dass dieser Host-Schlüssel (des Servers) ein öffentlicher Schlüssel ist?

Wie nennst Du den Schlüssel eines Schlüsselpaares, der an jeden verteilt wird? Auch der Wiki-Artikel verwendet diesen Begriff, nur leider halt einmal (meiner Meinung nach) falsch (markiert):

dass der Server auch über den richtigen öffentlichen Schlüssel verfügt, 
der zum öffentlichen, in der Datei ~/.ssh/known_hosts abgelegten passt

Wie und wo generiert man das Schlüsselpaar des Servers und wo bzw. wie werden welche Schlüssel des Servers abgelegt?

Aus der manpage zu "ssh-keygen": "Additionally, the system administrator may use this to generate host keys." Wird vermutlich bei Installation des SSH-Serverpakets erledigt.

Die Schlüssel liegen dann in /etc/ssh/ssh_host_*_key auf dem Server bzw. (so steht's auch im Wiki-Artikel 😉) der öffentliche Host-Schlüssel in der Datei ~/.ssh/known_hosts des Anwenders.

Wird vermutlich bei Installation des SSH-Serverpakets erledigt.

Ja, sieht man bei apt-get.

Habe bei der Beschreibung der Einrichtung eines PublicKey-Verfahrens einen Absatz in eine Hinweisbox ausgelagert (Thema Rechte setzen von ~/.ssh usw unter Ubuntu Precise). Da ist auch noch eine Befehlsbox integriert. Irgendwie funktioniert das Verschachteln der Boxen aber nicht. Bitte um Korrektur.

Hallo,

Da ist auch noch eine Befehlsbox integriert. Irgendwie funktioniert das Verschachteln der Boxen aber nicht. Bitte um Korrektur.

Done. In Man kann in der Tat nicht zwei Elemente verschachteln, die mit {{{ beginnen. Das geht dann anders ☺

Gruß, noisefloor

Meine Frage hat sich erledigt, die letzte Änderung ist doch korrekt.

Danke an random-access für die Korrektur des Wikiartikels.

Die letzte Änderung ist falsch. Aber der ganze Abschnitt ist von vornherein Murks. Am besten erst mal zurückrollen.

Benno-007 schrieb:

Die letzte Änderung ist falsch. Aber der ganze Abschnitt ist von vornherein Murks. Am besten erst mal zurückrollen.

Das dachte ich am Anfang auch, aber in diesen Abschnitt müsste es so richtig sein.

Vielleicht - kann das jemand erklären?

Ich bin eigentlich der Meinung, der private Key hat nur was auf meinem PC verloren! Und wenn da irgendwas abgeglichen wird, dann ja wohl mit dem öffentlichen Key auf meinem PC und bestimmt nicht mit meinem privaten auf dem Server. Da könnte ja jeder Serverbetreiber meinen Key krallen und auf alle andren Server mit selbem Key zugreifen - ist dem wirklich so?

Hier ist die Rede vom /etc/ssh/ssh_host_ecdsa_key auf dem Server.

Natürlich versende ich meinen öffentlichen Schlüssel an den Server, der damit Nachrichten verschlüsselt, die nur ich mit meinem privaten Schlüssel auf meinem PC entschlüsseln kann.

Genauso schickt mir aber der Server seinen öffentlichen Schlüssel, mit dem ich die Nachrichten an ihn verschicken kann. Das ist der besagte ecdsa-key, den ich mit Hilfe des Fingerprints überprüfe, und wenn ich die Authentizität bestätige, kommt dieser öffentliche Schlüssel in die Datei ~/.ssh/known_hosts zusammen mit der IP-Adresse des Servers.

Wenn ich nun das nächste mal mit dieser IP-Adresse Kontakt aufnehme, dann wird der in der known_hosts abgelegte Schlüssel mit dem vom Server gesendeten verglichen, und nur wenn diese übereinstimmen, wird die Verbindung hergestellt. Ansonsten gibt es die Fehlermeldung, dass die Schlüssel nicht übereinstimmen

$ ssh 127.0.0.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
a4:24:bc:03:4b:6f:0a:96:fb:0a:c1:09:33:c7:a7:45.
Please contact your system administrator.
Add correct host key in /home/stepfahn/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/stepfahn/.ssh/known_hosts:11
  remove with: ssh-keygen -f "/home/stepfahn/.ssh/known_hosts" -R 127.0.0.1
ECDSA host key for 127.0.0.1 has changed and you have requested strict checking.
Host key verification failed.

Indirekt prüft das SSH-Programm also tatsächlich, ob der Server über den richtigen privaten Schlüssel verfügt, um die Nachrichten, die ich mit seinem öffentlichen Schlüssel verschlüssele, zu entschlüsseln.

Klarer wäre aber zu sagen, dass der öffentliche Schlüssel von nun an mit dem in der Datei known_hosts verglichen wird, und bei Unterschieden die Verbindungsaufnahme verweigert.

Habe abends tatsächlich nur Zeit für das kurze diff gehabt - klingt logisch, was du erklärst. Müsste man sehn, ob das dort auch so rüberkommt.

Nur den letzten Absatz verstehe ich nicht richtig, weil ja dann jeder Server den öffentlichen Schlüssel eines anderen nehmen könnte, um sich ganz ohne privaten Schlüssel als dieser andere auszugeben, was ja damit verhindert werden soll.

Benno-007 schrieb:

Nur den letzten Absatz verstehe ich nicht richtig, weil ja dann jeder Server den öffentlichen Schlüssel eines anderen nehmen könnte, um sich ganz ohne privaten Schlüssel als dieser andere auszugeben, was ja damit verhindert werden soll.

Ja, jeder Server kann sich ohne Probleme als ein anderer ausgeben, indem er dessen öffentlichen Schlüssel versendet (der ja auch jedem zugänglich ist).

Das nutzt ihm aber gar nichts, denn ohne den privaten Schlüssel kann er ja die empfangenen Daten, die ja genau mit diesem öffentlichen Schlüssel verschlüsselt wurden/werden, nicht entschlüsseln. Das kann nur der Server, der den passenden privaten Schlüssel hat.

Und er kann uns keine von ihm verschlüsselten Daten unterschieben, da diese sich nicht mit dem fälschlicherweise benutzten öffentlichen Schlüssel dekodieren lassen.

Das Ver- und Entschlüsseln funktioniert nur, wenn beide den passenden Teil aus dem Schlüsselpaar benutzen.

Hmmm. 👍

Beim Abschnitt scp fehlt die Angabe, dass nur ein Server zum kopieren ausreichend ist. Beispiele sind etwas kurz gekommen. 😉

Wobei der Artikel mit Beispielen unter Umständen lang werden könnte, daher ist ein eigenständiger Artikel empfehlenswert?

Dazu noch eine Verlinkung zum Artikel rsync, als Erklärung. Etwa an der Stelle mit "(man beachte die Handbuchseite zu diesem Tool)", was auch immer mit dem Satz gemeint ist ☺.