staging.inyokaproject.org

Fehler in "Authentifizierung über Public-Keys"

Hallo,

ich vermute einen Fehler im Beispiel für ssh-copy-id :

es wird einen privaten Schlüssel übertragen!!!

Ist:

1

user@client:~$ ssh-copy-id -i ~/.ssh/id_rsa user@server

Soll:

1

user@client:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

Genau so im weiteren Skript

Ist:

1

ssh-copy-id -i ~/.ssh/id_rsa '-p 12345 user@server'

Soll:

1

ssh-copy-id -i ~/.ssh/id_rsa.pub '-p 12345 user@server'

Erfahrene Kollege bitte prüfen und korrigieren!

Gruß Pavel

Gruß Pavel

Hallo!

Ich habe den Betreffenden zwar bereits angeschrieben, doch die Sache ist etwas hässlich und sollte besser erwähnt werden.

Im Artikel SSH wurde letzten April offensichtlich an zwei Stellen ein Fehler eingeschleust, der mir eben aufgefallen ist.

Bei den Beispiel-Befehlen mit "ssh-copy-id" wird aktuell der private Schlüssel übertragen, statt der öffentliche.

Das ist eben kein kleiner Fehler sondern recht schei*e, da jetzt möglicherweise paar private keys nicht mehr nur da sind, wo sie hingehören.

Daher wollte ich es zusätzlich hier mal erwähnen...

Gruß sausix

sausix schrieb:

Im Artikel SSH wurde letzten April offensichtlich an zwei Stellen ein Fehler eingeschleust, der mir eben aufgefallen ist.

Nicht April, sondern bereits im Maerz 2014... ☹ Und peinlicherweise wurde der Fehler bereits erkannt, aber leider nicht korrigiert 👿

Bei den Beispiel-Befehlen mit "ssh-copy-id" wird aktuell der private Schlüssel übertragen, statt der öffentliche. Das ist eben kein kleiner Fehler sondern recht schei*e, da jetzt möglicherweise paar private keys nicht mehr nur da sind, wo sie hingehören.

Vorlaeufig gefixt, aber da ist wohl ein kompletter Audit des Artikels faellig. Aber schon mal ein grosses Dankeschoen fuers aufmerksame Lesen ☺

Laut man soll .pub ja automatisch angehangen werden:

     -i identity_file
             Use only the key(s) contained in identity_file (rather than looking for identities via ssh-add(1) or in the
             default_ID_file).  If the filename does not end in .pub this is added.  If the filename is omitted, the
             default_ID_file is used.

             Note that this can be used to ensure that the keys copied have the comment one prefers and/or extra options
             applied, by ensuring that the key file has these set as preferred before the copy is attempted.

Bedeuten die Einwände, dass das vom Leser nicht beachtet wurde oder dass das bei manchen doch nicht funktioniert?

Grüße, Benno

Hallo,

also ich habe gerade bei einer kurzen Recherche keinerlei Hinweis darauf gefunden, dass man mit ssh-copy-id "ausversehen" den privaten Schlüssel übertragen kann...

Und mein Test unter 14.04 und einem Raspi mit Raspbian zeigt auch, dass auch ohne .pub Endung "nur" der öffentliche Schlüssel kopiert wird.

Habe mal eine entsprechende Hinweisbox eingebaut.

Gruß, noisefloor

Dann ist ja gut, dass das Programm ssh-copy-id eine eigene Intelligenz mitbringt und nix passieren kann ☺ Freut mich, meinen Beitrag geleistet zu haben. Und sorry wegen ursprünglich 'falschem' Forum. Vielleicht hätte hier wieder niemand reagiert... ☺

Gruß sausix

Hallo zusammen,

bei der Sektion "Authentifizierung über Public-Keys" wird geschrieben:

[...]mit einem

 sudo /etc/init.d/ssh reload 

die Konfiguration neu einlesen lassen.

Das konnte ich so nicht bestätigen. Nach einem reload konnte ich mich immer noch via Password authentifizieren, genauso war der root Login noch aktiv.

Erst ein:

1

service ssh restart

Konnte die Änderungen aktivieren.

Viele Grüße, Schalla

Mirwegen kannst du es dann gern dort so korrieren - sudo nicht vergessen. Hab zwar nix zu sagen, aber sonst hätte ich es gemacht - ich überlasse dir die "Ehre". 😉 Wenn keiner dazu eine abweichend Meinung äußert, mach einfach. ☺

