Hallo Michael, Michael Hilscher wrote,
On Mon, Jul 22, 2002 at 09:30:28PM +0200, Waldemar Brodkorb wrote:
Hmm. Vom ersten Eindruck her würde ich: http://www.solucorp.qc.ca/miscprj/s_context.hc dem UsermodeLinux: http://user-mode-linux.sourceforge.net vorziehen. Der Punkt ist jedoch, dass diese Projekte über den Kern in meinen Augen hinausschiessen und auf "einem kleinen Intel 1200mhz Server" schnell zu PerformanceProblemen führen dürften. Mal ganz abgesehen von dem riesigen Aufwand der *pro* Nutzer anfallen würde.
Ich meinte diese Software: http://www.freevsd.org/ Auch sehr interessant. Kommt Zeit kommt checkout ...
Wieviel Benutzer erwartest du auf der 1,2 GHz mühle? Vorallem wieviel RAM hat der Rechner? Die Benutzeranzahl steigt mtl. Sobald es für die Kiste zu viel wird kommt halt ne Zweite. Es ist aber die Frage ob sich Aufwand generell lohnt - zur Zeit müssen sich die Leute eben mit einem FTP-Einmalpasswort und einem sehr restriktiven Apache für alle abfinden.
Zur Zeit sind lediglich 256MB Ram eingebaut. Wie sehen denn Deine Erfahrungswerte (hinsichtlich Benutzeranzahl) aus?
Ich habe ja nur cvs und sftp gechrootet. Apache und SSH läuft real. Wenn du Apache, MySQL und SSH Instanzen für jeden gechrootet anbieten willst, wird es halt irgendwann den Hauptspeicher aufbrauchen.
Gibt es nicht (doch) eine Möglichkeit sftp / scp wie bei FTP-Servern üblich einen DocumentRoot auf ~ zu verpassen? Mit patch von openssh schon. Habe ich für sftp-only Zugang schon mal realisiert. Ist ein kleiner patch gegen sftp-server.c. Escape character is '^]'. SSH-1.99-OpenSSH_3.4p1 Debian 1:3.4p1-2
Und der ist gepatcht. Wenn man sich den trivialen Patch anschaut, weiß man auch das es keinen Stress macht. Ja welchen Patch hasst Du denn verwendet - es finden sich mehrere, habe aber wie gesagt ein kleines Vertrauensproblem zu den Quellen. Aber wenn Du Deinen schon länger im Einsatz hast, würde ich mir _diesen_ doch mal näher ansehen :-)
Kommt per PM.
Da muß ich dir recht geben, allerdings halte ich es so, das ich nur den sftp-server-Code patche, dieser wird _nach_ erfolgreicher Authentifizierung als Subsystem vom sshd gestartet, sodaß ich die Gefahr eines unerkannten exploits als gering einschätze. Außerdem können nur berechtigte User bis dahin gelangen, außer sshd enthält den Exploit.
Die sftp-server Applikation muß mit dem SUID-Bit versehen werden, um den SystemCall chroot benutzen zu können, kurz danach wird aber dieses Privileg wieder abgelegt. Hmm: ist es möglich sftp Zugang für XY zu gewähren aber ssh Zugang zu verbieten?
Klar.
Es wäre doch Unsinn wenn sftp chrooted wird aber ssh "frei zur Verfügung steht"?
Jupp. # ssh waldemar@fqdn This is a restricted account. You cannot execute anything here. Goodbye. Connection to fqdn closed. Ziel war es eine sichere Möglichkeit zum Upload und zur Benutzung von CVS zu implementieren. Beides wird über SSH geregelt. Btw: Das kommerzielle SSH von ssh.com macht auch nix anderes als ne restricted shell, in der chroot() ausgeführt wird :) In meinem Fall ist die Shell ein Perlskript, welches nur bestimmte Befehle (cvs, /usr/lib/sftp-server) erlaubt. Kommt auch per PM. gruß Waldemar -- 8485 D0CE 2743 656E 867C 5C93 0317 AFD8 BE21 BD90