• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

vsftpd mit ftp und ftps

Chaoshh

Member
hi allerseits,
ich arbeite gerade an einer ftp Lösung und komme nicht weiter. Ich möchte, dass mein vsftpd sowohl ftp wie auch ftps bedient. Angeblich soll das mit xinetd möglich sein, doch bei mir klappt es nicht.

Ich habe sogar eine Anleitung gefunden, die ist aber offensichtlich fehlerbehaftet.
http://www.lcube-webhosting.de/forum/gleichzeitiges-bereitstellen-von-ftp-und-ftps-t5.html

Denn es wird 2x die Datei /etc/xinetd.d/ftp bearbeitet, was natürlich so nicht stimmen kann. Es müsste "ftp" und "ftps" sein, so habe ich auch eine 2-te datei erstellt. Aber auch damit funktioniert das nicht, nur ftps klappt, ftp hingegen nicht. Mit der Meldung "530 Non-anonymous sessions must use encryption."

/etc/vsftpd.conf
Code:
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
xferlog_enable=YES
xferlog_file=/var/log/xferlog
xferlog_std_format=YES
ascii_upload_enable=YES
ascii_download_enable=YES
ls_recurse_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
userlist_enable=YES
userlist_file=/etc/chrootUsers
userlist_deny=NO
pam_service_name=vsftpd

und /etc/vsftpsd.conf
Code:
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
xferlog_enable=YES
xferlog_file=/var/log/xferlog
xferlog_std_format=YES
ascii_upload_enable=YES
ascii_download_enable=YES
ls_recurse_enable=YES
connect_from_port_20=NO
chroot_local_user=YES
userlist_enable=YES
userlist_file=/etc/chrootUsers
userlist_deny=NO
pam_service_name=vsftpd
listen=YES
ssl_enable=YES
allow_anon_ssl=NO
rsa_cert_file=/etc/vsftpd/vsftpd.pem
force_local_data_ssl=YES
force_local_logins_ssl=YES
pasv_enable=YES
pasv_promiscuous=YES

Kennt jemand vielleicht noch eine Lösung oder kann einen Fehler entdecken, welcher für meine Probleme ausschlaggebend ist?
 

TomcatMJ

Guru
Deine Konfiguration mit Verschlüsselung läuft als Standalone vsftpd und nicht per xinetd wenn die Zeile
Code:
listen=YES
da korrekt ist
Da du sagst daß diese Version zu laufen scheint solltest du vielleicht einfach das Startscript in /etc/iniit.d kopieren, bezüglich der aufzurufenden Konfiguratiosndatei anpassen, entsprechend für die jeweiligen Runlevel verlinken und deine unverschlüsselte Variante dann auch als Standalone Server laufen lassen statt per xinetd zu starten.
Für weitere Problemanalysen wären ansonsten die modifizierten/selbst angelegten Dateien für xinetd interessant um zu sehen ob sich da vielleicht ein Fehler eingeschlichen hat.

Bis denne,
Tom
 
OP
C

Chaoshh

Member
Moin TomcatMJ,

hier die Ausgaben der Dateien "ftp" und "ftps" im Verzeichnis /etc/xinetd.d/
Code:
service ftp
{
        disable=no
        socket_type=stream
        wait=no
        user=root
        server=/usr/sbin/vsftpd
        nice=10
        server_args=/etc/vsftpd.conf
}
Code:
service ftps
{
        disable=no
        socket_type=stream
        wait=no
        user=root
        server=/usr/sbin/vsftpd
        nice=10
        server_args=/etc/vsftpsd.conf
}
 
OP
C

Chaoshh

Member
In der /etc/services steht:
Code:
ftp-data        20/tcp
ftp             21/tcp
ftps-data       989/tcp
ftps            990/tcp
tftp            69/udp
sftp            115/tcp
ftps-data       989/tcp                         # FTP over SSL (data)
ftps            990/tcp

Was sollte in der xinetd.conf stehen?
Ich habe folgendes darin:
Code:
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/

defaults
{

# Please note that you need a log_type line to be able to use log_on_success
# and log_on_failure. The default is the following :
# log_type = SYSLOG daemon info

}

includedir /etc/xinetd.d

Ist halt der originalzustand. Sollte ich noch etwas verändern? Der genannte Artikel ist genau an dieser Stelle unverständlich für mich.
 

TomcatMJ

Guru
Hi!
Also deine /etc/services und deine xinetd.conf sehen soweit korrekt aus. Check mal ob dein vsftpd im Runleveleditor aktiviert ist und ggf. sollte der dort deaktiviert werden wenn du beide Varianten übr xinetd starten lassen willst, was allerdings auch vom erwarteten Nutzungsausmaß abhängt,denn über xinetd würde ich den nur starten wenn weniger als 15 Clients pro Stunde als Nutzungsvolumen erwartet wird,sonst besser als Standalone-Server,d.h. über das eigene Startscript statt über xinetd starten.

