[Vsftp] Inloggen niet mogelijk

[ddkiller0900]

Ik probeer onder Centos 6.6 vsftp werkend te krijgen zodat personen toegang krijgen tot een map. Tevens moet deze map benaderbaar zijn via tftp. Momenteel is het niet mogelijk om via ftp een verbinding te maken.

Zodra ik probeer te verbinden met een gebruiker krijg ik de melding:

500 OOPS: cannot change directory:/hoofdmap/submap

Dit lijkt op een rechten probleem.
Volgens de documentatie dient de hoofdmap root als owner te hebben wat het geval is.

Wat ik op diverse fora las is dat in de configuratie van vsftpd pam_service_name=vsftpd gewijzigd moet worden naar pam_service_name=ftp. Echter lijkt me dit vreemd aangezien de service als vsftpd staat gedefinieerd onder /etc/pam.d. Wanneer ik deze wijziging toch doorvoer krijg ik volgende melding bij het inloggen:

530 Login incorrect.
Login failed.

Zelf dacht ik dat eventueel Selinux roet in het eten gooit.
Echter heb ik de mappen de juiste rechten gegeven en de configuratie van Selinux aangepast als volgt:

semanage fcontext -a -t public_content_rw_t "/hoofdmap(/.*)?"

getsebool -a | grep ftp

allow_ftpd_anon_write --> off
allow_ftpd_full_access --> on
allow_ftpd_use_cifs --> off
allow_ftpd_use_nfs --> off
ftp_home_dir --> on
ftpd_connect_db --> off
ftpd_use_fusefs --> off
ftpd_use_passive_mode --> off
httpd_enable_ftp_server --> off
tftp_anon_write --> on
tftp_use_cifs --> off
tftp_use_nfs --> off

ls -alZ /hoofdmap
drwx------. root root     unconfined_u:object_r:public_content_rw_t:s0 .
drwx------. root root     system_u:object_r:default_t:s0   ..
drwxrwx---. root sftponly unconfined_u:object_r:public_content_rw_t:s0 submap

Gebruiker:

De gebruikers hebben geen shell en daarnaast is de shell /bin/false toegevoegd aan /etc/shells

cat /etc/passwd | grep test
test:x:10010:10001::/hoofdmap/submap:/bin/false

groups test
test : sftponly

/etc/vsftpd/vsftpd.conf

anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=002
dirmessage_enable=YES
xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd.log
connect_from_port_20=YES
chroot_local_user=YES
listen=YES
pam_service_name=ftp
userlist_enable=NO
tcp_wrappers=YES
local_root=/hoofdmap
log_ftp_protocol=YES

Rechten:

drwx------.  3 root   root     4096 Jul 30 08:50 hoofdmap
drwxrwx---. 12 root sftponly 4096 Jul  7 09:20 submap

/etc/pam.d/vsftpd

cat /etc/pam.d/vsftpd

#%PAM-1.0
session    optional     pam_keyinit.so    force revoke
auth       required     pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed
#auth       required    pam_shells.so
auth       include      password-auth
account    include      password-auth
session    required     pam_loginuid.so
session    include      password-auth

Logging

/var/log/audit/audit.log

tail /var/log/audit/audit.log

type=USER_AUTH msg=audit(1438325466.856:12360): user pid=15445 uid=0 auid=0 ses=1869 subj=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="test" exe="/usr/sbin/vsftpd" hostname=server01.local addr=192.168.0.1 terminal=ftp res=failed'

/var/log/vsftpd.log

tail /var/log/vsftpd.log

Fri Jul 31 09:04:44 2015 [pid 15553] CONNECT: Client "192.168.0.10"
Fri Jul 31 09:04:44 2015 [pid 15553] FTP response: Client "192.168.0.10", "220 (vsFTPd 2.2.2)"
Fri Jul 31 09:04:45 2015 [pid 15553] FTP command: Client "192.168.0.10", "USER test"
Fri Jul 31 09:04:45 2015 [pid 15553] [test] FTP response: Client "192.168.0.10", "331 Please specify the password."
Fri Jul 31 09:04:47 2015 [pid 15553] [test] FTP command: Client "192.168.0.10", "PASS <password>"
Fri Jul 31 09:04:47 2015 [pid 15552] [test] FAIL LOGIN: Client "192.168.0.10"
Fri Jul 31 09:04:48 2015 [pid 15553] [test] FTP response: Client "192.168.0.10", "530 Login incorrect."
Fri Jul 31 09:04:48 2015 [pid 15553] FTP command: Client "192.168.0.10", "SYST"
Fri Jul 31 09:04:48 2015 [pid 15553] FTP response: Client "192.168.0.10", "530 Please login with USER and PASS."

