hallo michael, >> die richtige sytax wäre m.e.: >> [IP1]:22,[IP2]:22,[IP3]:22 keytype key > Ok -- ist in der while-Schleife aber momentan einfacher, wenn man's > _pro_ Client einträgt. klar. ich denke auch, daß das eher grundsätzliche info für eine v2 ist :)
>> ich würde mich auf den einen verwendeten algorithmus festlegen und >> diesen dann mit grep rausfiltern. > Ja, guter Plan -- das ist schnell geändert. Allerdings wird bei _mir_ > unter "ed25519" gar nix gefunden; s.u. hängt wohl vn der version ab und wann der server zuletzt seine keys erneuert hat. default bei jessie ist momentan afair rsa mit 2048, ecdsa und als "bestes" ed25519. m.e. für den normalfall aber alle gleichwertig sicher. mein (damals "blödsinnig" langer) rsa key von 1996 klappt dort zumindest klaglos... >> ich glaube aber garnicht, daß wirklich jemand verschiedene >> keyalgorithmen benutzt. > Ich auch nicht -- "ssh -v" zeigt ja an, welcher Schlüssel ausgehandelt > wurde; und ich habe in meiner > known_hosts-Datei _fast_ immer "ecdsa-sha2-nistp256" stehen. Das hängt > wahrscheinlich mit der > o.g. Umstellung, die OpenSSH vor kurzem erfahren hat, zusammen?!? in die known hosts datei wird der algorithmus deines lokalen keys eingetragen, wenn der server diesen auch anbietet. daß dies momentan ecdsa ist liegt an der kürzlichen default änderung bei openssh, ja. >> rm -f würde ich nie auf eine variable loslassen. >> denk mal was passiert, wenn zb durch ein falsches leerzeichen die >> variable /etc/ o.ä. lautet... > DAS Problem hat man aber auch bei "rm -f /tmp/bla-blupp" ?!? nein. man hat dann keine variable, sondern eine feste konstante im sourcecode. > Wenn man da ein Leerzeichen an der falschen Stelle einfügt, ist > ebenfalls Schicht im > Schacht ... (bin schon öfter darüber gestolpert -- und habe mich auch > schon öfter gewundert) > Man kann's natürlich auf /tmp/ umstellen, doch auch dann hätte man > irgendwo ein "rm -f /tmp/..." ja, aber bei einem rm schaut man (hoffentlich) genauer hin, als bei einer variablenzuweisung. außerdem wird dann immer einfach alles im tmp/linkey/ verzeichnis gelöscht. unabhängig von der art und anzahl der dateien... > mit einem ähnlichen Risiko!? Die verwendeten Variablen in dem Script > sind ja ausnahmslos oben definiert ... wenn da ein Leerzeichen an der > falschen Stelle rein rutscht: Gute Nacht :) /tmp enthält per definition nur temporäre daten, die das system auch dann nicht wesentlich in der lauffähigkeit beeinflussen, wenn sie ungeplant gelöscht werden. bei /etc, oder /root sieht das eeeetwas anders aus ;-) funktional ändert das natürlich nichts... > Übrigens: Was hälst du als Alternative von der Option > "StrictHostKeyChecking no"? hm, ja, hatte ich auch kurz angedacht. die option gilt dann aber für ALLE ssh verbindungen, nicht nur für die unkritischen zu den linbo servern. wenn man also auch verbindungen zu "echten hosts" macht, hat man da wieder weniger sicherheit, ohne dass es einem bewusst ist. die "sicherste" variante ist m.e. in der ssh.config das hashing angeschaltet zu lassen, mit deinem script die dupes rauszuwerfen und nur die linbo gegenstellen ungehasht einzutragen. jonny _______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
