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

Mathias_Thielen · 11. Januar 2022

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

Code

Running OS diagnostics... (LiveConfig 2.13.0-release)
FILE SYSTEMS:
  / [/dev/mapper/blablub] (total: 84854562816, free: 24177389568)
  /boot [/dev/xvda1] (total: 246755328, free: 70632448)
CPUs:
  CPU: 'cpu' user=1816 nice=0 system=1544 idle=164138 wait=5503 irq=0 sirq=391 steal=7729 guest=0
  CPU: 'cpu0' user=1816 nice=0 system=1544 idle=164138 wait=5503 irq=0 sirq=391 steal=7729 guest=0
  CPU: 'cpu1' user=1816 nice=0 system=1544 idle=164138 wait=5503 irq=0 sirq=391 steal=7729 guest=0
CPU IDENTIFICATION:
  Physical CPUs: 2
  CPU Vendor: GenuineIntel
  CPU Model: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz
  Physical Core Count: 1
  Cache: 25600 KB
LOAD AVERAGE:
  Load: 1min=0.000000, 5min=0.040000, 15min=0.040000
MEMORY:
  Total Memory: 4185620480
   Free Memory: 3370524672
    Total Swap: 4664061952
     Free Swap: 4664061952
INTERFACES:
  Name: 'lo'
       MAC: 00:00:00:00:00:00
       IPv4: '127.0.0.1'/8
       IPv6: '::1'/128
       IN: 119239 bytes (835 packets)
       OUT: 119239 bytes (835 packets)
       FLAGS: UP LOOPBACK
  Name: 'eth0'
       MAC: XXX
       IPv4: '1.2.3.4'/26
       IPv6: 'XXX'/64
       IPv6: 'XXX'/64
       IN: 19843332 bytes (392369 packets)
       OUT: 4442956 bytes (6750 packets)
       FLAGS: UP BROADCAST
HOSTNAME:
  Hostname: 'primary'
      FQDN: 'XXX'
UPTIME:
  Uptime: 0 days, 00:14:35
DMI:
 Manufacturer: Xen
 Product Name: HVM domU
      Version: 4.13
       Serial: e10999c6-6c81-5dec-c33e-6d2b32b7280a
IPMI:
QUOTA for group 'root' at path /var/www: OK - kb_used=5056108, inodes_used=169950
Running Lua diagnostics...
[INFO] Detected 'Ubuntu 20.04.3 LTS'
       Distribution name: 'Ubuntu'
   Distribution codename: 'focal'
     Distribution family: 'Debian'
    Distribution version: '20.04'
Distribution description: 'Ubuntu 20.04.3 LTS'
Checking for web server software:
 - Found 'apache' web server
   Version: '2.4.41'
   Package version: '2.4.41-4ubuntu3.9'
   Modules: core so watchdog http log_config logio version unixd access_compat actions alias auth_basic authn_core authn_file authz_core authz_host authz_user autoindex deflate dir env fcgid filter headers include mime mpm_prefork negotiation php7 proxy proxy_http reqtimeout rewrite setenvif socache_shmcb ssl status suexec
 - PHP 7.4.3 [DEFAULT] (code='php7')
   CGI/FastCGI: /usr/bin/php-cgi
   default php.ini: '/etc/php/7.4/cgi/php.ini'
 - default PHP CLI: /usr/bin/php
Checking for ftp server software:
 - Found 'vsftpd' FTP server
   Version: '3.0.3-12'
   Package version: '3.0.3-12'
Checking for SMTP server software:
 - Found 'postfix' smtp server
   Version: '3.4.13'
   Package version: '3.4.13-0ubuntu1.2'
   DANE/TLSA support: 'yes'
 - SpamAssassin: NOT FOUND
 - OpenDKIM: NOT FOUND
Checking for POP/IMAP server software:
Checking for database server software:
 - Found 'mysql' database server
   Version: '8.0.27'
   Package version: '8.0.27-0ubuntu0.20.04.1'
Checking for DNS server software:
Done.

