On Tue, 12 Jul 2005, Saskia Whigham wrote: > macht es Sinn ssh in einer chroot Umgebung laufen zulassen wenn man > über z.B. Fernwartung diesen Server wo sich der ssh Prozess drauf > befindet administrieren will. Die Administration soll im vollem Umfang > ablaufen das heisst man brauch auch Zugriff auf /etc usw. . Ist in > diesem Fall eine chroot überhaupt möglich. Also ich habe das in den > einzeln. Dokus so verstanden das wenn man einen User hat und der nicht > als super User fungieren soll diesem User eine chroot ssh zur > Verfügung stellt um per scp einige Dateien zu verschieben. Für den > Admin gebrauch fürs ganze system wäre dann ja wohl eine chroot > Umgebung nicht so sinnvoll oder?
Yup, sehe ich auch so. > Ich habe schon viel über SSH absicherung gelesen. Vielleicht habt ihr > ja noch eine Möglichkeit um ein sichers ssh zu ermöglichen. Fuer Zugriff von aussen nur PublicKey erlauben (siehe aber weiter unten). Ganz wichtig und gerne uebersehen: * Du darfst die Datei .ssh/authorized_keys nicht mit einem Dateisystem wie NFS verteilen! Dann braucht sich nur jemand bei Euch im Netz mit dem Laptop dranstoepseln und kann die Dateien lustig kopieren und "zu Hause" knacken. Weil das per default aber $HOME/.ssh/authorized_keys ist, musst Du das bei Benutzung von NFS o.ae. aendern mit (z.B.): AuthorizedKeysFile /ssh%h/authorized_keys Das entspricht --> /ssh/home/jens/authorized_keys * Den Benutzern einpraegen, dass sie keine leeren Passwoerter bei der Generierung des Schluessels benutzen. Besonders in Zshg. mit NFS ist das toedlich, auch sonst grob fahrlaessig. Es gibt Leute, die benutzen diese Methode "aus Bequemlichkeit" fuer den key von root, um mehrere Systeme zu administrieren, das ist genauso bescheuert. Das geht besser, auch dann, wenn man den root-Zugriff fuer Skripte benoetigt. Den root-Zugriff von aussen kannst Du ausschalten oder nicht, das ist m.E. nicht so wichtig. Wenn Du ihn aber ausschaltest, musst Du auf jeden Fall einen lokalen Benutzer-Account bereithalten der in /etc/passwd steht und nicht ueber LDAP oder NIS kommt. Sonst kannst Du fuer den Fall, dass sich der LDAP-Server aufhaengt, auch Deinen Server vergessen. Wenn die Systeme in einem homogenen Verbund stehen, kannst Du zusaetzlich noch "HostbasedAuthentication" einsetzen (das ist die alte .rhosts-Methode, nur jetzt zusaetzlich durch Schluessel abgesichert). Da authentifizieren sich diese Systeme untereinander ueber PublicKeys und erlauben Benutzern gleicher ID den gegenseitigen Zugriff. Das geht aber nicht fuer root. Wenn Du also PublicKey und fuer die Rechner untereinander HostbasedAuthentication angeschaltet hast, kannst Du schliesslich mit "ChallengeResponseAuthentication no" den Zugriff von aussen abschalten. Dann werden alle Leute, die nicht von einem internen Host oder mit einem gueltigen PublicKey ankommen, ignoriert. Das wuerde ich aber nicht fuer alle Systeme so machen, halte Dir noch ein, zwei Systeme mit ChallengeResponse offen, sonst bleibst Du draussen, wenn's hart kommt, und Du von einem neuen Rechner ohne Schluessel noch mal ins System musst. Viel Spass beim Ausprobieren Jens