Für die Nutzung mit xinetd sollte dann in beiden(!) vsftpd-Konfigurationen die Direktive
Code:
listen=NO
gesetzt sein,denn ein "YES" wäre für eine Standaloneserverkonfiguration zuständig bei dem der Server selbst lauscht ob eine Anfrage auf den jeweiligen Port gekommen ist (was mit "NO" eben vom xinetd übernommen wird der dann auch den Server selbst startet).

Btw. noch eine ganzt platte Frage: Ist im Runleveleditor dein xinetd überhaupt aktiviert? Ich weiss,mag sich blöd anhören diese Frage, aber genau solche Kleinigkeiten sind es oft die einen unnütz stundenlang suchen lassen wenn man sie mal übersehen hat ;)

Bis denne,
Tom
 
OP
C

Chaoshh

Member
In beiden configs (vsftpd.conf,vsftpsd.conf) steht jetzt "Listen" auf "NO". Der Dienst xinetd ist bereits als startlink eingetragen allerdings habe ich ihn sowieso manuell gestartet -> /etc/init.d/xinetd start <-

Mein filezilla sagt:
Code:
Status:	Verbindung hergestellt, warte auf Willkommensnachricht...
Antwort:	220 (vsFTPd 2.0.7)
Befehl:	USER snoopy5
Antwort:	530 Non-anonymous sessions must use encryption.
Fehler:	Herstellen der Verbindung zum Server fehlgeschlagen
Status:	Nächsten Versuch abwarten...

Interessant: ich habe jetzt festgestellt, daß ich mich nur über den Port 21 per ftps verbinde. Die Ports 989 und 990 sind zu:
Code:
Status:	Verbinde mit 12.345.67.890:990...
Status:	Verbindungsversuch fehlgeschlagen mit "ECONNREFUSED - Connection refused by server".
Fehler:	Herstellen der Verbindung zum Server fehlgeschlagen
Status:	Nächsten Versuch abwarten...
Status:	Verbinde mit 12.345.67.890:989...
Status:	Verbindungsversuch fehlgeschlagen mit "ECONNREFUSED - Connection refused by server".

Ich weiß, geht sowieso nur über den einen, ich habe aber beide versucht.
 

TomcatMJ

Guru
Ist dein User snoopy5 defintiv ein User bei dem der ftp-Server nicht diesen User in eine chroot-Umgebung sperren soll?
Auszug aus der default vsftpd.conf dazu:
Code:
..
chroot_local_user=YES
#
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
#
#chroot_list_enable=YES
#
# (default follows)
#
#chroot_list_file=/etc/vsftpd.chroot_list
..
Wenn dieser User nicht chrooted werden soll (sprich: wenn er in der Liste der nicht zu chrootenden User steht) hat er dann Zugriff auf das Homeverzeichnis des Users unter dessen Kennung dein vsftpd läuft?
Oder steht er in der in deiner Konfiguration angegebenen Liste drin und darf sich daher gar nicht einloggen?
Dazu ein Auszug aus der Linupedia:
http://www.linupedia.org/opensuse/Vsftpd schrieb:
...

userlist_enable

Wenn diese Option genutzt wird lädt vsftpd eine Benutzerliste aus der unter userlist_file vermerkten Datei. Jeder Benutzername aus dieser Datei wird als unzulässig abgewiesen. Dies kann nützlich sein um Klartextpasswortübermittlungen über das Netz zu vermeiden.

userlist_file

Hier wird das Name der Datei angegeben, die geladen werden soll wenn man userlist_enable aktiviert hat. Per Default wird /etc/vsftpd.user_list verwendet.
...
Sieht mir nämlich irgendwie noch nichtmal nach einem Serverproblem sondern eher nach einem Benutzerkonfigurationsproblem nun aus.....

Bis denne,
Tom
 
OP
C

Chaoshh

Member
Bin mir nicht sicher, ob ich dich richtig verstanden habe.

Jeder Benutzer soll in seinem eigenen Verzeichnis verbleiben. Es gibt eine Listendatei und auch dieser Benuzter der mit ftps reinkommen soll ist darin vermerkt.

Was kann denn dafür verantwortlich sein, daß die Ports nicht funktionieren? Die iptables Tabellen sind leer...
 

TomcatMJ

Guru
Also mal zur Analyse dessen was du da konfiguriert hast:
1.: Du hast eingestellt daß alle User chrooted werden,also alle User ihr Heimatverzeichnis als FTP-Rootverzeichnis vorgesetzt bekommen über das sie keine ebene höher hinaus kommen.

