vsftpd nie udaje się uwierzytelnić pam


13

Przeniesienie sprawdzonej konfiguracji vsftpd na nowy serwer z Fedorą 16 napotkałem problem. Wygląda na to, że wszystko poszło tak, jak powinno, ale uwierzytelnianie użytkownika kończy się niepowodzeniem. Nie mogę znaleźć żadnego wpisu w żadnym dzienniku wskazującym, co się stało.

Oto pełny plik konfiguracyjny:

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 wzywa mnie do podania nazwy użytkownika i hasła, podaję je, login niepoprawny. Zweryfikowałem, że ten użytkownik może zalogować się z ssh. Coś się zepsuło pam_service.

Anonimowy (jeśli zmieniono na dozwolony) wydaje się działać dobrze.

SELinux jest wyłączony.

Wygląda na to, że Ftpsecure jest dobrze skonfigurowany ... Mam całkowitą stratę!

Oto pliki dziennika, które sprawdziłem bez powodzenia:

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

Znaleziono coś w /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'

Może powinienem spojrzeć na /var/log/wtf-is-wrong.help :-)

Więcej informacji:

/etc/pam.d/vsftpd wygląda następująco:

#%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
Jaka jest konfiguracja PAM ( /etc/pam.d/vsftpdtak myślę)?
Gilles 'SO - przestań być zły'

Spróbuj /var/log/sysloglub dmesg.
Cześć71,

pam config: sesja opcjonalna pam_keyinit.so wymuś odwołanie autoryzacji wymagane pam_listfile.so item = user sense = odmowa pliku = / etc / vsftpd / ftpusers onerr = udane uwierzytelnienie wymagane pam_shells.so autoryzacja zawiera konto uwierzytelniania hasłem wymagana sesja autoryzacji hasła pam_loginuid Sesja .so obejmuje uwierzytelnianie hasłem
KateYoak

Odpowiedzi:


24

Uff Rozwiązałem problem. Jest to konfiguracja, ale w /etc/pam.d/vsftpd

Ponieważ sesje ssh zakończyły się powodzeniem, a sesje ftp nie powiodły się, poszedłem do

/etc/pam.d/vsftpd, usunął wszystko, co tam było i zamiast tego umieścił zawartość pliku ./sshd, aby dokładnie pasować do reguł. Wszystko działało!

Metodą eliminacji stwierdziłem, że linia obrażająca była:

    auth       required     pam_shells.so

Usunięcie go pozwala mi kontynuować.

Tuning out, „pam_shells to moduł PAM, który pozwala na dostęp do systemu tylko wtedy, gdy powłoka użytkownika jest wymieniona w / etc / shells.” Spojrzałem tam i na pewno, bez uderzenia, bez niczego. Jest to, moim zdaniem, błąd w konfiguracji vsftpd, ponieważ nigdzie w dokumentacji nie ma edytora / etc / shells. Dlatego domyślna instalacja i instrukcje nie działają zgodnie z opisem.

Poszukam teraz, gdzie mogę zgłosić błąd.


/ etc / shells zwykle zawiera listę akceptowalnych powłok. Jest używany przez kilka różnych podsystemów i oczekuje się, że będzie poprawny. Ten plik nie jest tworzony ani obsługiwany przez vsftpd, ale raczej przez podstawową konfigurację twojej dystrybucji. Więc to nie jest błąd vsftpd, to błąd w konfiguracji komputera.
tylerl 24.04.2013

Boże dzięki! Powinienem był widzieć, że ten użytkownik nie może się zalogować i dopasował tych z / sbin / nologin jako powłoki użytkownika ...
mveroone

Dziękuję bardzo! Twój komentarz na temat /etc/shellspomógł mi znaleźć przyczynę tej dziwnej zmiany zachowania. Użytkownik FTP został utworzony Shell: /sbin/nologini /sbin/nologinzostał usunięty z /etc/shells. Więc dodałem linie /sbin/nologini /usr/sbin/nologinco czyniło auth required pam_shells.sopracę też.
Bodo Hugo Barwich

4

Używam Ubuntu i miałem ten sam problem

Rozwiązanie:

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

Następnie komentuj i dodaj wiersze w następujący sposób

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

Jak wspomniałeś we własnej odpowiedzi, powłoka użytkownika powinna być wymieniona w /etc/shells. Możesz ustawić /sbin/nologinjako powłokę użytkownika, aby zabraniać ssh i zezwalać na ftp bez zmiany konfiguracji pam:

usermod -s /sbin/nologin restricted_ftp_user

0

Jeśli vsftpd zawiedzie z błędem

vsftpd.service: proces kontroli zakończony, kod = status zakończony = 2

Następnie inną możliwością jest sprawdzenie, czy pasv_addr_resolve=YESjest ustawiony w /etc/vsftpd/vsftpd.confpliku. To powoduje, że nazwa hosta serwera FTP jest rozpoznawana przez DNS. Jeśli nie będzie postanowienie, tak jakby nie można DNS ping yourhostname.example.com, a następnie będziesz musiał rozwiązać ten problem rozpoznawania nazw DNS lub zestaw pasv_addr_resolve=NOW /etc/vsftpd/vsftpd.confi powinien przynajmniej niech vsftpd uruchomić bez błędu.


0

Wpadłem również na to samo dziwne zachowanie, w którym skonfigurował się użytkownik FTP

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

na jednym System może się zalogować, a na drugim nie.

W odpowiedzi na Odpowiedź @KateYoak okazało się, że /etc/shellsPlik był inny i nie zawierał /sbin/nologinpowłoki. w którym dokonano uwierzytelnienia PAM/etc/pam.d/vsftpd

auth       required     pam_shells.so

zawieść

Po prostu dodając do /etc/shellspliku brakujące linie

/sbin/nologin
/usr/sbin/nologin

odprawa /etc/pam.d/vsftpddziałała.

Tak więc działający /etc/shellsplik powinien mieć:

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

0

w moim przypadku wybrałem komentarz do wiersza autoryzacji w pliku konfiguracyjnym /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

Oto powód. Jeśli dodasz / sbin / nologin jako system powłoki, prawdopodobnie możesz otworzyć niechciane backdoor w swoim systemie. Zamiast tego zmiana tego pliku na pewno wpływa tylko na vsftpd .

Nie wiem, czy inny proces, taki jak sshd, szuka powłok systemowych, ale myślę, że zmiana pliku pam.d jest lepszym rozwiązaniem niż inne.


-2

Utwórz kopię zapasową pliku konfiguracyjnego przed dokonaniem zmiany;

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

a następnie edytuj vsftpd.conf (z vi lub nano)

nano /etc/vsftpd.conf

Następnie wprowadź następującą zmianę

pam_service_name=ftp

Zapisz zmianę i zrestartuj serwer ftp (jeśli używasz nano, naciśnij CTRL + O i Enter, aby zapisać, a następnie CTRL + X, aby wyjść)

sudo service vsftpd restart
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.