Alles anzeigen

Mathias_Thielen · 11. Januar 2022

Ich habe auch mal manuell das Passwort via userdbadm[1] via Konsole gesetzt. Geht auch nicht.

[1] https://nasauber.de/opensource/userdbadm/

Mathias_Thielen · 11. Januar 2022

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

kk · 11. Januar 2022

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.

Mathias_Thielen · 11. Januar 2022

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

Hier ist das liveconfig --diag von diesem:

Code

Running OS diagnostics... (LiveConfig 2.13.0-release)
FILE SYSTEMS:
  / [/dev/xvda1] (total: 417338998784, free: 151514234880)
CPUs:
  CPU: 'cpu' user=18550864 nice=477181 system=8525242 idle=278685389 wait=6930450 irq=0 sirq=753004 steal=1139750 guest=0
  CPU: 'cpu0' user=18550864 nice=477181 system=8525242 idle=278685389 wait=6930450 irq=0 sirq=753004 steal=1139750 guest=0
  CPU: 'cpu1' user=18550864 nice=477181 system=8525242 idle=278685389 wait=6930450 irq=0 sirq=753004 steal=1139750 guest=0
  CPU: 'cpu2' user=18550864 nice=477181 system=8525242 idle=278685389 wait=6930450 irq=0 sirq=753004 steal=1139750 guest=0
  CPU: 'cpu3' user=18550864 nice=477181 system=8525242 idle=278685389 wait=6930450 irq=0 sirq=753004 steal=1139750 guest=0
CPU IDENTIFICATION:
  Physical CPUs: 1
  CPU Vendor: GenuineIntel
  CPU Model: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz
  Physical Core Count: 4
  Cache: 25600 KB
LOAD AVERAGE:
  Load: 1min=0.690000, 5min=0.440000, 15min=0.590000
MEMORY:
  Total Memory: 8305029120
   Free Memory: 4919656448
    Total Swap: 5367656448
     Free Swap: 4432588800
INTERFACES:
  Name: 'lo'
       MAC: 00:00:00:00:00:00
       IPv4: '127.0.0.1'/8
       IPv6: '::1'/128
       IN: 2695199448 bytes (11429742 packets)
       OUT: 2695199448 bytes (11429742 packets)
       FLAGS: UP LOOPBACK
  Name: 'eth0'
       MAC: XXX
       IPv4: 'XXX'/26
       IPv6: 'XXX'/64
       IPv6: 'XXX'/64
       IN: 1104653370 bytes (447674015 packets)
       OUT: 1714707464 bytes (83810686 packets)
       FLAGS: UP BROADCAST
  Name: 'eth0:1'
       MAC: XXX
       IPv4: 'XXX'/26
       FLAGS: UP BROADCAST
  Name: 'eth0:2'
       MAC: XXX
       IPv4: 'XXX'/26
       FLAGS: UP BROADCAST
  Name: 'eth0:3'
       MAC: XXX
       IPv4: 'XXX'/26
       FLAGS: UP BROADCAST
HOSTNAME:
  Hostname: 'web'
      FQDN: 'XXX'
UPTIME:
  Uptime: 9 days, 03:36:18
DMI:
 Manufacturer: Xen
 Product Name: HVM domU
      Version: 4.13
       Serial: 20a1d1ff-81a3-9d6b-5f53-4e49bffb7c1d
IPMI:
QUOTA for group 'root' at path /var/www: OK - kb_used=23497576, inodes_used=262832
Running Lua diagnostics...
[INFO] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'
[INFO] Loading hooks...
[INFO] Detected 'Debian GNU/Linux 11 (bullseye)'
[INFO] setting PHP default version to 'php73'
       Distribution name: 'Debian'
   Distribution codename: 'bullseye'
     Distribution family: 'Debian'
    Distribution version: '11'