2.: Du hast keine chrootuserliste eingerichtet mit der einzelne User aus diesem Vorgang ausgenommen wären die dann das Heimatverzeichnis des FTP-Users unter dessen Kennung der Server läuft als FTP-Root vorgesetzt bekämen statt ihrem eigenen.

3.Du hast eine Userliste angelegt deren dort eingetragene User auf jeden Fall vom FTP-Server abgewimmelt werden. (Letzteres vermute ich mal als den Irrtum der zur Fehlermeldung führt)

Die entlich funktionieren nur wird dem User eben der Zugang verwehrt weswegen die Verbindung abgebrochen wird. Wäre er in einer chrootuserliste drin in der die Ausnahmen vom chroot drinstünden so würde die Verbindung vermutlich ebenso abgewürgt werden wenn kein Heimatverzeichnis des FTP-Users unter dem vsftpd läuft für diesen User zugänglich ist.

Vermutlich liegt also nur ein vorheriges Missverständnis betreffs dem von mir aus der Linupüedia zitieren Parametern vor und dein User ist in der Liste drin ;)

Bis denne,
Tom
 
OP
C

Chaoshh

Member
Hi, hier meine vsftpd.conf und vsftpsd.conf nochmal aktuell.

vsftpd.conf
Code:
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
xferlog_enable=YES
xferlog_file=/var/log/xferlog
xferlog_std_format=YES
ascii_upload_enable=YES
ascii_download_enable=YES
ls_recurse_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
userlist_enable=YES
userlist_file=/etc/vsftp.chruserslist
userlist_deny=NO
pam_service_name=vsftpd
listen=NO

vsftpsd.conf
Code:
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
xferlog_enable=YES
xferlog_file=/var/log/xferlog
xferlog_std_format=YES
ascii_upload_enable=YES
ascii_download_enable=YES
ls_recurse_enable=YES
connect_from_port_20=NO
chroot_local_user=YES
userlist_enable=YES
userlist_file=/etc/vsftp.chruserslist
userlist_deny=NO
pam_service_name=vsftpd
listen=NO
ssl_enable=YES
allow_anon_ssl=NO
rsa_cert_file=/etc/vsftpd/vsftpd.pem
force_local_data_ssl=YES
force_local_logins_ssl=YES
pasv_enable=YES
pasv_promiscuous=YES

Eigentlich dachte ich, ich habe ich eine Liste angelegt, für User die auf ihre chroot Umgebung eingeschränkt werden müssen. Von der Logik her wäre das was du schreibst also nicht verkehrt. Normalerweise müsste doch /etc/ftpusers den Benutzern den Zugang verweigern.

Doch jetzt kommt es - wenn ich meinen Benutzer aus dieser Liste entferne, komme ich garnicht mehr rein. Weder mit ftps noch mit ftp, egal welche Ports. "530 permission denied" heißt es dann. Interessant - bei Port 21 heisst es immer "530 permission denied" und "530 Non-anonymous sessions must use encryption", hingegen bei Port 990 "ECONNREFUSED - Connection refused by server".
 

TomcatMJ

Guru
HM,scheint wohl doch etwas verwzickter zu sein als es beim groben Checken den Anschein hat. Ich werde wohl entweder im Laufe dieses Tages oder des morgigen Tages (also Freitag) mal nachbauen anhand eines Rechners (den ich eh noch fertigkonfigurieren muss) und bei der Gelegenheit auch direkt mal checken ob es da nicht doch möglich ist SSL und nicht-SLL verschlüsselt parallel zu fahren ohne 2 Server zugleich anwerfen zu müssen.
Wenn ich es richtig gesehen habe, dann hast du ja bei beiden den anonymen Zugang unterbunden und fährst da auch keine verschiedenen Defaultverzeichnisse für beide Varianten, sondern in beiden nur lokale Nutzer (echte Nutzer des Systems,keine virtuellen) die allesamt nur in in ihren jeweils eigenen chroot Verzeichnises in Form der in /etc/passwd hinterlegten Homeverzeichnisse Zugang haben sollen,sowohl verschlüsselt als auch unverschlüsselt,oder?
 
OP
C

Chaoshh

Member
Ja, sie sollen in ihren home Verzeichnissen bleiben.

Am seltsamsten finde ich, dass ich nur über Port 21 reinkomme, Port 990 klappt hingegen überhaupt nicht.
 
OP
C

Chaoshh

Member
Ich hab es. Die Beschreibung war auch was die Ports angeht fehlerhaft, sie trifft nur bei ftps implizit zu. Bei ftps explizit sind es die Ports 20/21. Dann bleibt also weiterhin das Problem, wieso normales FTP nicht klappt.
 

TomcatMJ

Guru
http://www.gtkdb.de/index_7_1017.html lief mir gerade zufäälig über den Weg und könnte durchaus hilfreich sein um das Problem, sofern es denn noch existiert, zu lösen.

Bis denne,
Tom
 
Oben