Hallo,

ich bin wieder da und würde auch vermuten, daß im System etwas nicht (richtig) konfiguriert wurde.
Ich hätte noch eine Idee, was man probieren könnte: probier mal dem ProFTPD explizit über
"DefaultAddress ..." mitzuteilen, welche IP-Adresse er verwenden soll.
Vielleicht klappt das...

mfg.
  VolGas

Mit (x)initd kenn' ich mich nicht aus,
aber mach mal noch in die .conf: "RequireValidShell off"

mfg.
  VolGas

Und was soll er in sein Referat reinschreiben?

"Mit yast installiert - da hat's funktioniert...
...warum und wie - das weiß nur das liebe Vieh!" ?

Das gibt nicht wirklich etwas her und dann hat er auch nichts davon.
Er soll sich ja etwas in die Materie einarbeiten und ggf. Rede und
Antwort stehen können, oder?

Wenn denn dem nicht so ist, dann hat sich das seit "meiner Zeit" aber
gewaltig verändert. Dann wundert mich PISA aber wirklich auch nicht mehr... :roll:

mfg.
  VolGas

Hi!

Wow, Da hat sich jemand aber ganz schön Mühe gegeben!
Jetzt im Detail darauf einzugehen wird mir -ehrlich gesagt- zu viel und warum das Login
nicht klappt, ist mir auch nicht ganz klar.

Ich versuche nun auf die Punkte einzugehen, die mir aufgefallen sind:

[*]Fasse zuerst alle möglichen Anweisungen im <Global>-Block zusammen.
[*]Prima: DefaultAddress, SocketBindTight, DefaultServer, <VirtualHost ...>
Weglassen: Bind (unnötig und "depricated")
[*]<Limit LOGIN PASV PORT>: Login ist klar, aber warum den "passive mode"
verbieten - dieser ist doch normalerweise ausdrücklich erwünscht?!
[*]DefaultChdir /home/ftpdaten entfernen
[*]Du machst Dir mit deinen "Limits" das Leben ganz schön schwer.
Drehe die Logik um und es wird wesentlich einfacher (und kürzer):

Code:

<Limit LOGIN>
  DenyGroup !ftpuser
  </Limit>

<Directory /home/ftpdaten>
 <Limit WRITE>
    DenyAll
  </Limit>
</Directory>
...

Das dürfte das selbe bewirken wie das, was Du erreichen wolltest.
[*]Daran denken: die System-Zugriffsrechte können nicht "ausgehebelt" werden![/list]Ich habe mir erlaubt und -auch nur ausnahmsweise(!!!)- die Mühe gemacht,
Deine .conf-Datei entsprechend umzugestalten (nicht getestet und natürlich
alles ohne Gewährleistung!):

Code:

ServerType          standalone
SocketBindTight     on
DefaultServer       off

DeferWelcome        off
MultilineRFC2228    on

MaxInstances 30
MaxClientsPerHost 3
MaxClientsPerUser 3
MaxHostsPerUser 1

UseReverseDNS off
IdentLookups off

# Some logging formats
LogFormat default "%h %l %u %t \"%r\" %s %b"
LogFormat auth "%v [%P] %h %t \"%r\" %s"
LogFormat write "%h %l %u %t \"%r\" %s %b"

<Global>

    # Set the user and group that the server normally runs at.
    User    nobody
    Group   nogroup

    RequireValidShell    off
   
    TimeoutNoTransfer   600
    TimeoutStalled      600
    TimeoutIdle         1200
   
    DisplayLogin        welcome.msg
    DisplayFirstChdir   .message
    DenyFilter          \*.*/
    ListOptions         "-l"
    ShowSymlinks        on

    # Normally, we want files to be overwriteable.
    AllowOverwrite          on
    AllowRetrieveRestart    on
    AllowStoreRestart       on

    # Umask 022 is a good standard umask to prevent new files and dirs
    # (second parm) from being group and world writable.
    Umask   027  027
   
   
    # Log file/dir access
    ExtendedLog /var/log/proftpd/proftpd.access_log WRITE,READ write
    # Record all logins
    ExtendedLog /var/log/proftpd/proftpd.auth_log AUTH auth
    # Paranoia logging level....
    ExtendedLog /var/log/proftpd/proftpd.paranoid_log ALL default
    # Normale Log-Datei anstatt Syslog
    ServerLog /var/log/proftpd/proftpd.log
   
    DefaultRoot /home/ftpdaten

    # Login-Berechtigungen setzen
    <Limit LOGIN>
        DenyGroup !ftpuser
    </Limit>
   
    <Directory /home/ftpdaten>
        HideNoAccess on
        <Limit WRITE>
            DenyAll
        </Limit>
    </Directory>
   
    # Verzeichnis /home/ftpdaten/upload und Unterverzeichnisse
    <Directory /home/ftpdaten/upload>
        # Gruppe ftpuser Schreib-Zugriff geben
        # (ohne Loesch-Rechte)
        <Limit MKD STOR STOU>
            AllowGroup ftpuser
        </Limit>
    </Directory>
</Global>

# --------------------------------------------
# Standard-Server
# --------------------------------------------

