Jau, habe ich gemacht. Ich habe mich vom 7.3er Rechner auf den 10er Rechner mit ssh eingelogt. Auf dem SuSE 7.3er ist in der /home/xy/.ssh/known_hosts ist auch der 10er PC drin. Ich hatte den 10er neuinstalliert und der SSH-Key ist natürlich anders - ich glaube, beim Update von 7.3 auf 10 wären lustige Sachen rausgekommen... Na ja, funzt immer noch net. Ich habe mal mit ssh-keygen -t rsa1 einen Key auf dem 10er Rechner erzeugt. Jetzt wird eine identity.pub erzeugt und die habe ich analog wieder ins ./ssh-Verzeichnis von xy auf dem 7.3er kopiert und in authorized_keys umbenannt. Mit rsa1 erhalte ich einen Key, der wie der alte, funktionierende nur aus Zahlen besteht und auch die "richtige" Länge hat. Ähh, was für einen Key (dsa,rsa,rsa1 usw.) kann man grundsätzlich für dieses Authentifizieren nehmen. Man findet ja quasi alle Möglichkeiten im Netz. Die Rechte von /home/xy/ sind 755, von /home/xy/.ssh 700 und von /home/xy/.ssh/authorized_keys 644. Alles gehört xy und users. Hmmm, langsam bin ich ratlos. Gruß, Michel Jörg Dreßler schrieb:

Wenn ich wetten würde, würde ich auf den SSH-Hostkey tippen, mit dem sich die Rechner authentifizieren. Hast Du ein Update gemacht oder eine Neuinstallation? Bei ner Neuinstallation ist das auf jeden Fall ein Problme, bei nem Update weiß ich es nicht. Praktikable Vorgehensweise: lösche auf dem 73-Rechner die Datei "~./known_hosts" und starte als entsprechender Nutzer manuell eine SSH-Verbindung zum 10er-Rechner und authorisiere den Host. dann sollte das alles sein.

Gruß Jörg

post@chemiegott.de wrote:

...

Tach zusammen!!

Ich habe zwischen meinen zwei Linuxservern ein paßwortloses Login von Rechner A nach Rechner B ermöglicht, um Nachts mit scp einige Dateien regelmäßig automatisch kopieren zu lassen.

Das funktionierte bis zuletzt auch.

Server A kopierte als root eine Datei auf Server B als User xy

Ich hatte mit ssh-keygen auf A ein Schlüsselpaar angelegt und das in /home/xy/.ssh/autorized_keys kopiert. Alles wunderbar.

So jetzt habe ich Rechner A auf SuSE 10 neu aufgesetzt. Auf Rechner B läuft noch SuSE 7.3. Ich habe mit ssh-keygen auf Rechner A wieder Schlüssel generiert, aber es funktioniert nicht mehr :-(((.

Mir fällt auf, das der öffentliche SSH-Schlüssel von root auf Rechner A nun 603 Bytes groß ist, vorher waren es 379 Bytes.

Kann ich was ändern, damit es wieder geht (bitte nicht: Rechner B auf SuSE 10 updaten...)

Danke vorab für jeden Tipp.

Gruß, Michel

No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/206 - Release Date: 16.12.2005

* Michael Paarmann wrote on Sat, Dec 17, 2005 at 21:45 +0100:

N'abend nochmal!

Das Problem mit dem paßwortlosen Login via SSH ist gelöst. Ich hatte mir die /etc/sshd_config auf beiden Systemen mal angeschaut. Auf SuSE 7.3 steht da standardmäßig, "Protocol 1,2" - also wir zunächst SSH1 benutzt.

Sowas wollte ich gerade schreiben, gut, dass Du gleich selbst geantwortet hast, danke!

Auf SuSE 10 wird SSH1 standardmäßig gar nicht mehr verwendet. Da das alte System, mit dem der paßwortlose Login funktionierte, auch ein SuSE 7.3 war, kommunizierten die Rechner ja über SSH1.

Da jetzt einer auf SuSE 10 läuft, läuft die Kommunikation nun über SSH2, also mußte ich mit ssh-keygen -t rsa einen SSH2-Keypaar erstellen und die id_rsa.pub auf die SuSE 7.3 Kiste kopieren - aber als authorized_keys2.

Ja, das mit authorized_keys2 ist ein blöder "Fehler", den die Packagebauer da gemacht haben, ist aber zum Glück bei neueren raus. Wundert mich, dass Deine SuSE 7.3 das brauchen sollte... Sollte man entweder umkonfigurieren oder per update lösen können, ich bin mir recht sicher, mich daran zu erinnern, zwar mal authorized_keys2 Symlinks angelegt zu haben aber später entfernen konnte.

Tja, jetzt darf ich mich selbst wieder schlagen, weil eigentlich alles in der MAN-Page steht...RTFM rulez !!

Bei solchen Problemen immer erstmal "ssh -v" machen, das hilft einem oft schon ne Menge (auch wenns um "agent forwarding" geht und so - es funktioniert nämlich ein "ssh -v host1 ssh -v host2") - der output ist natürlich bissel gewöhnungsbedürftig. Zum Testen sind auch "-1" und "-2" nett, falls die /etc/ssh mal wieder nicht stimmt. Im SSH-Server kann man auch ne Menge Debug anschalten, hab ich aber selten gebraucht. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.