vsftpd fallisce l'autenticazione pam


13

Spostando una configurazione vsftpd collaudata su un nuovo server con Fedora 16, ho riscontrato un problema. Tutto sembra andare come dovrebbe, ma l'autenticazione dell'utente fallisce. Non riesco a trovare alcuna voce in alcun registro che indica cosa è successo.

Ecco il file di configurazione completo:

anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
idle_session_timeout=0
data_connection_timeout=0
nopriv_user=ftpsecure
connect_from_port_20=YES
listen=YES
chroot_local_user=YES
chroot_list_enable=NO
ls_recurse_enable=YES
listen_ipv6=NO

pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES

FTP mi richiede un nome utente e una password, li fornisco, Accesso errato. Ho verificato, questo utente è in grado di accedere da SSH. Qualcosa è rovinato pam_service.

Anonimo (se modificato in consentito) sembra funzionare bene.

SELinux è disabilitato.

Ftpsecure sembra essere configurato bene ... Sono completamente perso!

Ecco i file di registro che ho esaminato senza successo:

/var/log/messages
/var/log/xferlog      #empty
/var/log/vsftpd.log   #empty
/var/log/secure

Trovato qualcosa in /var/log/audit/audit.log:

type=USER_AUTH msg=audit(1335632253.332:18486): user pid=19528 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="kate" exe="/usr/sbin/vsftpd" hostname=ip68-5-219-23.oc.oc.cox.net addr=68.5.219.23 terminal=ftp res=failed'

Forse dovrei guardare /var/log/wtf-is-wrong.help :-)

Ulteriori informazioni:

/etc/pam.d/vsftpd è simile al seguente:

#%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

1
Qual è la configurazione PAM ( /etc/pam.d/vsftpd, credo)?
Gilles 'SO- smetti di essere malvagio' il

Prova /var/log/syslogo dmesg.
Ciao,

pam config: sessione opzionale pam_keyinit.so forza revoca autorizzazione richiesta pam_listfile.so item = senso utente = nega file = / etc / vsftpd / ftpusers onerr = esito positivo richiesto pam_shells.so autentica include password-autent account include password-auth sessione richiesta pam_loginuid La sessione .so include password-auth
KateYoak il

Risposte:


24

Accidenti. Ho risolto il problema Si tratta di una configurazione ma all'interno di /etc/pam.d/vsftpd

Dato che le sessioni ssh sono riuscite mentre le sessioni ftp hanno fallito, sono andato a

/etc/pam.d/vsftpd, rimosso tutto ciò che era lì e invece posizionò il contenuto di ./sshd in modo che corrispondesse esattamente alle regole. Tutto ha funzionato!

Con il metodo di eliminazione, ho scoperto che la linea offensiva era:

    auth       required     pam_shells.so

Rimuoverlo mi permette di procedere.

Tuns out, "pam_shells è un modulo PAM che consente l'accesso al sistema solo se la shell degli utenti è elencata in / etc / shells." Ho guardato lì e abbastanza sicuro, niente bash, niente di niente. Questo è un bug nella configurazione di vsftpd secondo me dato che da nessuna parte nella documentazione è possibile modificare / etc / shells. Pertanto, l'installazione e le istruzioni predefinite non funzionano come indicato.

Vado a trovare dove posso inviare il bug ora.


/ etc / shells dovrebbe in genere contenere un elenco di shell accettabili. Questo è usato da parecchi sottosistemi diversi e dovrebbe essere corretto. Questo file non è creato o gestito da vsftpd, ma piuttosto dalla configurazione di base della tua distribuzione. Quindi questo non è un bug vsftpd, è un bug con la configurazione del tuo computer.
tylerl,

Dio grazie! Avrei dovuto vedere che l'utente che non era in grado di accedere corrispondeva a quelli con / sbin / nologin come shell utente ...
mveroone