Deze config lijkt wel te werken onder debian/ubuntu.

Heeft iemand tips?

[ Voor 21% gewijzigd door ddkiller0900 op 31-07-2015 09:18 . Reden: typos ]

[Hero of Time]

Weet je zeker dat de hoofdmap alleen voor root toegankelijk moet zijn? Ik denk dat daar het probleem ligt, zie namelijk ook de foutmelding. Je zal other op z'n minst execute rechten moeten geven zodat ze door de map heen kunnen. Je authenticatie was prima, als daar namelijk een probleem mee zou zijn, krijg je niet de chroot error.

[ddkiller0900]

Ik heb de hoofdmap en submappen al eens geconfigureerd zodat other lees en execute rechten had. Dit lost het probleem helaas niet op. Zelfs volledige rechten verhelpen het probleem niet.

Authenticatie lijkt inderdaad goed te gaan voor alle gebruikers.

Wat ik verder nog heb geprobeerd is het tijdelijk uitschakelen van Selinux. Echter als Selinux het probleem was dan zou inloggen moeten lukken zodra deze functionaltieit is uitgeschakeld en zou "ftp_home_dir on" het probleem moeten verhelpen zodra Selinux weer terug is ingeschakeld.

[Thralas]

En toch kun je een directory sowieso niet traversen als je geen executerechten hebt. Dat zou ik toch zodanig instellen, en dan heb je elders nog een probleem.

Misschien handig om SELinux even te disablen en jezelf een shell te geven als de probleemuser?

[ddkiller0900]

Thralas, de hoofdmap en submap hebben 775 rechten en toch is het niet mogelijk om toegang te krijgen tot deze mappen via ftp.

Zoals al eerder aangegeven helpt het helaas niet om SELinux te disablen.
De context die ik gebruik voor de mappen (public_content_rw_t) zou sowieso toegang moeten geven tot ftp, tftp etc.

[ Voor 0% gewijzigd door ddkiller0900 op 31-07-2015 14:24 . Reden: typo ]

[Hero of Time]

Ik neem even aan dat het een typo is, want 774 is other read/write, niet execute. Logsichere rechten zijn 755.

[ddkiller0900]

Hero of Time schreef op vrijdag 31 juli 2015 @ 13:33:
Ik neem even aan dat het een typo is, want 774 is other read/write, niet execute. Logsichere rechten zijn 755.

Was inderdaad een typo, heb mijn reactie gewijzigd.
Maar dus alsnog niet mogelijk om in te loggen.
De rechten op de mappen staan dus goed, de context staat ook goed (SELinux), is er nog iets anders wat ik over het hoofd zie?

[Hero of Time]

Check http://www.linuxquestions...ee-login-attempts-632999/ zodat je je logging op orde brengt. Hopelijk zie je dan wat er mis gaat bij 't aanmelden.

[ddkiller0900]

Hero of Time schreef op vrijdag 31 juli 2015 @ 16:07:
Check http://www.linuxquestions...ee-login-attempts-632999/ zodat je je logging op orde brengt. Hopelijk zie je dan wat er mis gaat bij 't aanmelden.

Mijn configuratie is al zo ingesteld. Maandag ga ik kijken in de man pages of er nog een optie is om het verbose level te verhogen. Ik zie gewoon te weinig in de logging. Bedankt alvast allemaal.

[Hero of Time]

Je hebt iig niet de logging laten zien van de mislukte chroot, alleen de mislukte authenticatie.

Maar je hebt ook de mogelijkheid om de ingebouwde sftp server van openssh te gebruiken samen met chroot. Daar heb je alleen maar wat extra config nodig in sshd_config. Is het ook gelijk SFTP, ipv plain FTP.