Distribution description: 'Debian GNU/Linux 11 (bullseye)'
Checking for web server software:
 - Found 'apache' web server
   Version: '2.4.52'
   Package version: '2.4.52-1~deb11u2'
   Modules: core so watchdog http log_config logio version unixd access_compat alias auth_basic authn_core authn_file authz_core authz_groupfile authz_host authz_user autoindex cgi deflate dir env expires fcgid filter mime mpm_prefork negotiation proxy proxy_fcgi proxy_html proxy_http reqtimeout rewrite setenvif socache_shmcb ssl status suexec xml2enc
 - PHP 7.2.34 (code='php72', eol='2020-11-30')
   CGI/FastCGI: /opt/php-7.2/bin/php-cgi
   FPM: /opt/php-7.2/sbin/php-fpm
        pool config: /etc/php-fpm/php72-fpm.d
   default php.ini: '/opt/php-7.2/etc/php.ini'
 - PHP 7.3.33 [DEFAULT] (code='php73', eol='2021-12-06')
   CGI/FastCGI: /opt/php-7.3/bin/php-cgi
   FPM: /opt/php-7.3/sbin/php-fpm
        pool config: /etc/php-fpm/php73-fpm.d
   default php.ini: '/opt/php-7.3/etc/php.ini'
 - PHP 7.4.27 (code='php74', eol='2022-11-28')
   CGI/FastCGI: /opt/php-7.4/bin/php-cgi
   FPM: /opt/php-7.4/sbin/php-fpm
        pool config: /etc/php-fpm/php74-fpm.d
   default php.ini: '/opt/php-7.4/etc/php.ini'
 - PHP 8.0.14 (code='php80', eol='2023-11-26')
   CGI/FastCGI: /opt/php-8.0/bin/php-cgi
   FPM: /opt/php-8.0/sbin/php-fpm
        pool config: /etc/php-fpm/php80-fpm.d
   default php.ini: '/opt/php-8.0/etc/php.ini'
 - PHP 8.1.1 (code='php81')
   CGI/FastCGI: /opt/php-8.1/bin/php-cgi
   FPM: /opt/php-8.1/sbin/php-fpm
        pool config: /etc/php-fpm/php81-fpm.d
   default php.ini: '/opt/php-8.1/etc/php.ini'
 - default PHP CLI: /usr/bin/php
Checking for ftp server software:
 - Found 'vsftpd' FTP server
   Version: '3.0.3-12+b1'
   Package version: '3.0.3-12+b1'
Checking for SMTP server software:
 - Found 'postfix' smtp server
   Version: '3.5.6'
   Package version: '3.5.6-1+b1'
   DANE/TLSA support: 'yes'
 - SpamAssassin: NOT FOUND
 - found OpenDKIM (package version: '2.11.0~beta2-4')
   configured: yes
Checking for POP/IMAP server software:
 - Found 'dovecot' POP/IMAP server
   Version: '2.3.13'
   Package version: '1:2.1.7-7+deb7u1'
Checking for database server software:
 - Found 'mysql' database server
   Version: '10.5.12'
   Package version: '1:10.5.12-0+deb11u1'
Checking for DNS server software:
Done.

Alles anzeigen

Mathias_Thielen · 11. Januar 2022

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!

kk · 11. Januar 2022

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...

Mathias_Thielen · 11. Januar 2022

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

kk · 11. Januar 2022

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

kk · 11. Januar 2022

Zitat von Mathias_Thielen

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.

Mathias_Thielen · 1. März 2022

Zitat von kk

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.

antondollmaier · 2. März 2022

Zitat von Mathias_Thielen

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.

Die angepasste Funktion kann via custom.lua "sauber" überschrieben werden und so "update-fest" genutzt werden.

Machen wir für einige Webspace-Funktionen auch so.

aho546745 · 21. März 2022

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.

Mathias_Thielen · 24. Mai 2022

Hier nochmal der Eintrag in /usr/lib/liveconfig/lua/custom.lua, der für den Workaround vorzunehmen ist:

Code

LC.crypt.crypt = LC.crypt.crypt_md5

Danach LiveConfig einmal durchstarten, dass die custom.lua aktiviert wird.

Jetzt mitmachen!