PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : ssh - "halbautomatisierter" key-austausch



SniperRifle
02.09.04, 21:59
Hallo zusammen,

ich habe ein Skript, welches mehrere passwortfreie SSH-Logins benötigt. Das Skript laufe z.B. als "userA" auf "rechnerA". Dieser userA braucht passwortfreies SSH zu "userB" auf "rechnerB". Und dieser userB braucht passwortfreies SSH zu "userC" auf "rechnerC".

Zusammengefasst:
userA@rechnerA ---> userB@rechnerB ---> userC@rechnerC

Das ganze mache ich mit public-Key-Austausch und ist auch überhaupt nicht problematisch.

Das eigentliche Problem ist folgendes:
Meine Skripte arbeiten mit sehr vielen Rechnern, d.h. es müssen jede Menge Keys ausgetauscht werden. Um das wenigstens etwas zu vereinfachen, wollte ich mir ein Skript schreiben, dem ich als Parameter userB, rechnerB, userC, rechnerC übergebe, das mich nur noch einmal nach den Passwörtern fragt und damit die Keys austauscht (und gleichzeitig noch ein anderes Skript auf die Rechner kopiert und ausführt). Außerdem fragt es ggf. ob Keypaare erzeugt werden sollen, falls diese noch nicht existieren.

Der erste Keytausch ist kein Problem:

cat $HOME/.ssh/identity.pub | ssh -1 -l$1 $2 '[ -r .ssh/ ] || { mkdir .ssh; chmod 700 .ssh; }; cat >> .ssh/authorized_keys'
wobei $1 == userB und $2 == rechnerB

Beim zweiten wirds schwieriger:
Das Skript, was auf rechnerA läuft, muss den Public-Key von rechnerB nach rechnerC bringen. Bisher hab ich das so:

ssh -1 -l$1 $2 cat \$HOME/.ssh/identity.pub | ssh -1 -l$1 $2 "ssh -1 -l$3 $4 '[ -r .ssh/ ] || { mkdir .ssh; chmod 700 .ssh; }; cat >> .ssh/authorized_keys' "

Das funktioniert, solange die Host-Key von rechnerC auf rechnerB schon verifiziert wurde. Dann werde ich nach einem PW gefragt und der Public-Key wird einwandfrei von B nach C übertragen.
Ist der Host-Key allerdings noch nicht verifiziert, bekomme ich keine Frage danach, auf die ich mit "yes" antworten könnte, sondern nur die Meldung "Host key verification failed" und das wars.
Ich vermute mal, dass das daran liegt, dass ssh bei Kommandoübergabe eine nichtinteraktive Shell verwendet, bin aber nicht ganz sicher. Und eine Lösung dafür fällt mir auch nicht ein. Deshalb frage ich nun euch :) Hoffe ihr könnt mir dabei helfen.

Gruß
Christian

PS: "ssh-copy-id" bringt genau das gleiche Ergebnis.

Aetius
02.09.04, 23:23
Hi Christian,

es kann sein das ssh-keygen, standardmäßig einen rsa1 Key erzeugt, der nur passend für Protocol 1 ist.
Protocol 2 braucht aber entweder rsa oder dsa.

Kann es sein das unterschiedliche Versionen hier zusammenarbeiten. Welche ssh-Version läuft auf den Systemen?

Ich hatte ein ähnliches Problem mit RedHat (Protocol 2) und Suse (Protocol 1), das hat nicht gepasst. Es könnte bei dir um ähnliches Problem handeln.

Gruss
Aetius :)

SniperRifle
02.09.04, 23:41
Hi Aetius,

danke für deine Antwort!

Ich verwende hier ausschließlich SSH v1 (bin in nem Intranet, da reicht das), daran liegt es also nicht :)

Gruß

Aetius
03.09.04, 13:12
Hi Christian,

haette sein koennen. Schade, kann ja nicht alles so einfach sein. :D

Was mir noch so spontan einfällt ist die "sshd_config" des Zielrechners, insbesondere die darin gesetzten Werte fuer
PubkeyAuthentication und RSAAuthentication
und evtl. Falsche permissions?

Gruss
Aetius :)

SniperRifle
25.09.04, 17:32
Ich muss den Thread leider noch mal ausgraben, weil ich das Prob bis heute nicht lösen konnte. Aetius Tipps haben leider auch nicht geholfen und zwischendurch war ich noch 2 Wochen in Urlaub. :)

Gruß
Chris

Terran Marine
25.09.04, 18:47
Ich vermute mal, dass das daran liegt, dass ssh bei Kommandoübergabe eine nichtinteraktive Shell verwendet, bin aber nicht ganz sicher. Und eine Lösung dafür fällt mir auch nicht ein. Deshalb frage ich nun euch :) Hoffe ihr könnt mir dabei helfen.


Sollte es an der nicht interaktiven Shell liegen, probiert mail die Option -t beim ersten ssh - Aufruf.

Gruß
Terran

SniperRifle
25.09.04, 21:56
Hi Terran,

die Option "-t" scheint in die richtige Richtung zu gehen. Mit

ssh -t -luserA compA "ssh -luserB compB"
funktioniert auch die Host-Key-Verification von A nach B, was ohne das "-t" nicht ging. Allerdings muss ja gleichzeitig noch die identity.pub übertragen werden, um den passwortfreien Login zu ermöglichen:

cat .ssh/identity.pub | ssh -t -luserA compA "ssh -luserB compB 'cat >> .ssh/authorized_keys' "
Und genau dann kommt wieder das alte "Host key verification failed." :ugly:
Hängt wahrscheinlich an dem Pseudoterminal und der Pipe. Weiß ich nich genau. :)

ABER: Ich hab das Problem bereits anders gelöst: Passwortfrei von localhost nach compA ist kein Prob.
Danach ist das PW von compB für passwortfreien Login von localhost nach compB nötig. Den SSH-Host-Key grep ich mir dann aus der localhost:.ssh/known_hosts raus und schreib ihn nach userA@compA:.ssh/known_hosts (geht ja schon ohne PW). Und ich kann passwortfrei die userA@compA:.ssh/identity.pub auslesen und ohne pW nach userB@compB:.ssh/authorized_keys schreiben. Dann kann auch userA@compA ohne PW nach userB@compB :D Wenn man grad dabei ist, kann man auch noch den passwortfreien Login von localhost direkt nach compB wieder deaktivieren. Ist zwar etwas umständlich das ganze, aber funzt :p

Gruß
Chris :)