ServerName      "Debian"
DefaultAddress  192.168.2.3
Port            621

# TLS
<IfModule mod_tls.c>
    TLSEngine on
    TLSProtocol TLSv1
    TLSLog /var/log/proftpd/proftpd_tls.log
    TLSRequired on
    TLSVerifyClient off
    TLSRSACertificateFile /etc/ftpcert/ftphost.cert
    TLSRSACertificateKeyFile /etc/ftpcert/ftphost.key
</IfModule>


# --------------------------------------------
# Lokaler Server
# --------------------------------------------

<VirtualHost 192.168.2.4>
    ServerName "Debian-Local"
    Port 21
   
    # Log file/dir access
    ExtendedLog /var/log/proftpd/local-proftpd.access_log WRITE,READ write
    # Record all logins
    ExtendedLog /var/log/proftpd/local-proftpd.auth_log AUTH auth
    # Record all paranoid...
    ExtendedLog /var/log/proftpd/local-proftpd.paranoid_log ALL default
    # Normale Log-Datei anstatt Syslog
    ServerLog /var/log/proftpd/local-proftpd.log

    DefaultRoot /home/backuplw

    <Limit LOGIN>
        DenyGroup !imageftp
    </Limit>
</VirtualHost>

Ich hoffe, daß das alles so funktioniert...
Zum Testen schaltest Du vielleicht zuerst einmal TLS aus ("TLSEngine off").
Wenn das mit TLS so nicht funktionieren sollte, dann überprüfe noch einmal
Deine Zertifikate und die Zugriffsrechte darauf.

Gruß
  VolGas

Hi,

Deine .conf schein soweit in Ordnung zu sein.
Aber was mich etwas irritiert, ist das Ausrufezeichen vor "ftpuser".

Ich würde empfehlen, daß Du einmal nachsiehst, ob Du wirklich im richtigen Verzeichnis
gelandet bist, denn wenn Du bei Deiner Konfiguration nicht in der Gruppe "ftpuser"
bist, gilt für Dich auch kein "DefaultRoot ~" - und Du landest sonst wo.

Entferne einfach das "!ftpuser" nach "DefaultRoot ~" - das macht IMHO
dort sowieso überhaupt keinen Sinn, da Du ja mit dem nachfolgenden "Limit"-Block
schon alle User dieser Gruppe aussperrst.
"DefaultRoot ~" gilt dann -ganz so wie es sein soll- für alle (restlichen) User.

Ich vermute einmal, daß Du eigentlich genau das Gegenteil wolltest:
es dürfen nur die User dieser Gruppe ins System. Dann entferne einfach das Ausrufezeichen...

mfg.
  VolGas

Du machst es Dir aber ziemlich leicht, aber wenn Du schon so weit gekommen
bist, ist es auch fast schon geschafft. Du benötigst nur noch eine entsprechend
angepasste Konfigurationsdatei "/etc/proftpd.conf" (Beispiel: ->hier)

Ich empfehle Dir, den ProFTPD als "Standalone" zu nutzen, nicht via (x)inetd.
Dann brauchst Du evtl. noch ein Script, das beim Hochfahren des Systems den
ProFTPD gleich mit startet. Beispiele findest Du ->hier

Wer sich wie und wo einloggen darf, wird bei der Standardinstallation aus dem
Linux-System (Systemuser) geholt.

Ansonsten gilt (wie für alle anderen auch):

 :RTFM  :FAQ:

Einen weiteren Tipp noch: in der proftpd.conf nie "RequireValidShell no" vergessen...

Viel Erfolg!

mfg.
  VolGas

Rücke mal n' Meter beiseite - du sitzt auf dem Schlauch!
Dann: Gehirn einschalten.
Anschließend: Siehe oben!

So: ich kann und ich will nun nicht mehr!

 :RTFM   :FAQ:

mfg.
  VolGas

Meine Güte - Du hättest genauer sagen sollen, was Du möchtest!

Alles zurück!
User & Group so belassen, wie es ursprünglich war.
"RequireValidShell no" hinzufügen.

Ohne mySQL würde der ProFTPD die Userdaten aus dem System nehmen.

Mit mySQL -oh Wunder!- holt er diese aus einer SQL-Tabelle.
Dort trägst Du die beiden User mit Username, Passwort und Homedir ein.
In der .conf werden niemals User, Passworte, etc. eingetragen!

ProFTPD sperrt automatisch einen User -egal ob Systemuser oder virtuellen User aus mySQL!-
durch die Direktive "DefaultRoot ~" in sein Homedir-Verzeichnis ein.

Eigentlich hättest Du alle Infos ganz einfach auch auf Stonki's Website finden können...!

mfg.
  VolGas

Wenn Du keine Websites oder sonstiges auf dieser Maschine per FTP pflegen mußt,
dann setze im System für die beiden User die entsprechenden Home-Dirs und
lösche in der .conf einfach alles ab einschließlich "SQLAuthTypes" und füge noch
"RequireValidShell no" hinzu - das hatte noch gefehlt!
Den Quota-Kram kannst Du Dir bestimmt verkneifen...

