chrooted SSH

D

dbudde

Mitglied
Hi Boarder,

Ich breche mir gerade die Finger an einer chroot Umgebung für SSH.

Wir hosten auf unserem Server Domänen diverser Kunden von uns, die mit der Zeit zunehmend anfragen ob die möglichkeit besteht, dass Sie einen SSH account auf unseren Server bekommen zur direkten Bearbeitung Ihres Quelltextes.

Nun sage ich meinen Kunden zunächst Nein, weil ich vermeiden will, dass diese sich nach SSH Login auf dem ganzen Server frei bewegen können.

Ich habe bereits eine chroot Umgebung für FTP Dienste mit vsftpd realisiert, was auch super funktioniert, aber wie ich das sehe ist eine chroot Umgebung für SSH Verbindungen nicht ganz so einfach zu realisieren. :)

Darum wende ich mich an dieser Stelle mal wieder an die Profis!

Wer kann mir helfen?

MfG

Dennis Budde
Viventu Systemhaus GmbH
 
Hallo
Das ist nicht so kompliziert wie du denkst.
Wenn der Server im Dateisystem in den Permissions richtig gesetzt ist, hat der user genau nur die Rechte für sein /home die das Lesen und Schreiben sensibler Daten ausserhalb verbieten.
Ein chroot ist da eigentlich nicht nötig.
Sensible Daten wie sshkeys oder Passwordfiles sollten ja ohnehin nur von den Eignern lesbar sein.

Gruß Wofgang
 
Ja gut das ist ja auch passiert, da der Server allerdings offen ist, möchte ich den Usern denen ich einen SSH Zugang gewähre sowenig spielraum wie möglich geben. Man weiß ja nie wo deren Kennwörter überall landen.

Ich kann ruhiger schlafen, wenn die User sich ausser in Ihrem Home Verzeichniss nirgendwo auf dem Server bewegen können, denn auch die Konfiguration und die gesamte Verzeichnissstruktu unseres Servers hat einen User nicht zu interessieren.




Wolfgang_1 schrieb:
Hallo
Das ist nicht so kompliziert wie du denkst.
Wenn der Server im Dateisystem in den Permissions richtig gesetzt ist, hat der user genau nur die Rechte für sein /home die das Lesen und Schreiben sensibler Daten ausserhalb verbieten.
Ein chroot ist da eigentlich nicht nötig.
Sensible Daten wie sshkeys oder Passwordfiles sollten ja ohnehin nur von den Eignern lesbar sein.

Gruß Wofgang
 
Hi Boarder,


Wie gesagt wenn ich Probleme habe Poste ich wieder :)

Während der Einrichtung musste ich feststellen, dass diese Anleitung auf Redhat aufsetzt.

Bis auf einige Pfadanpassungen hat die Installation auch soweit funktioniert.

Das init.d Script was kopiert wurde macht mir allerdings noch Probleme.

Zum beenden des Dienstes wurde killproc verwendet was ich durch killall ersetzt habe. funzt auch, aber an den folgenden Zeilen scheiter ich dann doch:

97 echo -n $"Starting $prog:"
98 initlog -c "$SSHD $OPTIONS" && success || failure
99 RETVAL=$?
100 [ "$RETVAL" = 0 ] && touch /var/lock/subsys/sshd
101 echo


Ich bekomme die Meldung, dass in Zeile 98 ein Fehler aufgetreten ist. initlog command not found.

Die restlichen Fehler im Script konnte ich soweit auch funktionell anpassen, aber an der Stelle kreisen bei mir die Fragezeichen!?!

Hat jemand eine Idee?


Dennis Budde
viventu Systemhaus GmbH
 
dbudde schrieb:
Wir hosten auf unserem Server Domänen diverser Kunden von uns, die mit der Zeit zunehmend anfragen ob die möglichkeit besteht, dass Sie einen SSH account auf unseren Server bekommen zur direkten Bearbeitung Ihres Quelltextes.
Nebenbei bemerkt: Wuerde deine Kundschaft auf ein ordentliches CMS setzen, braeuchte niemand per SSH am Quellcode zu frickeln.
 
lol

was isn das fürn quark?!

gerade wenn du nen richtiges cms hast musst du auch mal öfters was machen per shell.

ausserdem isses mit der shell einfach viel zu oft viel komfortabler :) nix geht über ne shell

mfg frank
 
von einem typo3-user war auch nix anderes zu erwarten... klar das du bei deinem quelltext eine ssh-shell benoetigst :> installiere doch mal eben zur abwechslung ne neue extension, gibt doch genug von...
 

Ähnliche Themen

IT System Engineer für Linux (m/w) in Voll- oder Teilzeit gesucht

Squid und SQL

SAN Boot über qlogic 2300 Adapter

Amavis und eTrust Antivirus

Server-Betriebssysteme auf dem Prüfstand

Zurück
Oben