Al Bogner schrieb:
Wenn du schon Putty Key Generator bedienst, dann lese bitte auch richtig.
Dort steht nicht zu überlesen: "Public Key for pasting into OpenSSH autherized_keys file"
und darin befindlicher Textfeld sollte in die Datei ~/.ssh/autherized_keys eingefügt werden.
Habe ich natürlich gemacht, aber in auth_o_rized_keys
Jupp. Unter Putty dann den Username Connection -> Data -> Auto-login username (falls notwendig) festlegen und den Private-Key in Putty unter Connection -> SSH -> Auth einbinden und fertig ist die Kiste. Sollte so gehen.
Ziel soll es nun mit putty sein, dass sich ein "DAU" dort mit einem abgespeicherten Profil als root anmelden kann, ohne ein PW oder einen User anzugeben und dann auf der Konsole ein Sicherungsscript aufrufen kann. Mir ist schon klar, dass dies ohne PW nicht optimal ist, aber so einfach denke ich sind die Keys nicht zu hacken. Generell würde ich einem "DAU" gar keine Root-Rechte geben und ist auch sonstiger Sichtweise nicht empfehlenswert. Denn ein "DAU" kann eine ganze Menge kaputt machen.
Sicher, aber wenn es der Server des DAU ist, kann ich nur warnen und das tun, das vielleicht funktionieren könnte. Ist er nicht lernwillig, dann hat er früher oder später Probleme.
Nicht umsonst hat man dem Root-User die höchstmöglichen Rechte vergeben. Denn die normalen User sollen am System nichts rumfuschen.
Ein Skript aufrufen, könnte schon gut gehen. Da es um eine Sicherung geht, werden Root-Rechte benötigt.
Sowas ähnliches habe ich mir schon gedacht.
Vorschlag, um ein Sicherheitsskript bei Bedarf aufzurufen: - Richte dem User einen eigenen Account ein - Generiere für den User ein SSH-Key - Der User braucht nur eine Dummy-Datei per "touch runsript" in seinem Home-Verzeichnis zu erstellen. - Richte ein Cronjob als Root-User ein, der ständige nach dieser Dummy-Datei im Home-Verzeichnis sucht und falls die Datei existiert wird entsprechend das Sicherheitsskript ausführt.
Das Skript führt auch "zypper update" aus und da kann Interaktion notwendig sein. Ich habe mir schon überlegt, die Ordnergröße zu bestimmen und alle paar Stunden per Cronjob zu prüfen, ob sich was geändert hat und automatisch zu sichern, sodass nur mehr per Winscp runtergeladen werden muss. Das würde vermutlich meistens gut gehen, aber eventuell nicht immer, und dann wäre ich der Böse, falls es Probleme gibt. Muss er interaktiv entscheiden und baut Mist, dann hat er den Fehler gemacht.
Naja, ich würde generell dem Kunden nicht wirklich beim Server freie Hand geben. Wenn er sich nicht gewachsen fühlt, einen Linux-Server zu bedienen und im Fehlerfall auch einzugreifen, dann sollte er es wirklich bleiben lassen. Dann soll er einfach ein Managed-Server buchen und nicht solche Low-Cost-Geschichten. Der Kunde hat womöglich hinterher mehr Ärger und verliert womöglich auch Geld. Und weil du dieses Skript geschrieben hast, liegt es auch in deiner Verantwortung, dass es im Fehlerfall ein Rollback durchführt. Wobei man hier auch Fehler machen kann. Fazit: Die Durchführung von Updates in der Verantwortung des DAU-Kunden zu übertragen, ist schon sehr fragwürdig. Denn falls der Server nicht mehr funktioniert, weil z.B. ein Kernel-Update durchgeführt wurde und ein wichtiges Kernel-Modul nicht mehr vorhanden ist oder noch neukompiliert werden muss. Wer trägt dann die Verantwortung, wenn der Server nicht mehr startet? Glaubst du wirklich, dass der Kunde ein Notfallsystem bedienen kann? -- Gruß Sebastian Wichtiger Hinweis zur openSUSE Mailing Liste: - Achtung: >>> Bitte keine Anhänge! <<< Stattdessen Paste-Service verwenden: <http://paste.phati.de/> <http://de.pastebin.ca/> - Bitte weitere Netiquette auf folgender wiki-Seite beachten: <http://de.opensuse.org/Mailinglisten> openSUSE Member (Freespacer) openSUSE Build Service Maintainer: - PokerTH (seit Version 0.6.3) - p7zip (seit Version 9.04) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org