Da scheint etwas nicht zu stimmen - das war wohl nicht Deine Maschine.

Ich gehe nun für das weitere Vorgehen davon aus, daß Dein ProFTPD lokal funktioniert.

Für die Benutzung hinter einem NAT-Router reicht die Verwendung von "MasqueradeAddress"
alleine noch nicht aus. Du mußt noch eine Lücke für die sog. "high ports" in Deine Firewall
"schlagen", d.h. Du benötigst ein Portforwarding in Deinem Router für den "passive mode".
(Dein FTP-Client sollte immer nur den "passive mode" nutzen!)

Richte im Router einen Portforwarder für z.B. die Ports 50000 bis 52000 ein.
In der proftpd.conf muß dann analog dazu noch "PassivePorts 50000 52000" stehen.
Den ProFTPD neu starten, hoffen, und versuchen diesmal die richtige Maschine zu treffen.

Es kann aber durchaus sein, daß es Dir wirklich nur von außerhalb gelingt, auf Deine
Maschine zu kommen - das hängt von dem IP-Resolving Deines Arbeitsplatzrechners ab.
Versuche es einfach und poste ggf. den Debug-Output wie schon beschrieben.

Viel Erfolg!

mfg.
  VolGas

Hallo!

Deine proftpd.conf sieht eigentlich gut aus, mir ist nach kurzem Überfliegen nichts aufgefallen.
Was mich etwas stutzig gemacht hat, ist Deine Bemerkung "bekomme ich übers Netz von außen".
Wenn Dein Server hinter einem Router mit NAT erreichbar sein soll, siehe Direktive ->MasqueradeAddress
Damit wäre ebenfalls die Problematik der TLS-Zertifikate zu beachten: sie sind auf eine IP "fixiert".
Generell würde ich TLS zunächst ausschalten "TLSEngine off", bis alles getestet ist und funktioniert.

Zu Deinem Debug-Output: leider kann man damit nichts anfangen, da dieser nicht von einem Login stammt.
Diesen Teil des Output kannst Du jeweils verwerfen. Was interessant ist, ist die Ausgabe ab dem Zeitpunkt,
an dem versucht wird, sich einzuloggen.

Zu dem Thema Root-Rechte: normalerweise wird der ProFTPD als "root" gestartet und schaltet sich dann
aus Sicherheitsgründen auf einen angegebenen User um. Beim Einloggen wird ein neuer Prozess gestartet,
der dann kurzfristig auf die Root-Rechte zurückschaltet, um die Identität (UID/GID) des Users anzunehmen.
Damit verliert dieser abgespaltete Prozess engültig alle Root-Rechte und erst dann ist der Login komplett
(so oder so ähnlich, man möge mir Fehler im Detail nachsehen). Wenn die FTP-Session beendet wird,
wird auch der dem User zugeteile Prozess beendet. Du must Dir darüber nicht wirklich Gedanken machen,
das funktioniert normalerweise sehr zuverlässig.

Deaktiviere also zunächst noch einmal TLS und poste hier ein Debug-Ouput eines Loginversuchs,
dann sehen wir weiter.

mfg.
  VolGas

Hallo!

Betrachte den ProFTPD wie eine Shell für den aktuell eingeloggten User:
es gelten genau die Zugriffsrechte und Beschränkungen des Filesystems
die der User auch per Telnet/SSH/etc... hätte!

Einen "Masteraccount" ließe sich damit -wenn überhaupt!- nur über Gruppenrechte realisieren.
Es bleibt Dir nur übrig, Dich als "root" einzuloggen (never-ever per FTP!)
und damit das Filesystem zu administrieren.

mfg.
  VolGas

Hallo,

die Antwort weiß ich nicht wirklich, aber siehe einmal die Beschreibung
für die Direktive ->ShowSymlinks

Ich hoffe, das hilft Dir weiter.

mfg.
  VolGas

Au weia - Du meine Güte!
Nein, natürlich nicht!

Die "umask" weist keine Gruppe zu, sondern ist eine Maske für Default Datei- und Verzeichnisrechte!

Normalerweise lauft der Apache nicht mit so einer kleinen Gruppen-ID, sondern z.B.
unter der Gruppe "nobody" (= 65534 = Standard). Das solltest Du vielleicht noch ändern.

Aber es stimmt - wenn die Gruppe für den Apache die ID 33 hat (und behält), dann müßtest
Du "SQLDefaultGID 33" setzen.

Wie umask funktioniert, werde ich hier nicht beschreiben. (das wäre wie das Rad neu erfunden
und auch hier nicht angebracht - Du solltest wirklich unbedingt das Linux-Buch vom Kofler lesen!)
Aber eine -meiner Meinung nach- sinnvolle Einstellung für FTP-User mit "Apache-Anschluß"
gebe ich Dir noch gerne mit: "umask 117 007"

