Hallo,

mit dem ProFTPD werden noch einige weitere Programme installiert.
Unter anderem auch "ftptop" - das es...

mfg.
  VolGas

Hi,

per Default ist es "root" ausdrücklich verboten, sich per FTP einzuloggen.
Das ist prinzipiell zwar möglich, aber ein viel zu großes Sicherheitsrisiko.

"RequireValidShell off" ist richtig, aber Du mußt auch dem ProFTPD mitteilen,
daß es seine Konfigurationsdatei neu einlesen soll. Entweder Du sendest ein
entsprechendes Signal oder Du startest den ProFTPD neu.

Falls es dann immer noch nicht klappen sollte, so poste Deine proftpd.conf
hier. Dann sehen wir weiter.

mfg.
  VolGas

Bitteschön.

So verhalten sich aber eigentlich alle gängigen HTTP-Browser...
(zumindest die, die ich kenne!)

mfg.
  VolGas

[ServerType inetd:]

Hi,

so eine Konfiguration wie Deine habe ich noch nicht gesehen und ich mußte zuerst
einmal nachsehen, was die einzelnen Direktiven eigentlich für eine Bedeutung haben.

Aber eines nach dem anderen:

• ServerType inetd: ich würde den Server nicht unter (x)inetd laufen lassen -
  es gibt Gründe, die man hier auf Stonki's Site nachlesen kann und auf die ich nicht
  noch einmal eingehen möchte. Besser: "ServerType standalone"
• MaxInstances: bei Servertype "inetd" wirkungslos, darum kümmert sich schon
  der Internet-Daemon. Wenn Du aber den ProFTPD wirklich alleine laufen lässt, ist
  diese Direktive ok.
• AuthPAMConfig ftp: wenn man den ProFTPD in der Standardumgebung belässt, funktioniert
  dieser schon ganz perfekt mit dieser Infrastruktur. Diese Direktive erfordert einen spziell
  eingerichteten PAM-Dienst, der von der normalen Konfiguration Abweichungen zuläßt.
  Wenn Du die Direktive komplett entfernst, verhält sich Dein ProFTPD wieder ganz normal.
• AuthUserFile: ein ganz anderes Authentifizierungsmodul, das es erlaubt,
  alternative passwd-Dateien zu benutzen. "/etc/passwd" ist schon die Standard-Datei des
  Systems, auch diese Zeile kann (und sollte) komplett entfernt werden
• User & Group: ruhig aktivieren, das erhöht die Sicherheit.
  Unter (x)inetd witzlos.
• DefaultRoot: so wie Du das einsetzt, hast Du Dir das bestimmt nicht gedacht:
  die Anweisung bezieht sich nur auf die User der Gruppe "psacln" - alle anderen bleiben
  verschont und in "Freiheit" und können damit überall hin - kein "DefaultRoot"...
  Ich bin mir so ziemlich sicher, daß Du eigentlich das möchtest:
  

  DefaultRoot ~
  <Limit LOGIN>
     DenyGroup !psacln
  </Limit>

  Damit kommt keiner rein, der nicht dieser Gruppe angehört und die, die es tun,
  werden sogleich sicherheitshalber auf Ihr Homeverzeichnis reduziert. (chroot)
• füge Deiner proftpd.conf noch folgendes hinzu: "RequireValidShell off", "UseReverseDNS off"
  und "IdentLookups off"

Mit Deinen Direktiven hast Du es eigentlich ganz genau und wohl definiert hinbekommen
wollen, dabei aber leider den Vogel abgeschossen. Durch die Korrekturen hast Du wieder
einen Standardserver, der sich erwartungsgemäß verhalten sollte.

Viel Spaß damit.

mfg.
  VolGas

Hiho!

Der FireFox ist kein FTP-Client im "klassischen" Stil und verhält sich wie bei einer Website.
Bei einen Authentifikationsfehler fragt er einfach nach Benutzername & Passwort.
Kannst Du mit Deinem Firefox z.B. Dateien hochladen oder Verzeichnisse erstellen?
Ich kann's nicht - es ist alles nur read-only.

Sorry: nimm einen richtigen FTP-Client.

mfg.
  VolGas

So ähnlich hatte ich mir das schon gedacht (letzter Absatz).

Wenn der FTP-Server ein lokales Netz hat, aber nach extern eine feste IP, dann
ist es ja kein Problem mit "MasqueradeAddress" dem ProFPTD die IP mitzuteilen.
Achtung: bei einer Firewall dazwischen mußt Du eine "Bresche" für die sog.
High-Ports schlagen und ProFTPD diese via "PassivePorts xxx yyy" mitteilen.

