vsftpd - SFTP and FTP at the same time?

chmorin

I figured I would toss this in the linux forums and see if I can't get a good answer for this. I have a node that can only connect to our server via FTP. I have vsftpd configured and nodes are able to connect to it via SFTP, but nothing can connect to it via FTP. It time's out after it puts in the password.

Any clue why I can get to it via one and not the other? I'd appreciate it.

EDIT: Worth noting probably, is this is an Ubuntu Server.

/pub/beer/

SFTP is ran through SSH. Are you saying one machine can access via FTP, the others can only access via SFTP? Is this a fresh server install or is this a box that was setup by someone else?

I would check firewall settings and the /etc/hosts.allow /etc/hosts.deny files.

chmorin

Sorry, let me explain again:

I have a server. This server needs to have nodes connect to it via SFTP and FTP.

Nodes can currently connect to it via SFTP.

Nodes can NOT connect to it via FTP.

How can I make it so the server accepts connections on both SFTP and FTP?

MentholMoose

From the server CLI run "ftp localhost" and try to login, and let us know the result either way (just copy and paste the output).

sidsanders

any reason you cant get the few machines to use sftp? if ftp is running (or under xinetd control), check the logs for either pam errors or perhaps as others mentioned iptables/tcp wrappers info/config.

if lsof is installed: lsof -i
does it show the machine is listening on tcp 21? TCP *:ftp (LISTEN)

chmorin

Here is the result of FTP Localhost:

administrator@xxx-xxxx01:~$ ftp localhost
Connected to localhost.
220 (vsFTPd 2.2.2)
Name (localhost:administrator): administrator
331 Please specify the password.
Password:
421 Timeout.
Login failed.
No control connection for command: No such file or directory
ftp>

It should be noted that once you put in the password, it sits there for an extend period of time and then times out, I assume.

sidsanders wrote: »

any reason you cant get the few machines to use sftp? if ftp is running (or under xinetd control), check the logs for either pam errors or perhaps as others mentioned iptables/tcp wrappers info/config.

if lsof is installed: lsof -i
does it show the machine is listening on tcp 21? TCP *:ftp (LISTEN)

The log shows this as a result from my recent connection:

Sat Feb 26 13:37:57 2011 [pid 2] CONNECT: Client "127.0.0.1"

That is the same as it shows for everything else, no errors.

The application that I need to support only supports FTP for backups. I could make it really complicated and re-configure the whole thing to do the backup's manually in the CLI, but that would be rather inefficient for me to do.

Thanks for the help everyone.

MentholMoose

The first step should be getting it to work from localhost. Paste the contents of (or attach) vsftpd.conf. Also are you using winbind or some other AD user integration functionality (e.g. Likewise)?

sidsanders

nothing in /var/log/messages? syslog.conf may put various errors/info some place else...

chmorin

MentholMoose wrote: »

The first step should be getting it to work from localhost. Paste the contents of (or attach) vsftpd.conf. Also are you using winbind or some other AD user integration functionality (e.g. Likewise)?

Here you are. Thanks for helping!

# Example config file /etc/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
#
# Run standalone?  vsftpd can run either from an inetd or as a standalone
# daemon started from an initscript.
listen=YES
#
# Run standalone with IPv6?
# Like the listen parameter, except vsftpd will listen on an IPv6 socket
# instead of an IPv4 one. This parameter and the listen parameter are mutually
# exclusive.
#listen_ipv6=YES
#
# Allow anonymous FTP? (Disabled by default)
anonymous_enable=NO
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# If enabled, vsftpd will display directory listings with the time
# in  your  local  time  zone.  The default is to display GMT. The
# times returned by the MDTM FTP command are also affected by this
# option.
use_localtime=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/vsftpd.log
#
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
#xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
#nopriv_user=ftpsecure
#
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
#async_abor_enable=YES
#
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that on some FTP servers, ASCII support allows a denial of service
# attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd
# predicted this attack and has always been safe, reporting the size of the
# raw file.
# ASCII mangling is a horrible feature of the protocol.
#ascii_upload_enable=YES
#ascii_download_enable=YES
#
# You may fully customise the login banner string:
#ftpd_banner=Welcome to blah FTP service.
#
# You may specify a file of disallowed anonymous e-mail addresses. Apparently
# useful for combatting certain DoS attacks.
#deny_email_enable=YES
# (default follows)
#banned_email_file=/etc/vsftpd.banned_emails
#
# You may restrict local users to their home directories.  See the FAQ for
# the possible risks in this before using chroot_local_user or
# chroot_list_enable below.
#chroot_local_user=YES
#
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
#chroot_local_user=YES
#chroot_list_enable=YES
# (default follows)
#chroot_list_file=/etc/vsftpd.chroot_list
#
# You may activate the "-R" option to the builtin ls. This is disabled by
# default to avoid remote users being able to cause excessive I/O on large
# sites. However, some broken FTP clients such as "ncftp" and "mirror" assume
# the presence of the "-R" option, so there is a strong case for enabling it.
#ls_recurse_enable=YES
#
# Debian customization
#
# Some of vsftpd's settings don't fit the Debian filesystem layout by
# default.  These settings are more Debian-friendly.
#
# This option should be the name of a directory which is empty.  Also, the
# directory should not be writable by the ftp user. This directory is used
# as a secure chroot() jail at times vsftpd does not require filesystem
# access.
secure_chroot_dir=/var/run/vsftpd/empty
#
# This string is the name of the PAM service vsftpd will use.
pam_service_name=vsftpd
#
# This option specifies the location of the RSA certificate to use for SSL
# encrypted connections.
rsa_cert_file=/etc/ssl/private/vsftpd.pem

