Problem: ftpd (the package) does not let users log in. It connects ok regardless of using SSL or not, and prompts for the username and password, and then goes on to say that the login details are invalid. After many hours, I have discovered that this is nothing to do with PAM, but is in fact a shadow password issue. Using pwunconv and re-attempting to use the server resulted in success. I've checked the ebuild file, and I can see that the --without-shadow switch isn't being used, so I suspect that that SSL patch is at fault but I don't have any more time to test the system without using it - I'm way behind schedule now. I was amazed at how few servers actually support SSL, so including this daemon was most useful. Thanks guys.
What ftp client are you using to connect to the ssl enabled ftpd? I have had success using the netkit ftp w/ssl support (also in portage) but I haven't been able to verify things working with other ftp clients.
Sorry about the long wait for a reply - I've been away on holidays. I've tried many Windows clients - none of them work. I expect that would be irrelevant however, as I've also tried NetKit's SSL FTP client, and it has exactly the same problem - and is also fixed by running pwunconv. I'm 100% convinced it is getting stuck on Shaddow passwords. :(
are you going between.. or are you behind some sort of NAT or firewall? do you have any log information you can post for me?
I can't think of any loging information that I can provide. A detailed ftp client log is just as you would expect if it weren't able to login correctly. I'm not sure exactly how to analyze /var/log/ftpd/current - it only appears to have a single (seemingly irrelevant) line in it. Do I need to tail it while starting the daemon and attempt loging in? We don't have NAT. We have a firewall, but both computers are behind it - it doesn't go past the firewall to connect to this ftp server (yet). This server is in the process of being built.
I'm having the same problem. The client (I tried several clients) connects to the server, sends username and password and gets disconnected (wrong username or password). It's definately not a problem with the SSL patch. The only line in the system log shows the ftp daemon getting started by xinetd: Apr 5 23:57:34 [xinetd] START: ftp pid=21985 from=192.168.1.1
The problem is that the configure script tests whether the system supports shadow passwords or not, but the Makefile compiles ftpd without shadow support no matter what. I've created a patch which should fix the problem. Just apply it right after the SSL patch.
Created attachment 10270 [details, diff] Fix for the shadow password problem Apply right after the SSL patch.
I've got the same problem. I attached to the server with strace while logging in (connecting from localhost), and there was no access to the shadow password file. Making matters worse, I'm using NIS for most accounts, and it's not getting those, either. I did a Google search, and I found patches for using shadow passwords and nis with netkit-ftpd from 1994. (Search on netkit ftpd shadow nis.)
please test the -r1 ebuild.
Since the patch isn't SSL specific it should get applied outside the if statement, like this: src_unpack() { unpack ${A} cd ${S} if [ "`use ssl`" ]; then epatch ${FILESDIR}/ssl.diff.gz fi epatch ${FILESDIR}/${P}-shadowfix.patch } Other than that it seems to work perfectly.
thanks for checking. fixed in portage.