Die Konfiguration ohne (x)inetd ist dann auch einfacher und nur die proftpd.conf ist
anzupassen. Mein Tipp: fasse alle möglichen Direktiven zusammen in einen
<Global>...</Global>-Block (Kontext beachten!) und definiere dann für extern
den Rest zusammen in einem "VirtualHost".

Deine proftpd.conf hier einmal umgeschrieben und erweitert:

   ServerType  standalone
   PidFile     /var/run/proftpd.pid
   
   MaxInstances        30
   Port                21
   SocketBindTight     on
   DefaultServer       on
   
   UseReverseDNS       off
   MultilineRFC2228    on
   
   <Global>
      User                ftp
      Group               ftp
      
      IdentLookups        off
      
      AuthOrder           mod_sql.c
      
      SQLConnectInfo      ********************
      SQLUserInfo         ftp username password NULL NULL homedir NULL
      SQLAuthTypes        Plaintext 
      SQLAuthenticate     users
      SQLMinUserGID       100 
      SQLMinUserUID       500 
      SQLDefaultGID       65534 
      SQLDefaultUID       65534 
      SQLNegativeCache    on
      
      RequireValidShell   off
      
      DefaultRoot         ~
      Umask               022
      
      DenyFilter          \*.*/
      ListOptions         "-A +R"
      UseGlobbing         off
      TimesGMT            on
      
      AllowOverwrite      on
      
      TransferLog         /var/log/ftp_access
   </Global>
   
   
   # --------------------------------------------
   # Standard-Server (lokal)
   # --------------------------------------------
   
   DefaultAddress      192.168.xxx.yyy
   ServerName          "ABC"
   ServerAdmin         hostmaster@abc.de
   
   
   # --------------------------------------------
   # Virtueller Host (extern)
   # --------------------------------------------
   
   <VirtualHost 192.168.xxx.zzz>
      ServerName          "ABC"
      ServerAdmin         hostmaster@abc.de
      
      MasqueradeAddress   abc.de
   </VirtualHost>

Das Ganze natürlich ohne Gewähr!

Ich denke, damit kommst Du klar - wenn nicht...  

Viel Erfolg!

mfg.
  VolGas

Ich bin auf Deine letzten Fragen nicht eingegangen, da ich mein letztes Posting
"offline" verfasst habe und erst danach Dein Posting gesehen habe.

Natürlich kann man -sogar recht bequem- den ProFTPD für unterschiedliche IP's
und/oder Ports konfigurieren. Alles in der proftpd.con und mit einer Serverinstanz.
Aber bei einem Server sind dynamsche IP's eine recht kniffelige Sache -
und erst recht, wenn die IP mit in das Kommunikationsprotokoll eingebunden
werden muß.

Dabei bringt es überhaupt gar nichts, wenn Du dem Server netzintern eine weitere,
feste IP zuweist: die externe IP, unter der der ProFTPD erreicht werden soll, ist
maßgeblich, da diese - wie schon erwähnt- in das FTP-Protokoll "eingebaut" wird.
Das ist bei einem MTA nicht der Fall, für den gelten ganz andere Vorraussetzungen
und "Gesetze".

Man hätte auch eine Lösung ohne (x)inetd finden können, das wäre einfacher und
sogar mit weniger Aufwand machbar gewesen. Aber was, wenn die IP sich ändert?
Da bleibt nur, den Server neu zu starten - oder eben gleich einen TCP-Wrapper
bzw. den Internetdaemon zu benutzen. Das ist die zuverlässigere Methode.

Meine Meinung zu Servern im allgemeinen, ganz unabhängig von Deiner Person:
Ein Server ist ein "statisches Gebilde" und benötigt ein entsprechendes Umfeld
und eine feste IP. Er gehört ganz bestimmt nicht hinter einen heimischen
DSL-Anschluß oder gar auf eine Maschine, vor der vielleicht noch jemand sitzt.

Deine Lösung mit zwei Netzwerkkarten könnte ich mir gut in einer Firma vorstellen,
die einen einzelnen, dedizierten(!) Rechner als Internet-Gateway mit eingebauter
Firewallfunktionalität und evtl. einigen, nach außen unkritschen, Netzwerkdiensten
nutzt.

mfg.
  VolGas

Sorry, meine Antwort hat nun etwas gedauert, aber Dein Problem ist nicht ganz
trivial und mit einer kurzen Antwort zu erledigen. So hatte ich auch Zeit zum
nachdenken.

Für dynamische IP's gibt es eine (Teil-)Lösung, siehe ->MasqueradeAddress

Wie dort schon beschrieben, läßt Du am besten Deinen ProFTPD nicht mehr als
"standalone", sondern unter dem inetd (besser: xinetd) laufen. Jeder einiger-
maßen aktuelle Router bietet heutzutage die Möglichkeit, sich automatisch bei
z.B. dyndns.org für eine Subdomain einzutragen - das solltest Du nutzen.

