# ProFTPd login problems...

## milanuk

I emerged proftpd, and read thru the /etc/proftpd/proftpd.conf.distrib and copied it to /etc/proftpd/proftpd.conf.  I then started the server as a standalone daemon.  Worked out a bug in my /etc/hosts file  :Wink:  and everything seemed to be working.

When I try to log in from the localhost (on another VT), this is what I get:

```

monte@gentoo monte $ ncftp localhost

NcFTP 3.1.5 (Oct 13, 2002) by Mike Gleason (ncftp@ncftp.com).

Copyright (c) 1992-2002 by Mike Gleason.

All rights reserved.

Connecting to 127.0.0.1...

ProFTPD 1.2.9rc2 Server (ProFTPD Default Installation) [gentoo]

Login incorrect.

^[eeping 20 seconds...

monte@gentoo monte $ 

```

And tail -vf /var/log/everything/current shows this:

```

proftpd[15315]: [gentoo (localhost] error: no SQLAuthTypes configured_

proftpd[15315]: [gentoo (localhost] Permission denied_

                - Last output repeated 6 times -

proftpd[15315]: [gentoo (localhost] Invalid shell: '/bin/false'_

```

If I try logging in from another machine (emac, running OSX 10.2. :Cool: , using ncftpd, I get exactly the same  thing.  But if I try to log in w/ just the 'regular' OEM ftp client on OS X, I get this:

```

Welcome to Darwin!

bash-2.05a$ ftp gentoo

Connected to gentoo.local.net.

220 ProFTPD 1.2.9rc2 Server (ProFTPD Default Installation) [gentoo]

Name (gentoo:monte): 

331 Password required for monte.

Password:

230 User monte logged in.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> 

```

and /var/log/everthing/current  shows this:

```

proftpd[15316]: [gentoo (e-mac] error: no SQLAuthTypes configured_

proftpd[15316]: [gentoo (e-mac] Permission denied_

                - Last output repeated 9 times -

Nov 30 22:11:57 [PAM_pwdb] (ftp) session opened for user monte by (uid=0)

proftpd[15316]: [gentoo (e-mac] Permission denied_

proftpd[15316]: [gentoo (e-mac] Login successful._

```

If anyone has any ideas, or pointers to applicable documents (I'm reading thru what I can find @ the proftpd site, but the initial scan didn't seem to show much) I'd be very greatful!

TIA,

MonteLast edited by milanuk on Mon Dec 01, 2003 7:36 am; edited 1 time in total

----------

## milanuk

Well, this is what I've come up w/ so far:

I ran this command:

```

/usr/sbin/proftpd -nd6 2>&1 >& /tmp/debug

```

and 'tail'd the debug file.  A few interesting things pop up, like:

```

gentoo - dispatching auth request "getgroups" to module mod_sql

gentoo - dispatching auth request "getgroups" to module mod_auth_file

gentoo - dispatching auth request "getgroups" to module mod_auth_unix

```

The first line seems to indicate that it expects some sort of SQL ability?  As does this:

```

gentoo (e-mac[192.168.123.103]) - performing ident lookup

gentoo (e-mac[192.168.123.103]) - ident connection failed: Interrupted system call

gentoo (e-mac[192.168.123.103]) - ident lookup returned 'UNKNOWN'

gentoo (e-mac[192.168.123.103]) - mod_sql/4.10: error: no SQLAuthTypes configured

```

Now, adding a line:

```

SQLAuthTypes     Crypt

```

to /etc/proftpd/proftpd.conf gets rid of the lines in /var/log/everything/current griping about no SQLAuthTypes configured.  Not sure *why* I need SQLAuthTypes configured, when I just want to do provide basic FTP service to a handful of users.

Then the next glaring error in the debug info is this:

```

gentoo (e-mac[192.168.123.103]) - Unable to open group file /etc/group for reading: Permission denied

```

repeated off and on a half-dozen times.

Interestingly enough, the perms on /etc/group seem a bit tight, but I don't wan't to screw w/ them just yet:

```

entoo tmp # ls -al /etc/group

-rw-------    1 root     root          712 Nov 30 21:19 /etc/group

```

Any other ideas?

TIA,

MonteLast edited by milanuk on Mon Dec 01, 2003 7:46 am; edited 1 time in total

----------

## ali3nx

Here I sit at my tech-desk. looking out the frosted window at the cold winter in Canada near chistmas. Old saint nick would give to me what i wish; share what i treasure would be just the best   :Laughing: 

The configuration below will setup proftpd to run from xinetd which is much safer than funning proftpd as a standalone daemon and will cut down on your proc loads a little makin it a bit easier for xmms and proftpd to exist in harmony 

For the config's below to work properly you need to emerge tcp-wrappers xinetd proftpd then edit /etc/xinetd.conf and remove the option "only-from  localhost" that conf option is such a pain in the butt... Then nano -w /etc/xinetd.d/proftpd and enter the following text into that file if it's not allready there...

#/etc/xinetd.d/proftpd by ali3n at eliteitminds.com

#

# ProFTPd FTP daemon - http://www.proftpd.org

#

service ftp

{

	flags = REUSE

	log_on_success = HOST USERID PID

	socket_type = stream

	protocol = tcp

	user = root

	server = /usr/sbin/proftpd

	wait = no

	instances = 30

	cps = 6 2

}

#####

#

#/etc/proftpd/proftpd.conf by ali3n at eliteitminds.com

#

ServerType inetd

DefaultServer on

ServerIdent on "Jedi-Pimp Ftpd"

AuthPAM             on

AuthPAMConfig       ftp

# Port 21 is the standard FTP port.

Port 21

# Umask 022 is a good standard umask to prevent new dirs and files

# from being group and world writable.

Umask 022

# To prevent DoS attacks, set the maximum number of child processes

# to 30.  If you need to allow more than 30 concurrent connections

# at once, simply increase this value.  Note that this ONLY works

# in standalone mode, in inetd mode you should use an inetd server

# that allows you to limit maximum number of processes per service

# (such as xinetd).

MaxInstances 30

# Set the user and group under which the server will run.

User proftpd

Group proftpd

# Normally, we want files to be overwriteable.

<Directory />

  AllowOverwrite		on

</Directory>

<Global>

AllowRetrieveRestart on

AllowStoreRestart on

DefaultRoot ~

UseFtpUsers on

LoginPasswordPrompt on

AllowOverwrite on

AllowForeignAddress on

DeferWelcome on

TimeoutStalled 10

TimeoutNoTransfer 520

TimeoutLogin 20

RequireValidShell on

RootLogin off

AccessDenyMsg BuRp

AccessGrantMsg w00t

DenyFilter \*.*/

PassivePorts 11000 11100

</Global>

#

#above should be copied to /etc/proftpd/proftpd.conf

#

[sidenote]Proftpd can be so forgiving if your hostname don't match rdns hehe[/sidenote]

----------

## ali3nx

sidenote #2... 

ServerType inetd

DefaultServer on

ServerIdent on "Jedi-Pimp Ftpd" 

I set the ServerIdent because 8/10 exploits rely on host headers and why make it easy for pakit kiddies with 0Day 'sploit access  :Wink: 

----------

## milanuk

ali3nx:

Thanks, I'll give it a look-see tomorro (bedtime for bozo now!).  I heavily edited my second post while you posted your response, so it might have some (hopefully) more useful information in it.

Thanks again,

Monte

----------

## Jesore

I guess you have set a use flag for some sql database (most likely mysql). Try to do a 

```
USE="-mysql" emerge proftpd
```

It should then compile without mysql and just use the usual pam_unix authenification.

Jesore

----------

## UberLord

Are you using mysql authentication as opposed to pam authentication?

```

<IfModule mod_auth.c>

        AuthPAM                         on

        AuthPAMConfig                   ftp

</IfModule>

```

Last edited by UberLord on Tue Dec 02, 2003 11:28 am; edited 1 time in total

----------

## milanuk

I kind of wondered it that might be the case.  I'm in the process of redoing the emerge w/ USE="-mysql" right now.  Thanks for the idea!

I guess I'll see for sure when I get proftpd recompiled, but is that going to affect the issue proftpd seems to have w/ /etc/group having such strict permissions?

TIA,

Monte

----------

## milanuk

Well, redoing the emerge fixed the SQLAuth problems.  Proftpd still gripes about the permissions on /etc/group.  anybody out there w/ a functional proftpd setup care to check their log and see if their proftpd does/doesn't, so I can start tracing down what is causing it?

TIA,

Monte

----------

## milanuk

Well, for those who care, 

putting 'IdentLookup    off' in proftpd.conf fixed that bit.  Not sure why it comes as on by default; I was under the impression that most people don't rely on ident anymore because of a) security issues and b) ease of spoofing.

I chmod'd /etc/group to 0644 instead of the 0600 it was after checking w/ some people on IRC, and that took care of the problem.  Not sure at all how it got b0rked in the first place, as I *know* I didn't do it (manually at least) and the machine is not likely to have been hacked (behind a stateful firewall/router on a sloooow dialup line).

Hmmm...

Monte

----------

