Hi Helmut, Am Montag, 23. Juni 2003 00:13 schrieb Helmut Scholl:
Hallo Liste
Ich habe ein kleines Problem mit der richtigen Konfiguration von ssh. Ein kleiner Cluster von 3 Rechnern soll mit Transcode einen Film bearbeiten. Nun benötigt Transcode aber SSH. Das Problem jedesmal wenn einer der Knoten einen neuen Chunk bearbeiten soll, muß ich das Passwort eingeben, bei einem leeren Passwort ist es dasselbe, jetzt allerdings nur bestätigen. Die Rechner sollen aber zumindest in diesem Bereich ohne ständige Passwort eingabe zusammen arbeiten.
Das geht mittels Publickeys. Kristian Köhntopp hat das mal sehr schön hier in der Liste beschrieben: Im Archiv zu finden. Am Donnerstag, 6. März 2003 11:24 schrieb Kristian Köhntopp: Message-Id: <200303061123.49462.kris@koehntopp.de> --------schnipp---------------------------------------
ssh für Dummies:
Wie mache ich mir einen Key? ======================
In konsole eingeben:
$ ssh-keygen -b 2048 -t dsa -N "" ...
Jetzt existiert in $HOME/.ssh/id_dsa.pub ein Public Key und in $HOME/.ssh/id_dsa ein Private Key. Der Private Key wird NIEMALS herausgegeben und gut gesichert (auf USB Stick oder CD-RW).
Der Public Key sieht in etwa so aus (eine superlange Zeile)
kk@kris:~> cat .ssh/id_dsa.pub ssh-dss AAAAB3NzaC1kc3MAAAEBAM78PjFl27O3p2LoWLHlrOf2U10LOxN+GUEPTM6/4nEFm 2YeJdoTOAasQ7+LVYLwkzc6fV5L0b4YMaKXbys6vrqo/GdhrlF0s4HyQax8i2q4ePF 6fn/ZiNo+8p3Pho0JalQeDpNmAJtfIpubi9RMFDesbEmFChPEeWga/W67Dy/LUJ1eK D/MQ+ZE5Loygv6CIYjPUXIM18do4LqYK7esLos6GK6duQDQY0qGybRl7id7nnOgKH6 d/ZUXRbu+rhnPfoucIOK1KAwWzXkPzhM5sXTk2ehfyFfU7fEVyJwygCmtDSipRkh5s XVPEfgc4CQUHxGmu16wCswz8hm74CkwnxsAAAAVALZgtLerUehO17T4eSlEeL/KrUI jAAABAQCpsLlxn87DhxhyUi98aNTDspcHtsAtQlGPsFo4JxEEZNlfo1j7wWy8Yux46 ipjt92VbuCQhOfYAli52lQFkFeoCyZNj6UDzBdkYDPAuwBhN1ECmDWXWpzqY6Iw/QK kMPYBSj9txui/PIy8nr+j1NuQLAB7/RKOpIG/cwbu/VbM/6aaiHCKcxpgwUdCS+lI8 MvEevs8c8DdipF6OyNEWn0DLK9tnwNZ3YkZd7cM6hw4KKD9SAN+c5Jm7wpJadVG8CW mRHHjLDjsLQUBYyA6ME6gYGU++VSFWGi0ut4IoKcK6oh0eHWo9+BsCrpYbaivx/5yS vKL3cIyW1KKf2SvmMOIAAABAHCBCCYzq3e2+OeDsvPLbq3eFkrekSEHw1XQYW6hmw9 j56j3eP+EPj6vuusLGRNJiSSlolJw3VzTBRG1htqJAIR2FZ9ceqDbvAYB1hNvJEJJ8 WaYnMnpLqsYFctLKIFTcijHRoexu+iHuoJWOdg9FYjl8YuN1VhjPUonLswHYTg9tww 6X7IHu8Jo0JTdgAuR9hs7/2KbYg0BG8y8wZv+eB2ti4gxFyEp/zYw+2Dw6Ay5eRzQm aO9oapmZDujjrreaWYh2r4QoB5F5j05q80ihOqFWK3LZytBgPz3WRN6B4bhCsrQohj UR00scz8Ej9i1kjRA+4GJtfBNue+G7Lqcrks= kk@kris
und kann problemlos verbreitet werden.
Was nutzt mir der Key? =================
Der Public Key kann auf einem Zielrechner in der Datei $HOME/.ssh/authorized_keys gespeichert werden. Die Datei muß dem Zieluser gehören und darf maximal die Rechte 0644 haben. Sie muß im Verzeichnis .ssh liegen, und dieses muß dem Zieluser gehören und darf maximal die Rechte 755 haben. Das Home des Users muß diesem ebenfalls gehören und nicht mehr Rechte als 755 haben.
Also:
quser@quelle$ cat .ssh/id_dsa.pub | ssh zuser@ziel "cat >> .ssh/authorized_keys" zuser's Password: ...
Jetzt kann der Quelluser quser auf dem Quellsystem quelle sich auf dem Rechner ziel als zuser anmelden, ohne nach einem Paßwort gefragt zu werden.
Ist das nicht unsicher? ================
Yep. Wer quser's .ssh/id_dsa klaut, kann überall rein, wo quser auch rein darf. Also setzen wir ein Paßwort auf den Key:
quser@quelle $ ssh-keygen -p
Jetzt kann quser's id_dsa zwar geklaut werden, ist aber mit dem Paßwort gesichert und kann ohne Paßworteingabe nicht verwendet werden.
Für quser ist das ein Gewinn, denn er muß sich nun nur noch ein Paßwort merken (das vom Key) und nicht mehr 120 Stück (von 120 Zielrechnern).
Geht's noch bequemer? =================
Yep. Man ediere $HOME/.xsession. Bei Suse Linux steht da
# # If ssh is configured and ssh-agent is wanted set "yes" # usessh="no"
und das will stattdessen so aussehen:
# # If ssh is configured and ssh-agent is wanted set "yes" # usessh="yes"
Danach ist KDE zu beenden und man muß sich einmal neu anmelden.
Nach dem neuen Login steht "ssh-agent" in der Prozeßliste:
quser@quelle $ pstree ...
|-kdm-+-X | `-kdm---kde-+-kwrapper | `-ssh-agent
...
ssh-agent hat Umgebungsvariablen in jedem KDE-Prozeß, mit denen er mit dem KDE-Prozeß reden kann:
quser@quelle $ env | grep -i ssh kk@kris:~> env| grep -i ssh SSH_AGENT_PID=1205 SSH_AUTH_SOCK=/tmp/ssh-XXH9W1Tg/agent.1171
ssh-add kann nun den Key des User einmal aufschließen und in den Agent speichern. Andere ssh-Anwendungen können von dort den Key des Users bekommen:
quser@quelle $ ssh-add Enter passphrase for /home/quser/.ssh/id_dsa: Identity added: /home/quser/.ssh/id_dsa (/home/quser/.ssh/id_dsa)
Ein "ssh-add -l" zeigt, welche Keys geladen sind:
quser@quelle $ ssh-add -l 2048 9a:be:83:5d:06:5d:f4:56:d2:45:38:28:50:fe:23:28 /home/kk/.ssh/id_dsa (DSA)
Nun kann sich quser nach einmaliger Eingabe seines einzigen Paßwortes ohne weitere Fragen auf den 120 Zielrechnern einloggen.
------------schnapp------------------------- Ob das ganze jetzt mit transcode zusammenarbeitet weiß ich nicht, IMHO aber schon. Viele Spaß Andreas