/pub/beer/

You'll have to excuse me. I've been running fedora for 4 months now and my "Ubuntu" knowledge has slowly been leaking out.

Run "ufw show" to see to show firewall rules. Might have to run that with sudo. It could also be blocked in /etc/hosts.deny /etc/hosts.allow with TCP wrappers.

And lastly something could be blocking it with apparmor/selinux.

Is the server doing anything else? (web, email, etc) - just curious. Also - are these backups transfered within your local network or is this going over the internet? FTP is not an encrypted method of transferring files.

chmorin

/pub/beer/ wrote: »

You'll have to excuse me. I've been running fedora for 4 months now and my "Ubuntu" knowledge has slowly been leaking out.

Run "ufw show" to see to show firewall rules. Might have to run that with sudo. It could also be blocked in /etc/hosts.deny /etc/hosts.allow with TCP wrappers.

And lastly something could be blocking it with apparmor/selinux.

Is the server doing anything else? (web, email, etc) - just curious. Also - are these backups transfered within your local network or is this going over the internet? FTP is not an encrypted method of transferring files.

I'm going to assume the firewall is off, since every command I enter with ufw shows a list of commands and not actually any results.

The server is primarily RADIUS server and is not reachable outside of the LAN.

EDIT:

To test, I manually disabled ufw, and I get the same result. I guess it isn't a firewall problem.

MentholMoose

Is the "administrator" account a local user account, or is it authenticating to a centralized directory (e.g. AD, LDAP, etc.)? Also does the file /etc/vsftpd/ftpusers exist? If so, verify that any user that needs access is not listed. One other thing to try is to run "ftp", type "debug" (it should tell you debugging is on), then "open localhost" and put the username and password. This may give some additional information.

Forsaken_GA

chmorin wrote: »

Sorry, let me explain again:

I have a server. This server needs to have nodes connect to it via SFTP and FTP.

Nodes can currently connect to it via SFTP.

Nodes can NOT connect to it via FTP.

How can I make it so the server accepts connections on both SFTP and FTP?

Ok, well your question is really how can you make it connect via FTP. As others have pointed out, SFTP is handled by an entirely seperate service.

Now, when you say it cannot connect via FTP, need to be a little more specific. Is the connection refused? Is it hanging? or does it give an actual login prompt? If it's one of the first two, then it could be a firewall messing with you, or the daemon simply may not be binding to that interface (netstat -tapn will tell you if that's the case).

rhaegar:/etc# netstat -tapn | grep vsftp
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 26599/vsftpd

That indicates it's bound to all interfaces on port 21. If that only had 127.0.0.1 instead, it'd only be bound to localhost. ALOT of debian daemons default to binding to localhost by default (mysqld and snmpd come immediately to mind, though I don't remember vsftp being one of them.... if I remember right the only thing I had to make vsftpd work was set local_enable to yes)

The output you've shown below only indicates an attempt to connect via localhost. That's good, as it proves the service is up and running, but the only other thing it proves is that the daemon is bound to at least localhost.

Now, if it's actually giving you a login prompt, what happens when you try to log in? Is it refusing it? Is it giving any kind of an error message? If so, what? It looks like you're using a debian based distro, so /var/log/auth.log should give you a hint as to why a login fails. If it's bad credentials, it will tell you so.

One of the gotchas I remember specifically with a few ftp daemons is that the shell defined for the user account MUST be defined in /etc/shells. It doesn't actually have to exist (for example, I could just add /bin/boo into /etc/shells and set the users shell to that in /etc/password (filename altered because apparently the forum has an issue with the proper name of the unix password file!). It wouldn't allow them to do interactive logins, but ftp would work just fine). These days, this is usually automatic, but if you manually set a users shell to something like /bin/false in order to prevent interactive logins, then it may not be there.

Long story short, if your test from remote doesn't get you a login prompt, you have a connectivity problem. If it does, you have a configuration problem. If it's the latter, the logs will tell you what it is, it's just a matter of figuring out which log file to actually look at.

Oh, and as a general rule on Debian based systems, if a config has you scratching your head because you've got it configured one way, but it doesn't seem to actually be respecting that, check /etc/default. It doesn't apply in the case of vsftpd, but if you ever decide to enable snmpd on a box and want it to be able to be polled remotely, you'll thank me for that tip

exampasser

Do you have SElinux in Ubuntu (don't know as I have never messed around with Ubuntu)? If so, that might be blocking ftp access. I've had that happen to me in CentOS, I could connect but it then the connection would hang on me when trying to load folders.