anonymous ftp

[Joel]

Hello, I am having trouble getting anonymous FTP setup using 0.1RC3

Expected behavior - was working this way using D-Link's (warftp?) server:

1. Enter ftp address as URL in browser

2. Webpage shows dir listing

3. Click on file to download

Observed behavior - Alt-F 0.1RC3 vsftpd:

1. Enter ftp address as URL in browser

2. Webpage presents login dialog

3. No anonymous logins work... blank, "anonymous", "ftp", etc... cannot proceed past login dialog

I first tried configuration using the web interface:

Enable Anonymous: yes

Anonymous folder: [specified]

Enable SSL: yes

Then I tried configuring /etc/vsftpd.conf manually:

  GNU nano 2.2.4            File: /etc/vsftpd.conf                              


allow_anon_ssl=yes
anon_mkdir_write_enable=no
anon_other_write_enable=no
anon_umask=0
anon_root=/mnt/sda2/Media/Music/Indie
chroot_local_user=no
allow_writeable_chroot=no
anonymous_enable=yes
anon_upload_enable=no
ssl_enable=yes
force_local_logins_ssl=no
force_local_data_ssl=no
userlist_enable=yes

Here is the version info:

# vsftpd -version
vsftpd: version 3.0.2

Am I doing something wrong? I'm not sure how to proceed from here, any help would be appreciated.

[João Cardoso]

On Saturday, November 23, 2013 6:54:00 PM UTC, Joel wrote:

Hello, I am having trouble getting anonymous FTP setup using 0.1RC3

Expected behavior - was working this way using D-Link's (warftp?) server:

1. Enter ftp address as URL in browser

2. Webpage shows dir listing

3. Click on file to download

Observed behavior - Alt-F 0.1RC3 vsftpd:

1. Enter ftp address as URL in browser

2. Webpage presents login dialog

3. No anonymous logins work... blank, "anonymous", "ftp", etc... cannot proceed past login dialog

Try first in the command line, to see any error message returned from vsftpd that don't shows-up in the system log, e.g.:

jcard@silver> ftp nas

Connected to nas.homenet.

220 (vsFTPd 3.0.2)

Name (nas:jcard): ftp

500 OOPS: cannot change directory:/mnt/md0/Public

ftp: Login failed.

ftp> bye

500 OOPS: priv_sock_get_cmd

 

[Joel]

Good idea, thanks for your help.

Here is an attempt using blanks:
joel@ubuntu-office:~$ ftp 76.115.xxx.xx
Connected to 76.115.xxx.xx.
220 (vsFTPd 3.0.2)
Name (76.115.xxx.xx:joel):
331 Please specify the password.
Password:
530 Login incorrect.
Login failed.

Here is an attempt using "anonymous":
joel@ubuntu-office:~$ ftp 76.115.xxx.xx
Connected to 76.115.xxx.xx.
220 (vsFTPd 3.0.2)
Name (76.115.xxx.xx:joel): anonymous
500 OOPS: vsftpd: refusing to run with writable root inside chroot()
Login failed.
421 Service not available, remote server has closed connection

[João Cardoso]

On Saturday, November 23, 2013 8:26:35 PM UTC, Joel wrote:

Good idea, thanks for your help.

Here is an attempt using blanks:
joel@ubuntu-office:~$ ftp 76.115.xxx.xx
Connected to 76.115.xxx.xx.
220 (vsFTPd 3.0.2)
Name (76.115.xxx.xx:joel):
331 Please specify the password.
Password:
530 Login incorrect.
Login failed.

Here is an attempt using "anonymous":
joel@ubuntu-office:~$ ftp 76.115.xxx.xx
Connected to 76.115.xxx.xx.
220 (vsFTPd 3.0.2)
Name (76.115.xxx.xx:joel): anonymous
500 OOPS: vsftpd: refusing to run with writable root inside chroot()

Ah, already addressed, search the forum for  "refusing to run with writable root inside chroot".

I think that the vsftpd Alt-F package (installable on disk and overriding the one built in the firmware) solves that issue

[Joel]

Thank you!

I am making progess but still having problems.

On Saturday, November 23, 2013 1:04:24 PM UTC-8, João Cardoso wrote:

Ah, already addressed, search the forum for  "refusing to run with writable root inside chroot".

I think that the vsftpd Alt-F package (installable on disk and overriding the one built in the firmware) solves that issue

 I installed the 2.3.5-1 Alt-F package, specified the directory, and changed the directory permissions to 755 = Success!

