#977107 proftpd-core: AuthAliasOnly and AuthUserAlias in Anonymous section cause login denied #977107
- Package:
- proftpd-core
- Source:
- proftpd-dfsg
- Description:
- Versatile, virtual-hosting FTP daemon - binaries
- Submitter:
- Javier Kohan
- Date:
- 2025-04-24 17:36:04 UTC
- Severity:
- normal
- Tags:
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Running configuration in jessie and before. Upgraded system to stretch (didn't test in stretch) and then to buster.
Using Useralias for websites . All was working ok, but after upgrade can not login.
proftpd[22592] xxxxxxdu.ar (localhost[::1]): USER xxxxxxxxxxxx (Login failed): No such user found
(some data edited for privacy)
UserAlias users map to www-data
Each folder of our web is configured like this:
<Anonymous /var/www/xxxxx>
AnonRequirePassword on
RequireValidShell off
AuthAliasOnly on
User www-data
UserAlias xxxxx www-data
Group www-data
Umask 003
GroupOwner www-data
MaxClients 2
AccessGrantMsg "Acceso Permitido a %u - Toda su actividad esta siendo monitoreada."
HideNoAccess on
UserPassword www-data w4/CBsf6D7jf2
</Anonymous>
have several folders like that.
More information: we are using smbldap-tools and have users in ldap. However www-data is not in ldap, only in files (as it was from jessie and even before)
*** End of the template - remove these template lines ***
tags 977107 + moreinfo thanks Please, provide the whole setup (for files that differ from distributed ones). often evil is in details. Hide sensible information like IPs, domains and passwords, of course. This smells like a configuration issue which changed from stretch times. Thanks
tags 977107 = confirmed upstream
severity 977107 normal
thanks
Ok, I managed to replicate the issue by using the default configuration
and your snippet on buster. It works only by removing the
AuthAliasOnly/AuthUsingAlias directives.
Also, I did a fast trial with the latest jessie version (several security
patch had been applied during its support time) with the same results.
Same results with testing and moving AuthAliasOnly in global, too.
<Anonymous /var/www/xxxxx>
AnonRequirePassword on
RequireValidShell off
AuthAliasOnly on <----- here the problem
AuthUsingAlias on <----- here the problem, even by using xxxxx for UserPassword
User www-data
UserAlias xxxxx www-data
Group www-data
Umask 003
GroupOwner www-data
MaxClients 2
AccessGrantMsg "Acceso Permitido a %u - Toda su actividad esta siendo monitoreada."
HideNoAccess on
UserPassword www-data w4/CBsf6D7jf2
</Anonymous>
Hello. Sorry for the delay. I was on a trip this weekend. I´m not using "AuthUsingAlias", just "AuthAliasOnly". I have a near default proftpd.conf and then ( in a file included from conf.d with) 400 users defined by the snippet I already sent (without AuthUsingAlias, as told before). Well, removing all AuthAliasOnly from the configuration, started to work as expected. What I still don´t understand is if it is a bug or a configuration error. Do you still need my proftpd.conf ? Thanks a lot. Javier El 12/12/2020 a las 13:00, Francesco P. Lovergine escribió:
Yep, I found that both directives give problems. is confirmed by using a simple configuration. The only strange thing is that I found the same issue in jessie (latest from LTS security branch) 1.3.5e+r1.3.5-2+deb8u7, so the last working one was probably 1.3.5-1.1+deb8u2? Note: Apparently a similar issue as for #4255 has been fixed in 1.3.5c and 1.3.6rc1, so it is definitively weird.