Frühaufsteher und Spät-zu-Bett-Geher in einem.

Jetzt fällt mir noch eines auf: Der Server funktioniert ohne TLS - dann ist
das oben aber bestimmt nicht die komplette .conf-Datei, oder?
Das kann nicht passen.

mfg.
  VolGas

Mir sagt das leider auch nichts... (außer daß Du "lustige" IP-Adressen hast)
Vielleicht muß man sich wirklich den ganzen Output angucken.

Aber versuchen wir es erst anders herum: wie hast Du die SSL-Zertifikate erstellt?
Noch was: hast Du den ProFTPD mit den selben SSL-Bibliotheken compiliert,
mit denen dann später auch die Zertifikate erstellt wurden?

mfg.
  VolGas

Sind die Zertifikate für den ProFTPD überhaupt erreichbar?

Probiere einmal das Ganze im Debug-Modus -vielleicht kannst Du dann erkennen, was los ist...
...wenn nicht, einfach die Zeilen ab Beginn des Verbindungsversuchs hier posten...

mfg.
  VolGas

Hallo,

wir verwenden zwar selbst kein "PathDenyFilter" (also habe ich da keine Erfahrung),
es kann aber nur dieses sein und  ich habe da einen Verdacht: deaktiviere doch einmal
PathDenyFilter "(\.ftpaccess)|(\.ht)[a-z]+$"

Geht es dann?
Wenn nicht, dann grenze das Ganze einfach immer weiter ein.

Der Debug-Modus kann aber auch sehr hilfreich sein... ;-)

mfg.
  VolGas

Hallo!

Was meinst Du mit "eigenen" Zertifikat.?
Zertifikat auf dem Server oder auf dem Client?
Wohl ersteres... (IMHO auch mehr als ausreichend)

Es kann hilfreich sein, "TLSProtocol" aus Kompatibilitätsgründen zuerst einmal auf "SSLv23" zu belassen.
Nicht jeder Client kommt mit dem neuen TLS-Protokoll zurecht...

BTW: Ist "TLSRequired" wirklich notwendig?
Nicht sehr benutzerfreundlich, denn nicht jeder hat einen sicheren
Client zur Hand und kommt damit auch noch zurecht...

mfg.
  VolGas

Steht doch da: TLS-Zertifikat fehlt.

Entweder eines dort anlegen, wo es erwartet wird - oder: TLS ausschalten.

mfg.
  VolGas

[Server]

Ich hätte es einmal damit versucht:

Code:

$config_database_user                = 'MeinUserName';
$config_database_passord             = 'meinPasswort';
$config_database_database            = 'meineDB';
...

Aber ob das so für das System vorgesehen ist, weiß ich nicht.

Dieses Forum ist nur gedacht für den ProFTPD-Server,
nicht für irgendwelche Administrations-Scripte.

Wendet Euch doch bitte an ein/das entsprechendes Forum oder den/die Verfasser des Systems.

mfg.
  VolGas

Schmeiß' den einen "Directory"-Block raus und dann:

Code:

<Directory ~>
<Limit WRITE>
AllowUser administrator
DenyAll
</Limit>
</Directory>