[ddkiller0900]

Ja klopt.
Wat je aangeeft van sftp is al ingericht.
Ftp, tftp, sftp gaat gebruikt worden voor het updaten/back-uppen e.d. van netwerkapparatuur. Helaas beschikken wij hier en daar nog over apparatuur die alleen ftp ondersteund. Op zich geen probleem want de communicatie gebeurt via een afgeschermd netwerk. Op termijn worden deze devices vervangen uiteindelijk.

[ddkiller0900]

Aangezien ik het niet voor elkaar krijg om extra logging te genereren heb ik besloten om het anders aan te pakken. Ik heb de homedirectory van de ftp gebruiker test gewijzigd van /hoofdmap/submap naar /home/test met de juiste rechten (700 owner/group: test:test).

Wanneer ik via ftp inlog gaat alles goed. Echter moet ik toegang hebben tot een andere map nl. /hoofdmap/submap.

Het verschil tussen /home/test en deze laatste is dat de Selinux context verschilt.
/home/test => user_home_dir_t
/hoofdmap/submap => public_content_rw_t

Wat ik heb gedaan is hoofdmap/submap gemount onder /home/test waardoor ik zonder problemen toegang krijg tot deze map via ftp. Uiteraard is dit een workaround en zal ik dus moeten kijken om de juiste context toe te kennen aan /hoofdmap/submap zodat toegang via ftp kan worden gerealiseerd.

Wat ik niet begrijp is dat wanneer de ftp gebruiker /hoofdmap/submap als homedirectory heeft, de context public_content_rw_t niet werkt. Volgens de documentatie van SeLinux zou dit namelijk geschikt zijn voor ftp, tftp, enz.

[Hero of Time]

Het is toch wel heel bijzonder dat toen je SELinux had uitgeschakeld, het ook niet werkte. Dus wat zou de context er dan mee te maken moeten hebben? Echter is de context alles als 't op Enforcing staat en een home map, waar die dan ook staat, mag geen public_content hebben. Dan gaat chroot nogal lastig voor iets als een per-user afgeschermde FTP. Weet je 100% zeker dat je na een 'setenforce permissive' geen reboot hebt gedaan?

[ddkiller0900]

Hero of Time schreef op dinsdag 04 augustus 2015 @ 20:54:
Het is toch wel heel bijzonder dat toen je SELinux had uitgeschakeld, het ook niet werkte. Dus wat zou de context er dan mee te maken moeten hebben? Echter is de context alles als 't op Enforcing staat en een home map, waar die dan ook staat, mag geen public_content hebben. Dan gaat chroot nogal lastig voor iets als een per-user afgeschermde FTP. Weet je 100% zeker dat je na een 'setenforce permissive' geen reboot hebt gedaan?

Ik snap je opmerking dat de context er niks mee te maken heeft aangezien het ook niet werkte toen Selinux was uitgeschakeld. Echter lijkt ftp WEL te werken wanneer ik dus de folder mount in de /home directory. Zodra ik de homefolder van de gebruiker wijzig naar bv /hoofdmap/submap (met context public_content_rw_t) krijg ik geen toegang, zodra ik verwijs naar een homefolder in de /home directory werkt het wel. Uit de documentatie maak ik echter op dat een folder gewoon die public_content_rw mag hebben voor ftp toegang en niet noodzakelijk de context van een homefolder. Verder is de server niet herstart.

De huidige Selinux status:

sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

[Hero of Time]

Zoals ik al zei, die SELinux context doet het dan wel voor FTP, maar alleen als dat je FTP root zou zijn zonder extra maatregelen. Je hebt echter een chroot ingesteld en dan moet je de user_home_dir_t context hebben. Iig in /home.

iets verder gezocht, op simpele woorden die je zelf had kunnen gebruiken en kwam een topic uit 2006/2007 van LQ: http://www.linuxquestions...sftpd-and-selinux-449313/
Geeft precies aan wat je nodig hebt.

[ddkiller0900]

Bedankt voor het meedenken.
Ik ga hier nog eens naar kijken.

[ Voor 82% gewijzigd door ddkiller0900 op 07-08-2015 07:57 ]