<> ---- Die Zugangskontrolle für ''systemausfall.org'' bezieht sich ausschließlich auf den [[WikiPediaDe:Ssh|ssh]]-Zugang. Dies genügt zur Administration. Hinweis: im Folgenden bezeichnet ''NAME'' den Namen eines [[UML-Gastsysteme| Gast-Systems]]. = Allgemein = Das Ziel unserer Konfiguration ist die weitgehende Minimierung der Zugangsmöglichkeiten. Dabei muss jedoch ein gewisser Komfort für die Administratoren erhalten bleiben. Ein direkter ssh-Zugriff (von außerhalb des Host-Systems) auf die einzelnen Gast-Systeme ist nicht möglich. Nur das Host-System bietet einen ''ssh''-Zugang an. = Host-System = Der ''ssh''-Server ist direkt von außen zugänglich. Das Einloggen als ''root'' ist per ''ssh'' jedoch nicht möglich: * jeder Administrator hat einen eigenen Account * per ''su'' wechseln die Administratoren zum ''root''-Account Das Einloggen ohne gültigen ssh-key ist von außen nicht möglich: * als user mittels ssh-key und dem dazu gehörigen Passwort anmelden * achte auf den richtigen Port (22WC) Vorteile: * ein Angreifer braucht sowohl ein Nutzer-, als auch das ''root''-Passwort * Privatsphäre für die Admins :) * häufigere Passwort-Wechsel der Nutzer leicht umsetzbar Nachteile: * mehr login-Accounts * zwei Passwörter sind notwendig (Komfort!) = Gast-Systeme = == Zugang vom Host == * per ssh oder screen == Umsetzung == Das Login in ein Gast-System erfolgt indirekt: * zu jedem Gast-System existiert ein Nutzer im Host-System (Nutzername: ''uml-NAME'') * diese Nutzer erlauben den Zugang nur mittels [[WikiPediaDe:RSA-Kryptosystem|RSA]]-Schlüssel * jeder dieser Nutzer des Host-Systems besitzt einen weiteren RSA-Schlüssel, der ihm den passwort-freien Zugang zu dem dazugehörigen Gast-System gestattet * jedem rsa-Schlüssel, der den Zugang zu einem UML-Nutzer erlaubt, wird in der ''~/.ssh/authorized_keys'' das folgende ''force-command'' zugeordnet: {{{ command="sh -c 'ssh -l root ${USER#uml-} $SSH_ORIGINAL_COMMAND'" [hier folgt der dazugehörige rsa-Schlüssel]}}} * damit wird die transparente Weiterleitung von ''scp''-Anforderungen möglich Diese Methode erlaubt einem böswilligen Angreifer, der sich in einen dieser Gast-System-Accounts einloggen kann, lediglich den Zugriff auf die Daten dieses Gast-Systems auf dem Host, da die Gast-System-Verzeichnisse verschiedenen Nutzern gehören und keinen fremden Zugriff gestatten (Dateirechte). == Zugang von außen == === Schlüssel-Import === Um von außen per ssh in ein uml zu gelangen, bedarf es kurzer Vorarbeit. 1. auf einem sicheren Rechner den RSA-Schlüssel erstellen - '''''passwortgeschützt!''''': {{{ ssh-keygen -t rsa -b 4096 }}} 1. den öffentlichen Schlüssel (üblicherweise ''~/.ssh/id_rsa.pub'') zum Host-System kopieren 1. dann auf dem Host-System einloggen und (als root): {{{ /uml/scripts/admin-uml.sh import-key UML KEYFILE }}} Fertig! === Nutzung === Ein Administrator, dessen RSA-Schlüssel für den jeweiligen Gast-System-Nutzer gültig ist, kann sich per `ssh uml-NAME@systemausfall.org` einloggen. Beim Login in das Host-System wird automatisch die ''ssh''-Verbindung zum passenden Gast-System weitergeleitet. In kurzen Worten: mensch ist sofort drin, falls sein RSA-Schlüssel akzeptiert wurde. Auch ''scp'' ist problemlos möglich. === Nutzung bei mehreren RSA-Schlüsseln === Wenn der Rechner von dem aus du dich einloggen willst mehrere ssh-sec/pub-keys besitzt, hilft folgendes (wie auch im nächsten Punkt beschrieben): * in .ssh die keys reinkopieren (z.B. ~/.ssh/server1_rsakey) * in .ssh eine config für einen bestimmten server erstellen (z.B. server1_conf) {{{ echo "Host server1" >> ~/.ssh/config echo "IdentityFile ~/.ssh/server1_rsakey" >> ~/.ssh/config }}} * jetzt folgendermaßen einloggen {{{ ssh nutzer@server1 }}} == Zugang vom Host-System aus == Die Datei ''/root/.ssh/config'' enthält für jedes UML-System einen Eintrag nach dem folgenden Muster: {{{ Host NAME IdentityFile /uml/chrootjail/guests/NAME/.ssh/id_rsa }}} Der root-Nutzer im Host-System kann durch ein einfaches `su NAME` seine Identität wechseln. Als jeweiliger Nutzer kann dann per `ssh root@uml-hostname` (z.B.: ssh root@bastelecke) in das uml gewechselt werden. Dabei wird der ssh-key benutzt, also kein weiteres Passwort abgefragt. * ?stimmt das noch?: Somit genügt dem root-Nutzer im Host-System ein einfaches `ssh NAME`, um passwortfreien Zugang zu dem Gast-System zu erlangen (der passende RSA-Schlüssel wurde durch die ''ssh-config''-Datei automatisch ausgewählt). Diese Zugriffsmethode bleibt den anderen Nutzern verschlossen, da die Dateirechte für die Schlüssel der Gast-System-Nutzer äußerst restriktiv sind. = Diskussion des Sicherheit = Vorteile: * nur ein ''ssh''-Server muss sicher konfiguriert werden * das Ganze ist ziemlich leicht wartbar (alles wird von Skripten erledigt) * nur ein ''ssh''-Port für alles * mehrere [[WikiPediaDe:Maintainer|Maintainer]] eines Gast-Systems müssen kein gemeinsames Passwort verwenden * die Maintainer müssen sich nicht verschiedene Passworte für die verschiedenen betreuten Gast-System merken * Zugriffe von einem Gast-System zu einem anderen sind nicht möglich, da der notwendige RSA-Schlüssel nur im Host-System liegt - dies beseitigt die übliche Gefahrenquelle des Eintippens von Passworten auf entfernten Systemen (die eventuell von einem Angreifer übernommen wurden - [[WikiPediaDe:Keylogger|Keylogger]]!) * der ausschließliche Zugang mit einem (passwortgeschützten) RSA-Schlüssel ist vergleichsweise sicherer als die Verwendung eines Login-Passworts, da der Angreifer sowohl Zugriff auf deinen Schlüssel, also auch auf dein Passwort benötigt Nachteile: * das Host-System stellt einen Dienst nach außen hin zur Verfügung -> verwundbar * ''root'' auf dem Host-System darf alles (jedoch auch unabhängig von dem ''ssh''-Zugang) * dank LIDS nicht wirklich relevant (in ferner Zukunft) * mehrere Login-Accounts auf dem Host-System