<Directory ~/*>
<Limit WRITE>
AllowAll
</Limit>
</Directory>

Feierabend!

mfg.
  VolGas

Die die Berechtigung "rw-r-----" ist für Dateien in Ordnung, aber für
Verzeichnisse sollte es "rwxr-x---" sein, sonst klappt das mit den Usern und dem Apachen nicht!

Deinen "directory"-Block läßt momentan noch jeden in Dein "root"-Verzeichnis,
es fehlt der Teil der weiter oben im Thread beschrieben wurde, um auch dieses zu sperren.

Nach wie vor würde ich Dir noch einmal empfehlen, Deine Struktur zu überdenken!
Jedem User sein eigenes home-Verzeichnis und dann dort für jede Domain ein Unterverzeichnis.

Es wurde in diesem Thread nun alles relevante mindestens schon einmal angesprchen.
Das sollte schon längstens ausreichen, damit Du von selbst weiterkommst.

mfg.
  Volker

Bitte einen, nein, besser gleich zwei Schritte zur Seite!

In mySQL werden zu den Usernamen UID/GID's vergeben, die nach einem erfolgreichen Einloggen
dann von dem laufenden ProFTPD-Prozess übernommen werden.

Das ist genau so, als hätte man sich als existierender Systemuser mit einer Shell eingeloggt,
ohne daß aber dieser besagte Shelluser wirklich im System angelegt sein muß.

Ebenso kann man auch im Filesystem mit nicht im System eingetragenen Usern und Gruppen arbeiten.

Ich hoffe, ich habe mich nun verständlich genug ausgedrückt.

mfg.
  VolGas

Sobald man als FTP-User eingeloggt ist, hat der zugehörige ProFTPD-Prozess die vordefinierten UID/GID des Users.
Damit gelten die Unixrechte uneingeschränkt und genauso als hätte man sich mit einer Shell eingeloggt!

Zu Punkt zwei:
das hatte ich nicht richtig realisiert - ich dachte, es ginge dabei nur um einen Admin. Nun ist klar.

Den User kann man entweder durch geschickt gesetzte Unix-Rechte reglementieren
oder aber durch die zwei "Directory"-Blöcke weiter oben in diesem Thread.

Jetzt sollte aber alles geklärt sein.

mfg.
  VolGas

Mit Limitierungen meine ich den ganzen "<Directory ~/*>..." Block.

"Quota" und "Ratio" ist sowieso auskommentiert.

Meine Güte: Grundwissen und (selbst) Nachdenken!
chmod u=rwX,g=rX,o= /pfad/wohin/auch/immer

mfg.
  VolGas

Ich gehe davon aus, daß die Gruppenrechte dazu da sind, daß der Apache ebenfalls auf die Dateien zugreifen kann.
Dann wäre "umask 037 027" die sicherste Einstellung.
(User darf alles, Gruppe: Dateien nur lesen, Verzeichnisse "öffnen" und lesen, sonst kein Zugriff)
Umask 000 ist wohl die denkbar schlechteste Einstellung.


Was mir sonst noch an der .conf aufgefallen ist:

* "AllowOverwrite on" braucht kein umgebendes "Directory"
* Sind die Limitierungen wirklich (noch) notwendig?
* Solange Deine User keine Shell brauchen, reicht "SQLUserInfo users userid passwd uid gid homedir NULL" völlig aus.
Das Datenfeld in der mySQL-Tabelle braucht dann nicht mehr gepflegt und kann auch weglassen werden.
Dies gilt alalog auch für "gid", wenn alle User in der selben Gruppe sind - das ist sicherer. SQLDefaultGID ist ja vorhanden.
* SQLHomeDirOnDemand könnte man -streng genommen- als Risiko einstufen, ist aber ok.

Einen Fehler konnte ich nicht entdecken. (was aber nicht unbedingt etwas bedeutet)

mfg.
  VolGas

Aua, aua!

Mit dem Adminstrator und den Zugriffsrechten ist das immer so eine Sache -
man sollte dies vorher gründlichst überdenken und planen!
So ganz kann dies nämlich nicht funktionieren, wie Du das möchtest,
dazu müßtest Du nämlich root-Rechte erhalten (NEVER-EVER per FTP!!!)

Man kann aber versuchen, zumindest etwas ähnliches zu erreichen,
indem man allen Usern die selbe Gruppe zuweist und umask auf 007 setzt.

Dann noch:

Code:

<Directory ~>
<Limit WRITE>
AllowUser administrator
DenyAll
</Limit>
</Directory>

<Directory ~/*>
<Limit WRITE>
AllowAll
</Limit>
</Directory>

Das hat allerdings den gravierenden Nachteil, daß jeder User in den Verzeichnissen
der anderen stöbern und wildern kann, sofern diese nicht selbst die Zugriffsrechte ändern.

Warum gehst Du nicht hin, und machst dies so:
* jedem User sein eigenes Verzeichnis
* alle User die selbe Gruppe
* umask=007
* home von administrator in das übergeordnete Verzeichnis

Der "administrator" hat zwar auch nur Zugriff, wenn die User das nicht ändern, aber immerhin...

Meine Meinung:
Am besten hält man die User- und Gruppenrechte so restriktiv wie möglich und
erledigt seinen Admin-Job über die Konsole z.B. mit mc!

mfg.
  VolGas

Ich denke, so könnte es funktionieren wie Du es möchtest:

Code:

<Directory ~>
<Limit WRITE>
DenyAll
</Limit>
</Directory>

<Directory ~/*>
<Limit WRITE>
AllowAll
</Limit>
</Directory>

Im Home-Verzeichnis selbst werden alle schreibende Zugriffe verboten,
aber in den darunter liegenden Verzeichnissen wird es wieder erlaubt.

mfg.
  VolGas