Da durch "MasqueradeAddress" aber über das lokale Netzwerk keine
passiven Transfers mehr funktionieren, muß man die Direktive "regulieren".
Dies kann man mit Klassifizierungen erreichen. (->mini-HOWTO Classes)

Vorausgesetzt, Du hast ->mod_ifsession mit in den ProFTP compiliert,
könntest Du z.B. folgendes versuchen:

  <Class external>
    From !192.168.0.0/16
  </Class>

  <IfClass external>
    MasqueradeAddress xyz.dyndns.org
  </IfClass>

Rein theoretisch könnte das funktionieren - sofern der Betrieb unter (x)inetd
dies nicht vielleicht noch verhindert. Ich drücke Dir die Daumen und bitte um
Rückmeldung...

mfg.
  VolGas

Siehe Google.

Erster Eintrag ist Site des Herstellers mit kompletter Beschreibung.

mfg.
  VolGas

Evtl. ist ja der "xinetd" etwas für Dich - damit kann man das -glaube ich- machen.
Du müßstest das dem ProFTPD nur mit "ServerType inetd" in der proftpd.conf mitteilen.

mfg.
  VolGas

Den proftpd braucht man i.d.R. nicht zwei mal zu starten, man kann normalerweise alles
in einer proftpd.conf definieren.

Nun muß ich eine Frage stellen, vor der ich schon fast Angst habe: ist die Server-Maschine
hinter einem Router mit NAT - sprich: hat die Maschine eine dynamische oder eine feste IP
vom Internet aus?

Bei einer dynamischen IP hast Du echt Schwierigkeiten: nicht wegen dem proftpd, sondern
generell systembedingt. Da hätten wir dann die Fehlkonfiguration.

Was mir an Deiner .conf aufgefallen ist: wenn Du mit "SQLUserInfo" die beiden Felder "uid"
und "gid" definierst, verbietet sich eigentlich der Einsatz von "SQLDefaultUID" und "SQLDefaultGID".
Bei Datenfeldern, die Du nicht brauchst oder die immer wieder gleich sind, kannst Du bei
"SQLUserInfo" dann auch jeweils "NULL" angeben - so z.B. bei "shell".

mfg.
  VolGas

Sorry, das war das falsche Paket - wir brauchen natürlich wieder ein develop-Paket.
Und das müßte "libssl-dev" sein.

Wenn das mit dem Compilieren nicht klappen sollte, dann ufert das hier leider zu
weit aus. Ich drücke Dir mal beide Daumen, daß es nun nach der letzten Installation
klappt.

mfg.
  VolGas

[@ Küspert:]

@ Küspert:

Prinzipiell gesehen hast Du zuerst einmal recht - aber diese Diskussion hatten wir
schon einmal angefangen und ich möchte mich nicht weiter darauf einlassen als dieses:

die letzten beiden Zeilen sortieren die Dinge genau da ein, wo es sinnvoll ist und wo es
sein sollte. Nix kreuz und quer durch's System und sehr gut zu warten.
Den armen Mann jetzt durch den ganzen "Rotz" von wegen Paket- und Versionsverwaltung
hindurchjagen zu wollen ist Wahnsinn. Ich kann das selbst nicht und will es auch gar nicht
können. Wenn ich jemandem weiterhelfe, dann so, wie ich es kann und ich weiß, daß es
funktioniert.

Du siehst ja selbst, wie er -verständlicherweise- reagiert.
Und daß man als "root" auf Glatteis läuft sollte sich mittlerweile herumgesprochen haben.

@ hostage:

Installiere noch "openssl" mit "apt-get" - das hat vermutlich noch gefehlt.

mfg.
  VolGas

Hmm - jetzt hat uns die Kursiv-Schrift einen Streich gespielt.
Das sind keine zwei Slashes, sondern zwei kleine "L".

Ich weiß wirklich nicht, welches develop-Paket Du brauchst - bei uns sind alle
Server selbst compiliert, da mir die Debian-Pakete zu alt waren und auch nicht
alles so hatten, wie wir das wollen bzw. brauchten.

Probiere es nun noch einmal mit der Anweisung oben (am besten copy & paste).

mfg.
  VolGas

Ich glaube, da haben wir das Problem: ich meine, irgendwo hier im Forum einmal
gelesen zu haben, daß mit zwei Netzwerkkarten ein Problem auftreten kann.

Füge einmal Deiner proftpd.conf "Defaultserver on" hinzu.
Zusätzlich kann: "UseReverseDNS off" und "IdentLookups off" nur positiv sein.

Ich nehme einmal an, daß in der proftpd.conf kein Binding auf eine spezielle IP (und damit
an die Netzwerkkarte) vorgenommen wurde. Vielleicht ist auch das die Lösung - das solltest
Du unbedingt probieren.

mfg.
  VolGas