Nochmal: lies das Linux-Buch von Kofler oder suche Dir zumindest im Internet ein paar gute
Quellen für das notwendige Grundwissen. (z.B. http://www.faqs.org/docs/lnag/lnag_basics.html)

mfg.
  VolGas

Nachtrag:

die erste proftpd.conf ganz oben sieht soweit eigentlich recht gut aus.
Ich würde noch folgendes ändern/hinzufügen:

• Es hat sich herausgestellt, daß die DelayEngine immer wieder Schwierigkeiten machen kann.
  Daher: "DelayEngine off"
• Ändere die Zeile mit "SQLAuthenticate" um zu: "SQLAuthenticate users*"
• Um die Authentifizierung auf SQL zu beschränken, reicht in den neueren Versionen des
  ProFTPD die gerade erwähnte Direktive nicht mehr aus. Daher noch: "AuthOrder mod_sql.c"
• Wenn Du mit "SQLUserInfo" die UID/GID des FTP-Users definieren läßt,
  verbietet sich der gleichzeitige Einsatz von "SQLDefaultUID" und "SQLDefaultUID"
• Aua, Aua! Autsch: "SQLMinUserUID" und "SQLMinUserUID" = 0

Mit den vorgeschlagenen Änderungen dürfte es (wenn ich nichts übersehen habe)
dann auch wieder funktionieren. Ab den "aktive SQL Kommandos" habe ich es
mir allerdings erspart weiter nachzusehen - da hört dann die Nächstenliebe auf...

mfg.
  VolGas

Hi!

In dieser proftpd.conf wird zwar vieles konfiguriert,
aber was wirklich wichtig ist, fehlt leider!

Versuche es einmal mit:

DelayEngine         off
RequireValidShell   off
DefaultRoot         ~

Zusätzlich, für ein schnelleres Login (ohne unnötige Netzabfragen):

UseReverseDNS      off
IdentLookups      off

Damit sollte es dann funktionieren...

mfg.
  VolGas

aber weiter oben hast du geschrieben das es nicht mit dem Filesystem zu tun hat

Habe ich - wo

Wenn die hochgeladenen Files mit dem Apache dargestellt werden sollen, dann sollte
die GID für die FTP-User die selbe sein, wie für den Apache-User. (entsprechend ist
"Umask" zu setzen!)

Für die UID's kannst Du alles ab 1000 setzen.

So könnte z.B. die SQL-Konfiguration in Deiner proftpd.conf aussehen:

AuthOrder mod_sql.c
SQLConnectInfo ftpdb@localhost proftpd s900s900
SQLUserInfo users userid passwd uid NULL homedir NULL
SQLAuthTypes Plaintext
SQLAuthenticate users*
SQLMinUserUID 1000
SQLDefaultGID 65534
SQLLOGFILE /var/log/proftpd.sql.log

Was Du noch zur Beschleunigung des Logins tun könntest:
"UseReverseDNS off" und "IdentLookups off"

Sodele, viel Spaß noch - ich mache nun Feierabend!

mfg.
  VolGas

Prima, daß das nun klappt.

Aber die UID/GID für alle FTP-User gleich zu setzen ist ein echtes Sicherheitsproblem.
Zudem ist UID/GID 100 zu klein und damit in den für das System reservierten Bereichen.

Ich würde empfehlen, für jeden User eine eigene UID zu verwenden und für alle eine
gemeinsame Gruppe (am besten die des Webservers).

Die UID ist die User-ID und GID die Group-ID für das Filesystem.
Diese ID's haben tatsächlich etwas mit der User- und Rechteverwaltung zu tun,
aber das Filesystem benötigt keine User-Einträge im System um Zugriffsrechte
zu realisieren und zu nutzen.

Das ganze Thema gehört zum absolut untersten Unix-Grundwissen!
Ich kann Dir daher nur allerwärmstens und dringend z.B. das Standardwerk,
den "Kofler", zum Lesen ans Herz legen!

mfg.
  VolGas

Hi,

was ich bei meiner ersten Antwort übersehen habe, aber unbedingt vorhanden sein muß: "DefaultRoot ~"
Nur damit wird der User in sein Verzeichnis "gebeamt" und dort eingesperrt (chroot).

Generell zum Verständnis: der ProFTPD wird nach dem Einloggen quasi zur Shell des
einloggende Users mit genau den selben Rechten und Beschränkungen wie dieser.
Sollte das nicht funktionieren (falsches Verzeichnis oder keine Berechtigung) schlägt
der Login fehl. Daher kann eine "minimale Konfiguration" nur mit Username und PW
so niemals funktionieren.

Nun weiter zu Deinem Posting:

• reaktiviere unbedingt "SQLAuthenticate users*"!
• Das alleine geht auch nicht: "SQLUserInfo users userid passwd NULL NULL NULL NULL"
  Zumindest "homedir" sollte vorhanden sein, sonst ist ein Default mit"SQLHomeDIR" zu setzen.
  Analog dazu: für "uid" sollte "SQLDefaultUID" oder zumindest "SQLMinUserUID" und
  für "gid" sollte "SQLDefaultGID" oder zumindest "SQLMinUserGID" gesetzt sein.
  Siehe auch ->Direktive SQLUserInfo
• Ein "SQLGroupInfo" wird nicht gebraucht.
  Achtung: dort definierte Gruppe(n) haben NICHTS mit den GIDs des Filesystems zu tun,
  sondern sind nur intern zur Gruppendefinition für den ProFTPD!
• In der SQL-Tabelle ist "uid" als UNIQUE KEY nicht sehr sinnvoll und "userid" als PRIMARY fehlt.
  Um es kurz zu fassen poste ich einfach eine sinnvolle Tabellendefinition:
  

  CREATE TABLE `users` (
    `userid` varchar(24) binary NOT NULL default '',
    `passwd` varchar(24) binary NOT NULL default '',
    `homedir` varchar(255) NOT NULL default '/var/www/',
    `uid` smallint(6) unsigned NOT NULL default '65534',
    `gid` smallint(6) unsigned NOT NULL default '65534',
    PRIMARY KEY  (`userid`),
  ) TYPE=MyISAM;

• Bitte lies die Postings und die Supportseiten genau durch - da steht schon alles!

Wenn Du das beachtest hast, sollte es jetzt aber funktionieren.

mfg.
  VolGas

Hi,

Deine proftpd.conf ist ja sehr "übersichtlich"...

Füge in Deine profptd.conf noch ein: "AuthOrder mod_sql.c" - das sorgt dafür,
daß alle anderen Auth-Module (außer SQL natürlich) nicht weiter verwendet werden.

Was mir noch aufgefallen ist: wenn Du unterschiedliche UID und/oder GID benutzen
möchtest, dann verbietet sich analog dazu die Benutzung von "SQLDefaultUID" / "SQLDefaultGID".
Dann kannst Du bei "SQLUserInfo" die entsprechenden Werte auch auf "NULL" setzen.
Das/die Datenfeld(er) in der SQL-Tabelle wird/werden dann nicht weiter berücksichtigt
und kann/können damit auch gelöscht werden.

Das setzen von "RequireValidShell off" ist sehr gut, bei "SQLUserInfo" kannst Du noch "shell"
durch "NULL" ersetzen und brauchst damit in Deiner SQL-Tabelle auch dieses Feld nicht mehr.

Ich hoffe, ich konnte Dir damit weiterhelfen...

mfg.
  VolGas

Hallo,

Du machst es Dir sehr einfach, ich daher auch: siehe ->Support auf dieser Website!
Wenn Du konkrete Fragen haben solltest, dann gerne wieder hier...

Ich habe den Eindruck, daß ich Dir noch wärmstens das Linux-Standardwerk,
den "Kofler" ans Herz legen sollte...

mfg.
  VolGas

Ja!

Wenn Du -was man normalerweise macht- den/die User in sein Homeverzeichnis
mit DefaultRoot ~ "einsperrst" (chroot), hat auch der ProFTPD keine Möglichkeit
mehr, außerhalb dieses Verzeichnisses auf irgend etwas zuzugreifen.

Man muß dem den User zugeteilten ProFPTD-Prozess wie eine User-Shell betrachten:
sie hat die selben Rechte und Restriktionen wie der User selbst.

Deine Files müßtest Du also in dem Fall einer chroot-Umgebung in der Verzeichnis-
struktur des jeweiligen Users unterbringen. Mit etwas "Zauberei" in der proftpd.conf
kann man aber Dateien vor den Blicken und dem Zugriff des Users sicher entziehen.

mfg.
  VolGas

Hallo,

es gelten die Userrechte des Filesystems. Es gilt generell: es ist völlig egal,
ob für eine UID/GID ein User/eine Gruppe im System eingetragen ist oder nicht.
Für das Filesystem ist dies völlig unerheblich.

Was man mit dem ProFTPD zusätzlich machen kann, sind weitere "Regeln" zu
definieren (User darf/darf nicht schreiben, etc.), deren Basis aber immer die
Rechte des Filesystems darstellen und diese niemals außer Kraft setzen können.

Nach dem Einloggen ist der aktuelle ProFTPD-Prozess nur noch wie ein normaler
Systemuser mit seinen ihm zugewiesenen Rechten zu sehen - mehr nicht.
Man könnte auch sagen: der ProFTPD ist des Shell des eingeloggten Users...

Ich hoffe, das hilft Dir in Deinem Verständnis ein Stückchen weiter.

mfg.
  VolGas