Grazie mille! Il tuo commento su /etc/shellsmi ha aiutato a trovare la ragione di questo strano cambiamento di comportamento. L'utente FTP è stato creato con Shell: /sbin/nologine /sbin/nologinsi è rivelato essere rimosso da /etc/shells. Quindi ho aggiunto le linee /sbin/nologine anche /usr/sbin/nologinquesto ha auth required pam_shells.sofunzionato.
Bodo Hugo Barwich,

4

Sto usando Ubuntu e ho avuto lo stesso problema

Soluzione:

add-shell /sbin/nologin
sudo usermod -s /sbin/nologin ftpme
sudo vi /etc/pam.d/vsftpd

Quindi commentare e aggiungere le righe come segue

#%PAM-1.0
session    optional     pam_keyinit.so    force revoke
auth       required     pam_listfile.so item=user sense=deny file=/etc/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
@include common-auth
@include common-account
@include common-password
@include common-session

0

Come hai detto nella tua risposta, la shell utente dovrebbe essere elencata in /etc/shells. È possibile impostare /sbin/nologincome shell utente per vietare ssh e consentire ftp senza modificare la configurazione di pam:

usermod -s /sbin/nologin restricted_ftp_user

0

Se vsftpd fallisce con un errore di

vsftpd.service: processo di controllo uscito, codice = stato uscito = 2

Quindi un'altra possibilità è verificare se pasv_addr_resolve=YESè impostato nel /etc/vsftpd/vsftpd.conffile. Ciò causa la risoluzione del nome host del server FTP tramite DNS. Se il DNS non si risolve, come se non fosse possibile ping yourhostname.example.com, dovrai risolvere quel problema di risoluzione DNS o impostarlo pasv_addr_resolve=NOin /etc/vsftpd/vsftpd.confe dovrebbe almeno consentire a vsftpd di avviarsi senza l'errore.


0

Ho anche incontrato lo stesso strano comportamento con cui un utente FTP ha configurato

# finger <user>
Login: <user>                   Name: 
Directory: /home/user-dir           Shell: /sbin/nologin
Never logged in.
No mail.
No Plan.

su un sistema è in grado di accedere e sull'altro no.

In aggiunta alla risposta di @KateYoak si è scoperto che il /etc/shellsfile era diverso e non includeva la /sbin/nologinshell. che ha reso autenticazione PAM in/etc/pam.d/vsftpd

auth       required     pam_shells.so

fallire

Aggiungendo semplicemente al /etc/shellsfile le righe mancanti

/sbin/nologin
/usr/sbin/nologin

il check-in ha /etc/pam.d/vsftpdfunzionato.

Quindi un /etc/shellsfile di lavoro dovrebbe avere:

# cat /etc/shells
/bin/sh
/bin/bash
/sbin/nologin
/usr/bin/sh
/usr/bin/bash
/usr/sbin/nologin
/bin/tcsh
/bin/csh

0

nel mio caso ho optato per un commento alla riga auth nel file di configurazione /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/f$
#auth       required    pam_shells.so
auth       include  password-auth
account    include  password-auth
session    required     pam_loginuid.so
session    include  password-auth

Ecco il motivo. Se aggiungi / sbin / nologin come sistema shell, probabilmente potresti aprire una backdoor indesiderata nel tuo sistema. Invece, cambiare questo file sicuramente influisce solo su vsftpd .

Non so se un altro processo come sshd cerchi shell di sistema, ma penso che cambiare il file pam.d sia una soluzione migliore di altre.


-2

Eseguire il backup del file di configurazione prima di apportare una modifica;

sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.back

e poi modifica vsftpd.conf (con vi o nano)

nano /etc/vsftpd.conf

Quindi apportare la seguente modifica

pam_service_name=ftp

Salvare le modifiche e riavviare il server ftp (se si utilizza Nano premere CTRL + O e immettere per salvare, quindi CTRL + X per uscire)

sudo service vsftpd restart
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.