Moin, moin ... * Thomas Masaninger [030306 09:38]:

Hi Michael!

Ich heiße Martin, aber das macht so gut wie fast wenig ;-)

Man kann Daten austauschen ohne Samba? Was ist scp?

Also, wenn Du zwei Linux-Rechner hast, dann brauchst Du kein Samba, um Daten auszutauschen. scp steht imho für "secure copy" und ist im Paket "OpenSSH" in Deiner SuSE-Distri enthalten. kind regards Martin Mewes -- http://counter.li.org/ |User:274762 http://vmware.itst.org/ |Deutschsprachiges WebForum fuer VMware http://www.agent-de.org/ |"Forte Agent" auf Deutsch

Moin, * Thomas Masaninger [2003-03-06 09:38]:

...

Ja, das geht. Wenn sich die Rechner gegenseitig "sehen", dann wäre zum Beispiel "scp" Dein Freund. Im Zusammenhang mit "ssh" reicht dies imho völlig aus, um bequem Daten auszutauschen. Und zwar auf der Konsole ;-)

Man kann Daten austauschen ohne Samba?

Äh ja, allerdings, auch vor Windows hat es schon Netzwerke gegeben.

Was ist scp?

man scp Thorsten -- Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves. - William Pitt

On Thursday 06 March 2003 10:23, Maik Holtkamp wrote:

Wenn Du auf Basis von scp da was machen willst, gibt es AFAIK das fish Protokol dafür.

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/4nEFm2YeJdoTOAasQ7+LVYLwkzc6fV5L0b4YMaKXbys6vrqo/GdhrlF0s4HyQax8i2q4ePF6fn/ZiNo+8p3Pho0JalQeDpNmAJtfIpubi9RMFDesbEmFChPEeWga/W67Dy/LUJ1eKD/MQ+ZE5Loygv6CIYjPUXIM18do4LqYK7esLos6GK6duQDQY0qGybRl7id7nnOgKH6d/ZUXRbu+rhnPfoucIOK1KAwWzXkPzhM5sXTk2ehfyFfU7fEVyJwygCmtDSipRkh5sXVPEfgc4CQUHxGmu16wCswz8hm74CkwnxsAAAAVALZgtLerUehO17T4eSlEeL/KrUIjAAABAQCpsLlxn87DhxhyUi98aNTDspcHtsAtQlGPsFo4JxEEZNlfo1j7wWy8Yux46ipjt92VbuCQhOfYAli52lQFkFeoCyZNj6UDzBdkYDPAuwBhN1ECmDWXWpzqY6Iw/QKkMPYBSj9txui/PIy8nr+j1NuQLAB7/RKOpIG/cwbu/VbM/6aaiHCKcxpgwUdCS+lI8MvEevs8c8DdipF6OyNEWn0DLK9tnwNZ3YkZd7cM6hw4KKD9SAN+c5Jm7wpJadVG8CWmRHHjLDjsLQUBYyA6ME6gYGU++VSFWGi0ut4IoKcK6oh0eHWo9+BsCrpYbaivx/5ySvKL3cIyW1KKf2SvmMOIAAABAHCBCCYzq3e2+OeDsvPLbq3eFkrekSEHw1XQYW6hmw9j56j3eP+EPj6vuusLGRNJiSSlolJw3VzTBRG1htqJAIR2FZ9ceqDbvAYB1hNvJEJJ8WaYnMnpLqsYFctLKIFTcijHRoexu+iHuoJWOdg9FYjl8YuN1VhjPUonLswHYTg9tww6X7IHu8Jo0JTdgAuR9hs7/2KbYg0BG8y8wZv+eB2ti4gxFyEp/zYw+2Dw6Ay5eRzQmaO9oapmZDujjrreaWYh2r4QoB5F5j05q80ihOqFWK3LZytBgPz3WRN6B4bhCsrQohjUR00scz8Ej9i1kjRA+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. Und fish kann es auch. Was bitte ist fish? ============= Fish ist ein Plugin für KDE. Es ermöglicht KDE, fish-URLs zu verarbeiten. Jede Anwendung kann dann immer dann, wenn ein Dateiname oder eine URL gefragt ist, stattdessen eine ssh-Location ansprechen. Fish-URLs sehen so aus: fish://zuser@zhost/directory/file.ext Dies bewirkt ein Login auf zhost als zuser, und dann einen Zugriff auf /directory/file.ext. Mit fish kann Konqueror graphisch Files über ssh und scp managen, können kate und quanta remote Webs bearbeiten und jede andere KDE-Anwendung remote auf Ressourcen zugreifen. Kristian