LC + Ugrade von Ubuntu: 16.04(Xenial) -> 20.04(Focal): FTP-Login schlägt fehl

  • Hallo,


    ich habe ein Upgrade von Ubuntu 16.04 auf 18.04 auf 20.04 durchgeführt. Als FTP-Server ist vsftpd installiert.


    Nach dem Upgrade funktioniert der FTP login nicht mehr(Support-Ticket ist bereits auch erstellt). Mehrfache Neuanlage von Benutzern hat nichts gebracht. Der primäre FTP-Account von Liveconfig funktioniert. Alle zusätzlichen FTP-Accounts erhalten beim Login die Fehlermeldung ...


    ...am Client:


    Code
    Ablehnung des Logins mit "530 Login incorrect."


    ...am Server in der vsftpd.log:


    Code
    [username] FAIL LOGIN: Client "13....174"


    Hier nochmal die Ausgabe von liveconfig --diag


  • Ich habe mal das debugging vom pam_userdb Plugin eingeschaltet. Dann bekomme ich im auth.log:


    Code
    Jan 11 14:10:34 primary vsftpd: pam_userdb(vsftpd-lc:auth): Verify user `validuser' with a password
    Jan 11 14:10:34 primary vsftpd: pam_userdb(vsftpd-lc:auth): password in database is [0x123450033ba0]`abcdegIDyopY', len is 13
    Jan 11 14:10:34 primary vsftpd: pam_userdb(vsftpd-lc:auth): lengths of computed and stored hashes differ
    Jan 11 14:10:34 primary vsftpd: pam_userdb(vsftpd-lc:auth): user `validuser' denied access (incorrect password)
    Jan 11 14:10:34 primary vsftpd: pam_unix(vsftpd-lc:auth): check pass; user unknown
    Jan 11 14:10:34 primary vsftpd: pam_unix(vsftpd-lc:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=validuser rhost=1.2.3.4
  • Ein anderer Kunde hatte uns auch schonmal von diesem Problem berichtet - allerdings können wir das leider nicht reproduzieren.


    Je nach Systemkonfiguration kann es sein, dass nach dem Upgrade keine "alten" crypt()-Hashes mehr für die Passwortprüfung beim proftpd funktionieren (um genau zu sein: im Modul pam_userdb.so).


    Ändern Sie testweise mal in der Datei /usr/lib/liveconfig/lua/vsftpd.lua die Zeile 675 ab, und ersetzen darin "crypt(...)" durch "crypt_md5(...)":

    Code
    pwd = LC.crypt.crypt_md5(pwd)


    Anschließend bitte LiveConfig neu starten, dann das Passwort eines virtuellen FTP-Accounts noch einmal ändern und damit dann die Anmeldung versuchen.


    Wir prüfen aktuell ob es möglich ist, dass pam_userdb.so auch die "alten" Hashes weiterhin akzeptiert. Laut man-Page zu pam_userdb sollte mit der PAM-Option "crypt=crypt" ja eben ein "crypt()"-Passwort akzeptiert werden - tut es aber nicht. :(

  • Ein Debian 11 Server ist auch betroffen. (Wurde seit Debian 8 immer mit dist-upgrade aktualisiert).


    Hier ist das liveconfig --diag von diesem:


  • Zitat von kk

    Ändern Sie testweise mal in der Datei /usr/lib/liveconfig/lua/vsftpd.lua die Zeile 675 ab, und ersetzen darin "crypt(...)" durch "crypt_md5(...)":


    Anschließend bitte LiveConfig neu starten, dann das Passwort eines virtuellen FTP-Accounts noch einmal ändern und damit dann die Anmeldung versuchen.


    Funktioniert! Danke!

  • Ich habe das eben mal geprüft: LiveConfig ruft bei "LC.crypt.crypt()" eine crypt-Variante von OpenSSL auf. Bislang war diese offenbar immer identisch mit der (nicht-portablen) POSIX crypt()-Funktion, welche pam_userdb für den Passwortvergleich nutzt.
    (wir testen das ja automatisiert durch - auf jeder unterstützten Distibution wird u.a. auch ein virtueller FTP-User angelegt und ein Login mit diesem durchgeführt)


    Wir planen nun, LC.crypt.crypt() auf die POSIX-Variante umzustellen, müssen aber prüfen dass das bei alten Systemen keine Probleme macht. Parallel prüfen wir, ob sich die alten Hashes übergangsweise weiter nutzen lassen - alternativ werden dokumentieren wir man auslesen kann, welche Accounts betroffen sind.


    Update folgt in Kürze...

  • Also, der Hintergrund dürfte nun klar sein.
    Alte pam_userdb-Versionen haben ausschließlich nur DES-Passwörter unterstützt. Besonders schlimm sind da immer alte CentOS-Versionen betroffen, da es dort keinen bequemen Upgrade-Pfad wie bei Debian/Ubuntu gibt.
    Da CentOS 6 ja nun langsam aber sicher ausstirbt, und wir Ubuntu 14 LTS auch nicht mehr offiziell unterstützen (das würde noch bis April 2024 dauern!), sollte eine Umstellung keine Auswirkungen haben.


    Die interne Ursache (warum das auf manchen Systemen klappt und auf anderen nicht) liegt eventuell in der zugrundeliegenden Crypto-Bibliothek. Modernene OpenSSL-Builds enthalten gar kein DES mehr, wie das mit GNU-Crypto aussieht weiß ich ehrlich gesagt gar nicht.


    Viele Grüße


    -Klaus Keppler

  • Nur so ein Gedanke: Die angenehmste Lösung wäre natürlich, dass die Hashes bei erfolgreicher Passworteingabe automatisch aktualisisiert werden.


    Sehe ich persönlich auch so, wird aber leider nicht klappen.
    LiveConfig bekommt nichts davon mit, wenn sich ein virtueller FTP-Benutzer anmeldet - das läuft komplett im pam_userdb ab. Das greift wiederum nur lesend auf die passwd-Datenbank zu.
    LiveConfig kennt die Passwörter auch nicht im Klartext (um die pauschal neu zu setzen): nach dem Anlegen/Aktualisieren des Hashes wird das Klartext-Passwort im LC gelöscht.

  • Wir planen nun, LC.crypt.crypt() auf die POSIX-Variante umzustellen, müssen aber prüfen dass das bei alten Systemen keine Probleme macht. Parallel prüfen wir, ob sich die alten Hashes übergangsweise weiter nutzen lassen - alternativ werden dokumentieren wir man auslesen kann, welche Accounts betroffen sind.


    Gibt es dazu schon ein Update? Aktuell kann ich ja keine Updates sauber einspielen ohne dass die Problematik wieder auftritt, weil die vsftpd.lua natürlich durch neue Pakete überschrieben wird. Ist mir ansonsten natürlich klar, dass sie aktuell mit LC3 stark beschäftigt sind.

  • Wie ist denn hier der aktuelle Stand?


    Ich habe das Problem nach einem Dist-Upgrade von Debian9 auf Debian11 nun auch.


    aus crypt ein crypt_md5 machen hat soweit geholfen, dass nach dem Neusetzen eines Passworts danach ein Login wieder möglich war.
    Aber schön ist ja nicht.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!