Server neu starten - und gut!

mfg.
  VolGas

So kommen wir nicht weiter.
Ein bischen mußt Du schon selbst tun!
Und warum hast Du nicht ausprobiert, was ich Dir empfohlen habe?

Ob die FTP-User Shell-Zugriff haben oder nicht, ist für den Betrieb des FTP-Servers nicht interessant.

Es tut mir leid, daß ich das so schreiben muß:
Man sollte man zumindest die absolut notwendigsten Grundkenntnisse von
einem Linux-System haben, bevor man anfängt, dort etwas ändern zu wollen
und darf auch nicht davor zurückschrecken, selbst viel lernen und probieren zu müssen.
Wenn Du dazu nicht bereit bist, dann solltest Du Dir vielleicht eine andere Beschäftigung suchen.
Du kannst nicht einfach in ein Forum kommen und sagen: Ich hab' keine Ahnung, macht ihr mal...

Falls Du aber doch etwas lernen möchtest, kann ich Dir z.B. das Standardwerk, den "Kofler"
wärmstens empfehlen, es gibt aber auch sehr viel weiterführende Literatur im Internet...

Das VHCS kenne ich nicht, damit hatte ich noch nie etwas zu tun - und werde es wohl auch nie.
Am besten fragst Du bei den Verfassern des VHCS oder einer entsprechenden Community nach...

Dies ist ein ProFTPD-Forum: wenn Du Fragen dazu hast, dann wird Dir hier bestimmt gerne
weitergeholfen, aber Fragen im Zusammenhang mit anderen Systemen sind Off-Topic und damit
fehl am Platz.
Sorry...

mfg.
  VolGas

Deine .conf ist ein bischen "unsauber", scheint soweit aber in Ordnung zu sein.
Den Quota-Teil habe ich mir allerdings nicht näher angesehen -
ich bin nicht masochistisch veranlagt und zum Thema Login ist dies auch nicht relevant.

Also erstes kontrolliere einmal, ob "mod_sql_mysql" in Dein ProFTPD eingebaut ist,
z.B. so (ggf. den entsprechenden Pfad zufügen): proftpd -l

Den allerersten Tipp, den ich Dir geben kann: setzte "SQLAuthTypes" zunächst einmal
auf "Plaintext" und trage die Passworte in der mySQL-Tabelle im Klartext ein.
Damit schalten wir eine mögliche Fehlerquelle aus. Wenn später alles funktioniert,
kannst Du wieder auf verschlüsselte Passworte umschalten.

Zweiter Tipp: versuche es zunächst auch nur mit: "SQLAuthenticate users*"

Probiere alles zuerst einmal aus, dann sehen wir ggf. weiter.

Falls dies bis dahinnoch nicht zum Erfolg weitergeholfen hat:
1.) Gehe ich Recht in der Annahme, daß Du die FTP-Accounts zusammen mit einem Webserver nutzen möchtest?
Dann könnte man sich einiges (er)sparen und zugleich auch mögliche Inkonsistenzen vermeiden...
2.) Steht Dein Server hinter einer Firewall bzw. hinter einem Router?

mfg.
  VolGas

Hinter Crypt kann ein MD5-Algorithmus stecken, standardmäßig ist es aber DES.

Ich weiß nicht so genau, warum Dich das offene Passwort in der mySQL-Tabelle stört,
aber wenn Du "SQLAuthType Crypt" unbedingt nutzen möchtest, dann kannst Du
die Passworte in der SQL-Datenbank mit

Code:

UPDATE `Users` SET `Passwort`=ENCRYPT(`Passwort`)

umwandeln lassen...

Du mußt Deine Passworte dem zugrunde liegenden System anpassen, nicht umgekehrt.

mfg.
  VolGas

Wenn Du mit z.B. mit phpMyAdmin Deine Tabelle "user" ansiehst,
ist dann das Feld "count" als Logincounter erkennbar?

Wenn ja, dann ist ein Fehler in MyFTPAdmin.

In der .conf würde ich "User" & "Group" nicht auskommentieren und
laut Doku sind bei "PassivePorts" nur zwei Argumente erlaubt (min & max).
Sonst sieht Deine .conf recht gut und fehlerfrei aus.

mfg.
  VolGas

DefaultRoot ~

 :RTFM  :FAQ:

mfg.
  VolGas

Hallo,

der "Bind"-Befehl hat schon sehr viel Verwirrung gestiftet und wird deswegen
wohl demnächst auch verschwinden. "SocketBindTight on" ist goldrichtig,
"DefaultAddress xxx.xxx.xxx.xxx" für den "Hauptserver" und dann ggf. nur noch
"<Virtualhost xxx.xxx.xxx.xxx>" - alles ganz ohne Bind.

Bei uns funktioniert dies so einwandfrei, aber ob das auch über mehrere Netzwerkkarten
hinweg funktioniert, weiß ich leider nicht - solch eine Anwendung hatten wir bislang nicht.

Noch 'n zusätzlicher Tipp: mit einem "<Global>...</Global>"-Block
das Verhalten für alle (virtuelle) Server auf einmal definieren...

mfg.
  VolGas