Hi, we have two servers running Suse Linux 7.1. Now we need to write a script that copies all files in a directory from one server to the other server. We do that with "scp". I´ve read that i can switch of the ugly password-questions by generating ssh keys at both servers and copying the public keys to each other server. I did so, but the password-questions are still there. Does anyone know how to install the keys at the right position and what to do to get this running ? Is there a tutorial or a description how to make an automated copying from one server to another without password (via ssh?) ? Best Regards Jens Dinstuehler Tel.: +49 (0)911 9355330, Fax: +49 (0)911 935533 35 http://www.is-sw.com mailto:Jens.Dinstuehler@is-sw.com is Industrie Software GmbH Bremen, Hamburg, Koeln, Gummersbach, Mannheim Stuttgart, Nuernberg, Donauwoerth, Muenchen Salzburg (A), Wien (A), Atlanta (USA) This email contains confidential information. If you have received this email in error, please delete it immediately, and inform us of the mistake by return email. Any form of reproduction, or further dissemination of this email is strictly prohibited.
On 11 Mar 2002 at 14:20, Jens.Dinstuehler@is-ag.com wrote:
Hi,
we have two servers running Suse Linux 7.1. Now we need to write a script that copies all files in a directory from one server to the other server. We do that with "scp". I´ve read that i can switch of the ugly password-questions by generating ssh keys at both servers and copying the public keys to each other server.
I did so, but the password-questions are still there.
Does anyone know how to install the keys at the right position and what to do to get this running ? Is there a tutorial or a description how to make an automated copying from one server to another without password (via ssh?) ?
Das hier ist 'ne deutsche Liste, also die Antwort auch in Deutsch: 1. ssh-keygen starten. Frage nach passphrase mit >Return< beantworten. Damit wird ein key ohne passwort erzeugt. 2. vom client die Datei $CLIENT_USERNAME~/.ssh/identity.pub an die Datei $SERVER_USERNAME/.ssh/autorized_keys anhängen. 3. ssh/scp Zugriff vom Client auf den Server testen (falsch die Usernamen (genauer: IDs) unterschiedlich sind, den Usernamen des Servers mit angeben. So ging es hier zumindest Andreas
On Monday, 11. March 2002 14:42, Andreas Kyek wrote:
Das hier ist 'ne deutsche Liste, also die Antwort auch in Deutsch:
1. ssh-keygen starten. Frage nach passphrase mit >Return< beantworten. Damit wird ein key ohne passwort erzeugt.
Das hängt aber von der verwendeten ssh-Protokoll-Version ab. Stadnardmäßig wird nämlich nur ein Schlüsselpaar für Protokoll 1 erzeugt. Will man Ptotokoll 2 verwenden (_dringend_ empfohlen), dann muss man das bei der Schlüsselgenerierung angeben: ssh-keygen -t rsa oder ssh-keygen -t dsa
2. vom client die Datei $CLIENT_USERNAME~/.ssh/identity.pub an die Datei $SERVER_USERNAME/.ssh/autorized_keys anhängen.
Stimmt, nur wenn der Schlüssel nicht zum verwendeten Protokoll passt, wird dir Passwortabfrage durchgeführt. Heiner -- heiner@kflog.org GnuPG - Key: E05AEAFC Fingerprint: 257A DFBF 4977 4585 77A0 3509 973B 92AA E05A EAFC
Ralf Cirksena
On 2002-03-11 19:30 GMT, Heiner Lamprecht
wrote:
Will man Ptotokoll 2 verwenden (_dringend_ empfohlen),
Warum? Der Exploit bezog sich doch auf eine _Programm_-Version, nicht auf eine _Protokoll_-Version. Oder siehst Du andere Gründe? Nicht unbedingt der letzte Exploit, aber man sollte sich über die Security von SSH1 hier nicht zu sehr beschäftigen. Wer will, wird bestimmt genug zu diesem Thema finden (via google!).
SSH1 hat Scurity Schwachstellen und sollte daher nicht vewendet werden. (Aber immer noch besser als rsh oder telnet! Und wenn ich sehe, wie viele Leute genau dieses noch nutzen!) Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
Hallo Liste! Ehe lange diskutiert wird, reiche ich noch ein paar Seiten nach: http://cc.uoregon.edu/cnews/spring2001/ssh1.html http://www.ssh.com/products/ssh/advisories/ Und als die direkte Antwort auf den Thread: http://www.ssh.com/products/ssh/advisories/statement.cfm "SSH Communications Security recommends that everyone switches to using version 2 of the Secure Shell protocol (SSH2). The latest version of SSH Secure Shell, ssh-3.0.0, can be obtained from our ftp site for non- commercial use, or from our online store for commercial use." Natürlich muss das, was auf ssh.com gesagt wird, nicht auf openssh zutreffen, aber das lasse ich jetzt mal ausser Acht. Die genannten Seiten sind recht interessant und ich kann mich dem nur anschliessen. Hier kommt vielleicht auch noch hinzu, was ich bei den Update-Threads immer so schön sage: Ich will ja auch gewissen Support. Daher nehme ich ein Produkt, in dass die ganzen Security-Patches und so einfliessen. Ich weiss nicht in wie weit dies bei SSH1 Produkten noch der Fall ist! Dies soll aber nur als Ergänzug dienen und ich möchte diesen Punkt nicht unbedingt diskutieren! Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
Hallo Konrad,
On 2002-03-12 08:30 GMT, "Konrad Neitzel"
Ehe lange diskutiert wird, reiche ich noch ein paar Seiten nach:
http://cc.uoregon.edu/cnews/spring2001/ssh1.html http://www.ssh.com/products/ssh/advisories/
Und als die direkte Antwort auf den Thread: http://www.ssh.com/products/ssh/advisories/statement.cfm
Danke.
Natürlich muss das, was auf ssh.com gesagt wird, nicht auf openssh zutreffen, aber das lasse ich jetzt mal ausser Acht. Die genannten Seiten sind recht interessant und ich kann mich dem nur anschliessen.
Werde ich lesen. Allerdings vorab: Ich setze hier OpenSSH 3.1p1 ein.
Also schon am "Puls der Patches" ;-) Da es immer noch in der "anderen
Welt" viele Clients gibt, die Protokoll Version 2 nicht können,
interessiert(e) mich die Frage.
--
Ralf Cirksena
Hallo Konrad,
On 2002-03-12 08:30 GMT, "Konrad Neitzel"
Nachtrag: Zitat aus o.g. URL:
| If you're running OpenSSH, you should update to OpenSSH 2.3.0, which
| is not vulnerable to either of these attacks.
Das scheint aber schon älter zu sein, aufgrund inzwischen
festgestellter _Programm_-Sicherheitsmängel sollte man auf OpenSSH
3.1 updaten.
Auch die Quellen auf www.ssh.com schreiben, daß die Sicherheitsmängel
wegkonfigurierbar sind.
ssh2 ist aber möglicherweise einfacher zu konfigurieren.
Danke für die Hinweise.
--
Ralf Cirksena
participants (5)
-
Andreas Kyek
-
Heiner Lamprecht
-
Jens.Dinstuehler@is-ag.com
-
Konrad Neitzel
-
Ralf Cirksena