Observed behavior - Alt-F vsftpd 2.3.5-1:

1. Enter ftp address as URL in browser

2. Webpage shows dir listing

3. Click on file to download, but download never starts and eventually times out.

(duplicated in Chrome, Firefox, terminal)

Output from terminal attempt:

joel@ubuntu-office:~$ ftp 76.115.xxx.xx
Connected to 76.115.xxx.xx.

220 (vsFTPd 2.3.5)
Name (76.115.xxx.xx:joel): ftp
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get SlowSession.mp3
local: SlowSession.mp3 remote: SlowSession.mp3
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for SlowSession.mp3 (3070373 bytes).

[João Cardoso]

On Saturday, November 23, 2013 10:07:38 PM UTC, Joel wrote:

Thank you!

I am making progess but still having problems.

On Saturday, November 23, 2013 1:04:24 PM UTC-8, João Cardoso wrote:

Ah, already addressed, search the forum for  "refusing to run with writable root inside chroot".

I think that the vsftpd Alt-F package (installable on disk and overriding the one built in the firmware) solves that issue

 I installed the 2.3.5-1 Alt-F package, specified the directory, and changed the directory permissions to 755 = Success!

hmm, not clear, success on the command line and browser? or only partial success on cmd line?

browser cache effects? caching old user:pass?

 

Observed behavior - Alt-F vsftpd 2.3.5-1:

1. Enter ftp address as URL in browser

Try using ftp://ftp:ftp@yournas as the URL

 

2. Webpage shows dir listing

3. Click on file to download, but download never starts and eventually times out.

(duplicated in Chrome, Firefox, terminal)

You might want to turn on ful logging. From the vsftpd.conf manual page: (there are more log options :-)

       vsftpd_log_file

              This option is the name of the file to which we write the vsftpd style log  file.

              This  log  is  only  written  if  the  option  xferlog_enable  is  set, and xfer-

              log_std_format is NOT set. Alternatively, it is  written  if  you  have  set  the

              option  dual_log_enable.   One  further  complication  -  if  you  have  set sys-

              log_enable, then this file is not written and output is sent to  the  system  log

              instead.

              Default: /var/log/vsftpd.log

       xferlog_file

              This  option is the name of the file to which we write the wu-ftpd style transfer

              log. The transfer log is only written if the option xferlog_enable is set,  along

              with xferlog_std_format.  Alternatively, it is written if you have set the option

              dual_log_enable.

              Default: /var/log/xferlog

[Joel]

On Saturday, November 23, 2013 2:41:16 PM UTC-8, João Cardoso wrote:

hmm, not clear, success on the command line and browser? or only partial success on cmd line?

browser cache effects? caching old user:pass?

Sorry, that was confusing. Success meant that I did not get prompted for a login, which was the original problem statement. However, now that it logs in successfully I am not able to actually download any of the files.

 

On Saturday, November 23, 2013 2:41:16 PM UTC-8, João Cardoso wrote:

Try using ftp://ftp:ftp@yournas as the URL

I did this, same behavior: no login prompt (good), but unable to download file (bad).

 On Saturday, November 23, 2013 2:41:16 PM UTC-8, João Cardoso wrote:

You might want to turn on ful logging. From the vsftpd.conf manual page: (there are more log options :-)

       vsftpd_log_file

              This option is the name of the file to which we write the vsftpd style log  file.

              This  log  is  only  written  if  the  option  xferlog_enable  is  set, and xfer-

              log_std_format is NOT set. Alternatively, it is  written  if  you  have  set  the

              option  dual_log_enable.   One  further  complication  -  if  you  have  set sys-

              log_enable, then this file is not written and output is sent to  the  system  log

              instead.

              Default: /var/log/vsftpd.log

       xferlog_file

              This  option is the name of the file to which we write the wu-ftpd style transfer

              log. The transfer log is only written if the option xferlog_enable is set,  along

              with xferlog_std_format.  Alternatively, it is written if you have set the option

              dual_log_enable.

              Default: /var/log/xferlog

Either I'm not doing it correctly or there isn't much info. I added the following to /etc/vsftpd.conf to enable logging and specify the file locations:

dual_log_enable=yes
xferlog_file=/mnt/sda2/joel/xferlog
vsftpd_log_file=/mnt/sda2/joel/vsftpd.log

Only xferlog was generated and contained only this:

# cat /mnt/sda2/joel/xferlog
Sat Nov 23 22:09:04 2013 56 192.168.0.2 18824 /SlowSession.mp3 b _ o a <no_password> ftp 0 * i
# cat /mnt/sda2/joel/vsftpd.log
cat: can't open '/mnt/sda2/joel/vsftpd.log': No such file or directory

I think the vsftpd.log was redirected to the System Log based on this switch:

syslog_enable=yes

Here is what I found there using the Alt-F log utility:

Nov 23 21:37:07 T4HDD ftp.info vsftpd[1268]: [ftp] OK LOGIN: Client "192.168.0.2", anon password ""
Nov 23 21:38:21 T4HDD ftp.info vsftpd[1239]: [ftp] FAIL DOWNLOAD: Client "192.168.0.2", "/SlowSession.mp3", 18824 bytes, 0.03Kbyte/sec
Nov 23 21:56:58 T4HDD ftp.info vsftpd[1875]: [ftp] OK LOGIN: Client "192.168.0.169", anon password ""
Nov 23 21:57:03 T4HDD ftp.info vsftpd[1877]: [ftp] OK DOWNLOAD: Client "192.168.0.169", "/SlowSession.mp3", 3070373 bytes, 7325.99Kbyte/sec
Nov 23 21:57:40 T4HDD ftp.info vsftpd[1879]: [ftp] OK LOGIN: Client "192.168.0.169", anon password ""
Nov 23 21:57:46 T4HDD ftp.info vsftpd[1881]: [ftp] OK DOWNLOAD: Client "192.168.0.169", "/SlowSession.mp3", 3070373 bytes, 11307.38Kbyte/sec
Nov 23 22:00:11 T4HDD ftp.info vsftpd[1885]: [ftp] OK LOGIN: Client "66.249.64.7", anon password ""
Nov 23 22:08:03 T4HDD ftp.info vsftpd[1905]: [ftp] OK LOGIN: Client "192.168.0.2", anon password ""
Nov 23 22:09:04 T4HDD ftp.info vsftpd[1907]: [ftp] FAIL DOWNLOAD: Client "192.168.0.2", "/SlowSession.mp3", 18824 bytes, 0.33Kbyte/sec

I draw three conclusions from this:
1. When I login externally (mimicking remote access) the file transfer fails [192.168.0.2]
2. When I login to the IP adress on my local network the fine transfer succeeds [192.168.0.169]
3. Google is crawling me [66.249.64.7]

I guess this means I will have to consider that the router has some influence. But why did this work before? The only thing I have changed is the DNS-323 firmware.

[João Cardoso]

Do you have subnets in your local network?

I can't help you here. But from the above log vsftp gets contacted, and login succeeds, even for non-local access!?

 

 

I guess this means I will have to consider that the router has some influence.

You never said that you was trying non-local network access! Of course the router plays a role in that

 

But why did this work before?

Was you running some DDNS client on the box that was opening ports on the router?

The Alt-F shipped DDNS client don't mess with routers ports. (I suppose, as that is not his role)

If you end-up clarifying this local/non-local access issue I would appreciate if you report back.

[Joel]

On Sunday, November 24, 2013 6:50:16 AM UTC-8, João Cardoso wrote:

Do you have subnets in your local network?

Not that I know of. All of my IPs are 192.168.0.* and my router's subnet mask is 255.255.255.0

 

I can't help you here. But from the above log vsftp gets contacted, and login succeeds, even for non-local access!?

Yes, correct. 

You never said that you was trying non-local network access! Of course the router plays a role in that

Sorry, I thought that was clear since I was obscuring my IP with xxx.xx

The purpose is to allow my computer-illiterate bandmate to download our songs/practices, so it has to work non-local.

Was you running some DDNS client on the box that was opening ports on the router?

The Alt-F shipped DDNS client don't mess with routers ports. (I suppose, as that is not his role)

No, I host a webpage which includes a link to the ftp://76.115.xxx.xx directly. If my ISP changes my IP address I simply update the webpage.

 

If you end-up clarifying this local/non-local access issue I would appreciate if you report back.

I hope the above clarifies. Also, new information this morning: I now have confirmation from a bandmate that he is able to both connect and download remotely, so it seems that things are working as intended. It is curious that locally I have to log in to the local IP address, whereas before I could locally log in to the remote IP address.

To summarize:

Local IP to local IP: Connect = OK. Download = OK

Remote IP to external IP: Connect = OK. Download = OK

Local IP to external IP: Connect = OK. Download = fail

I guess this issue is closed since the intended functionality works, I'll just work around the little local/external quirk.