Grüße, Benno

Hallo,

habe den Artikel mal um "getestet: trusty" erweitert. Mir ist jedenfalls nichts aufgefallen, was nicht auch für 14.04 gelten sollte.

Gruß, noisefloor

Hallo,

hätte einen kleinen Verbesserungsvorschlag und wollte jetzt nicht direkt im Wiki editieren:

Die Konfiguration des SSH-Servers sshd findet über die Datei /etc/ssh/sshd_config statt. Die Voreinstellungen sind aber durchweg akzeptabel.

Ich wäre eher dafür anstatt dieser Aussage ausdrücklich die Nutzung von AllowUsers oder AllowGroups zu empfehlen. Ich komme darauf da ich selbst den Fehler gemacht habe, für den Samba-Server Nutzer mit teilweiße banalen Passwörtern anzulegen die natürlich alle SSH Zugriff hatten. Natürlich hätte ich von --disabled-login gebrauch machen können. Allerdings bin ich wahrscheinlich nicht der einzige Linux Nutzer mit nicht so viel Erfahrung, der sich einen Home-Server zum Hobby macht.

Zur meiner Verteidigung, der SSH- Server ist wenigstens von Auserhalb nicht erreichbar 😛

Kamas schrieb:

Die Konfiguration des SSH-Servers sshd findet über die Datei /etc/ssh/sshd_config statt. Die Voreinstellungen sind aber durchweg akzeptabel.

Ich wäre eher dafür anstatt dieser Aussage ausdrücklich die Nutzung von AllowUsers oder AllowGroups zu empfehlen.

-1, denn dieser Sachverhalt wird nur wenige Zeilen unterhalb der zitierten Stelle ausfuehrlich behandelt. Aber man koennte darauf hinweisen, dass in der Voreinstellung alle auf dem System vorhandenen Nutzer SSH nutzen duerfen.

Im Artikel steht:

Bei allen weiteren Kontakten stellt das ssh-Programm jedoch von nun an über asymmetrische Kryptografie sicher, dass der Server auch über den richtigen öffentlichen Schlüssel verfügt, der zum öffentlichen, in der Datei ~/.ssh/known_hosts abgelegten passt, und verweigert im Zweifelsfall den Verbindungsaufbau.

Müsste es nicht heißen "...dass der Server auch über den richtigen privaten Schlüssel verfügt..."?

Mit Sicherheit nicht: Den privaten gibt man never ever raus, auch nicht an vertraute fremde Server. Die Formulierung hakt trotzdem irgendwie.

Benno-007 schrieb:

Mit Sicherheit nicht: Den privaten gibt man never ever raus, auch nicht an vertraute fremde Server.

Absolut richtig, und genau deshalb ... 😉

Im angesprochenen Abschnitt geht es um die Identifikation des Servers mittels dessen Host-Schlüssel, der beim ersten Kontakt in ~/.ssh/known_hosts (des Nutzers) abgelegt wird. Der Logik nach kann es sich dabei nur um den öffentlichen Schlüssel des Servers handeln, denn er wird ja an jeden Client herausgegeben.

Also muß, um im Sprachgebrauch der asymmetrischen Verschlüsselung zu bleiben, der andere Schlüssel des Paars (der auf dem Server verbleibt), dessen privater Schlüssel sein. Mit diesem identifiziert sich dann der Server bei weiteren Verbindungen beim Client, so wie es ein Mensch ebenfalls mit seinem privaten Schlüssel tun würde.

Happy Penguin schrieb:

Der Logik nach kann es sich dabei nur um den öffentlichen Schlüssel des Servers handeln, denn er wird ja an jeden Client herausgegeben.

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, so schickt der Server dem Klienten eine zufällig generierte Challenge. Der Klient verschlüsselt diesen Datenblock mit seinem privaten Schlüssel, (wofür nötigenfalls die Passphrase abgefragt wird,) und wenn der Server diesen Chiffre mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsseln kann, ist die Identität des Benutzers bestätigt.

D. h. die Schlüssel (public und privat) kommen vom bzw. sind beim Client.

Nun muss noch der öffentliche Schlüssel, zu erkennen an der Endung .pub (id_rsa.pub), auf dem Zielsystem deponiert werden. Dazu dient das Programm ssh-copy-id. Zu diesem Zeitpunkt muss die Authentifizierung per Passwort noch erlaubt sein