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. -- mfG Helmut
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
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.
Dazu generierst Du auf den Knoten mit "ssh-keygen -t rsa" ein Schlüsselpaar (~/.ssh/id_rsa und ~/.ssh/id_rsa.pub) und kopierst dann den Inhalt von id_rsa.pub in ~/.ssh/authorized_keys auf dem Zielrechner. Wenn Du den Key nicht per Passwort schützt, ist ein automatisches Einloggen per SSH ohne Passworteingabe möglich. Gruß Jens -- registered linux user #130250
Am Montag, 23. Juni 2003 00:42 schrieb Jens Tautenhahn: Hi Jens
Dazu generierst Du auf den Knoten mit "ssh-keygen -t rsa" ein Schlüsselpaar (~/.ssh/id_rsa und ~/.ssh/id_rsa.pub) und kopierst dann den Inhalt von id_rsa.pub in ~/.ssh/authorized_keys auf dem Zielrechner. Wenn Du den Key nicht per Passwort schützt, ist ein automatisches Einloggen per SSH ohne Passworteingabe möglich.
Tja so steht es geschrieben, aber entweder habe ich dann noch einen Fehler in meinen Überlegungen oder Transcode schert sich einen Teufel darum. Denn sowohl known_hosts wie authorized_keys haben die Schlüssel der Knoten. Es wxistiert ein Verzeichnis /.ssh und eines /.gpg. In /.ssh liegen die Schlüsel für das interne Netz. In /,gpg die mit denen ich im allgemeinen meine Mails signiere. Könnten hier unverträglichkeiten entstehen? -- mfG Helmut
Am Montag, 23. Juni 2003 00:42 schrieb Jens Tautenhahn: Hi Jens
Dazu generierst Du auf den Knoten mit "ssh-keygen -t rsa" ein Schlüsselpaar (~/.ssh/id_rsa und ~/.ssh/id_rsa.pub) und kopierst dann den Inhalt von id_rsa.pub in ~/.ssh/authorized_keys auf dem Zielrechner. Wenn Du den Key nicht per Passwort schützt, ist ein automatisches Einloggen per SSH ohne Passworteingabe möglich.
Tja so steht es geschrieben, aber entweder habe ich dann noch einen Fehler in meinen Überlegungen oder Transcode schert sich einen Teufel darum. Denn sowohl known_hosts wie authorized_keys haben die Schlüssel der Knoten. Es wxistiert ein Verzeichnis /.ssh und eines /.gpg. In /.ssh liegen die Schlüsel für das interne Netz. In /,gpg die mit denen ich im allgemeinen meine Mails signiere. Könnten hier unverträglichkeiten entstehen? -- mfG Helmut
Hallo Helmut Am Montag, 23. Juni 2003 08:12 schrieb Helmut Scholl:
Am Montag, 23. Juni 2003 00:42 schrieb Jens Tautenhahn:
Hi Jens
Dazu generierst Du auf den Knoten mit "ssh-keygen -t rsa" ein Schlüsselpaar (~/.ssh/id_rsa und ~/.ssh/id_rsa.pub) und kopierst dann den Inhalt von id_rsa.pub in ~/.ssh/authorized_keys auf dem Zielrechner. Wenn Du den Key nicht per Passwort schützt, ist ein automatisches Einloggen per SSH ohne Passworteingabe möglich.
Tja so steht es geschrieben, aber entweder habe ich dann noch einen Fehler in meinen Überlegungen oder Transcode schert sich einen Teufel darum. Denn sowohl known_hosts wie authorized_keys haben die Schlüssel der Knoten. Es wxistiert ein Verzeichnis /.ssh und eines /.gpg. In /.ssh liegen die Schlüsel für das interne Netz. In /,gpg die mit denen ich im allgemeinen meine Mails signiere. Könnten hier unverträglichkeiten entstehen?
Was passiert, wenn Du Dich mit ssh Zielrechner anmeldest? Auch ein Passwort? Dann versuche mal ssh -2 Zielrechner falls das geht, in /etc/ssh/ssh_config Protocol 2,1 eintragen. Wenn Deine ssh das Protokoll 2 nicht unterstützt, die Schlüssel mit ssh-keygen -rsa1 erzeugen und den Inhalt von ~/.ssh/identity.pub in ~/.ssh/authorized_keys auf dem Zielrechner eintragen. Gruss Heiner -- Heiner Kuhlmann Unter den Eichen 30, D-28857 Syke, Germany Phone: +49(4240)95076 FAX +49(4240)95077 PM: heiner.kuhlmann@t-online.de Liste: linux@kr-k.de
Am Montag, 23. Juni 2003 10:18 schrieb Heiner Kuhlmann: Hallo Heiner
Tja so steht es geschrieben, aber entweder habe ich dann noch einen Fehler in meinen Überlegungen oder Transcode schert sich einen Teufel darum. Denn sowohl known_hosts wie authorized_keys haben die Schlüssel der Knoten. Es wxistiert ein Verzeichnis /.ssh und eines /.gpg. In /.ssh liegen die Schlüsel für das interne Netz. In /,gpg die mit denen ich im allgemeinen meine Mails signiere. Könnten hier unverträglichkeiten entstehen?
Was passiert, wenn Du Dich mit ssh Zielrechner anmeldest? Auch ein Passwort? Dann versuche mal
# ssh asterix "Enter passphrase for key ´/home/helmut/.ssh/id_dsa`:
ssh -2 Zielrechner
# ssh -2 asterix Enter passphrase key `/home/helmut/.ssh/id_dsa`:
falls das geht, in /etc/ssh/ssh_config Protocol 2,1
ist bereit eingetragen, aber noch auskommentiert, läuft also unter der Vorgabe. Wenn der laufenden Prozess beendet ist werd ich das mal ändern.
eintragen. Wenn Deine ssh das Protokoll 2 nicht unterstützt, die Schlüssel mit ssh-keygen -rsa1 erzeugen und den Inhalt von ~/.ssh/identity.pub in ~/.ssh/authorized_keys auf dem Zielrechner eintragen.
Die beteiligten Rechner haben jeder eine ~/.ssh/authorized_keys mit den Schlüsseln der anderen + dem eigenen. Zusätzlich werde nachsehen ob sich DVD::RIP in der Clustersteuerung mit dem ssl -x -i ~/.ssh/id_key.pub zufrieden stellen läßt. Danke auch an alle anderen für die Denkanstöße. -- mfG Helmut
Hi!
"Enter passphrase for key ´/home/helmut/.ssh/id_dsa`:
ssh -2 Zielrechner
# ssh -2 asterix
Enter passphrase key `/home/helmut/.ssh/id_dsa`:
sieht so aus, als ob Du beim Generieren des Keys ein Passwort angegeben hast. Das will er dann natürlich wissen. Bestätige beim Erstellen des Key die Passwortabfrage einfach mit <ENTER>. Dann fragt er beim scp ssh auch nicht mehr nach dem Passwort. Chris
Am Montag, 23. Juni 2003 11:50 schrieb Chris Zielecki: Hi Chris
"Enter passphrase for key ´/home/helmut/.ssh/id_dsa`:
ssh -2 Zielrechner
# ssh -2 asterix
Enter passphrase key `/home/helmut/.ssh/id_dsa`:
sieht so aus, als ob Du beim Generieren des Keys ein Passwort angegeben hast. Das will er dann natürlich wissen. Bestätige beim Erstellen des Key die Passwortabfrage einfach mit <ENTER>. Dann fragt er beim scp ssh auch nicht mehr nach dem Passwort.
Hab ich gemacht und dann möchte es auch einfach mit Enter bestätigt werden Einmal mit Password generiert ein anderesmal ohne, der Effekt ist der selbe. In dem Fall ziehe ich natürlich mit Password vor. Aber ich lasse den Film gerade mit den zusätlichen ssh-Parametern von DVD::RIP transcodieren. Ach ja, DVD::RIP und Co sind die Versionen i686 SuSE 8.2 -- mfG Helmut
Hi Helmut!
Hab ich gemacht und dann möchte es auch einfach mit Enter bestätigt werden Einmal mit Password generiert ein anderesmal ohne, der Effekt ist der selbe. In dem Fall ziehe ich natürlich mit Password vor.
klar (: allerdings hab ichs gerade selbst probiert: ssh-keygen -t dsa passwort mit enter übersprungen dann auf dem anderen rechner authorized_keys2 angelegt und dort den public key rein geschrieben (oder eben über "cat", egal). jedenfalls kann ich jetzt OHNE Passwort abfrage per ssh drauf zugreifen. sollte also auch bei dir gehn. guck halt das du auf der richtigen kiste bist *ggg* /me da aus eigener erfahrung spricht (; Chris
Am Montag, 23. Juni 2003 13:26 schrieb Chris Zielecki: Hi Chris Stell Dir vor, Du siehst mich strahlend lachen
klar (: allerdings hab ichs gerade selbst probiert:
ssh-keygen -t dsa passwort mit enter übersprungen dann auf dem anderen rechner authorized_keys2 angelegt und dort den public key rein geschrieben (oder eben über "cat", egal). jedenfalls kann ich jetzt OHNE Passwort abfrage per ssh drauf zugreifen.
sollte also auch bei dir gehn.
Tut es jetzt. ssh-keygen mußte ich von Anfang an mit -t dsa(rsa) aufrufen. Entgegen der Beschreibung in dem Buch "Datensicherheit im Netz" Dort habe ich keinen Hinweis gefunden der angedeutet hätte eine "authorized_keys2" zu erstellen, sondern nur "authorized_keys", sollte das der einzige Grund für den ganzen Ärger gewesen sein? Die ssh.config habe ich zusätzlich geändert. [...] # HostKey for protocol version 1 HostKey /etc/ssh/ssh_host_key # geändert 23.06.03 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key # geändert 23.06.03 #HostKey /etc/ssh/ssh_host_dsa_key [...] #RSAAuthentication yes PubkeyAuthentication yes # geändert 23.06.03 AuthorizedKeysFile .ssh/authorized_keys # geändert 23.06.03 [...] Sollte ich diese wieder rückgängig machen? Ich bin zwar nicht paranoid aber Sicherheitlöcher möchte nicht mehr als notwendig. -- mfG Helmut
participants (5)
-
Andreas Hergesell -
Chris Zielecki -
Heiner Kuhlmann -
Helmut.Scholl_Witten＠t-online.de -
Jens Tautenhahn