Re: chroot ssh

[Jens Ruehmkorf <ruehmkorf@informatik.uni-koeln.de>]

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