Anne Forker
ist es moeglich, Benutzern, die sich ueber ihren Host- und Benutzer-Key an einem Server anmelden, einen root-Zugang zum System zu gewaehren, indem der Host-Key in die Datei /etc/ssh_known_hosts kopiert wird? Die manpage zu ssh habe ich bereits gelesen, aber die Authorisierungsverfahren (speziell /etc/hosts.equiv) sind mir nicht bekannt.
Fuer passwortlose Logins via SSH gibts drei Varianten: RhostsAuthentication Ein Login als Benutzer USER wird zugelassen, wenn die Eintraege in /etc/hosts.equiv, /etc/shosts.equiv, ~USER/.rhosts oder ~USER/.shosts das erlauben. Die ersten beiden Dateien enthalten Eintraege von vertrauenswuerdigen Rechnern -- Benutzer von dort koennen sich unter gleichem Namen ohne Passwort einloggen. Mit den Dateien in ~USER ist noch etwas mehr moeglich: Ein Eintrag, der nur einen Hostnamen enthaelt, erlaubt einem gleichnamigen Benutzer von diesem Host das Login; steht noch ein Username dahinter, so kann sich der entsprechende User vom anderen Rechner ohne Passwort als USER einloggen. Dieses Verfahren ist nicht kryptographisch gesichert, d.h., es wird einfach nur den IP-Adressen vertraut. Daher sollte es in der Regel nicht zugelassen werden. (Die Datenuebertragung erfolgt aber auch hier verschluesselt.) RhostsRSAAuthentication Funktioniert wie RhostsAuthentication, verlangt aber zusaetzlich, dass der entfernte Rechner ueber seinen Hostkey identifiziert werden kann. Dazu muss der oeffentliche Hostkey des entfernten Rechners in /etc/ssh_known_hosts oder ~USER/.ssh/known_hosts stehen. RSAAuthentication Hier wird mit persoenlichen RSA-Schluesseln gearbeitet, d.h., es geht hier direkt um die Identifikation eines Benutzers, nicht um die eines vertrauenswuerdigen Rechners. Jemand darf sich als USER einloggen, wenn in ~USER/.ssh/authorized_keys sein oeffentlicher RSA-Schluessel aufgefuehrt ist. (Schluesselpaare werden mit ssh-keygen erzeugt, der private Schluessel bleibt in ~/.ssh/identity. Der oeffentliche Schluessel ~/.ssh/identity.pub kann dann auf anderen Rechnern in die entsprechende authorized_keys Datei eingetragen werden, um das passwortlose Login zu ermoeglichen.) Die dritte Variante waere fuer deinen Fall geeignet. Dazu muesste sich jede der berechtigten Personen ein Schluesselpaar generieren, und die oeffentlichen Schluessel muesstest Du in ~root/.ssh/authorized_keys eintragen. Vorausgesetzt, sie sollen wirklich vollen root-Zugang erhalten...
Konkret geht es um die Anwendungen postfix und majordomo sowie qmail und ezmlm. Wenn jemand hier zusichern kann, dass sich diese Programme auch ohne root-Rechte administrieren lassen, wuerde mir das auch schon sehr helfen.
Das sollte sich irgendwie machen lassen. Wenn es nur um das Ausfuehren bestimmter Kommandos (z.B. Starten und Stoppen von Servern) mit root-Rechten geht, solltest Du einen Blick auf su1 oder sudo werfen. Diese Tools ermoeglichen es, bestimmten Benutzern oder Gruppen das Ausfuehren bestimmter Kommandos mit root-Rechten zu ermoeglichen. Geht es um das Veraendern von Konfigurationsdateien, so laesst sich da vielleicht mit Schreibrecht fuer eine bestimmte Gruppe was machen. Falls sich solche Dateirechte nicht mit den Anwendungen vertragen, koennte eine Loesung z.B. so aussehen: Von den fraglichen Konfigurationsdateien werden Duplikate in einem gesonderten Verzeichnis abgelegt, wo sie fuer eine bestimmte Gruppe schreibbar sind. Nach dem Veraendern der Dateien koennen die Mitglieder dieser Gruppe dann mittels su1 oder sudo ein Skript aufrufen, das mit root-Rechten diese Dateien an ihren endgueltigen Platz kopiert, dort die Rechte richtig setzt und ggf. noch betroffene Programme zum erneuten Einlesen ihrer Konfiguration veranlasst. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org - eilert@linuxfreak.com http://www.informatik.uni-bremen.de/~eilert/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com