DA outgoing FTP backup connection fails "username and/or password was not accepted for login"

W

wdc

Verified User
Joined
Dec 8, 2013
Messages
73
On after submitting, the wizard defining remote FTP server, it always says:
ERROR DURING CRON MODIFICATION
ncftpls: cannot open ftpserveriphere: username and/or password was not accepted for login.
/usr/bin/ncftpls returned error code 1
FTP information invalid.
Click to expand...

When i used different server with different FTP server software etc., then it worked.

So DA fails to login, but i tried to connect using that credentials (just alphanumeric under 10 characters) via different computer, and login data works to login:
TLS Handshake successful
Protocol: TLS1.2, Key exchange: ECDHE-SECP384R1-RSA-SHA384, Cipher: AES-256-GCM, MAC: AEAD

certificate is self signed, generated using "openssl req -x509 -nodes -days 36500 -newkey rsa:1024 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem"
(i am unsure if that cipher etc. is ok for DA. if not, suggest better openssl command please)

The FTP server logged (into system log file) only that connection attempts from my test computer, but not the one made from DA server backup wizard. Which is strange, because the DA error mesage does not complain about connection, but about login itself...

Later likely when DA server admin tried connection manually, my FTP server logged following:
CONNECT: Client "IP_DA_server"
FTP response: Client "IP_DA_server", "220 (vsFTPd 3.0.2)"
FTP command: Client "IP_DA_server", "AUTH TLS"
FTP response: Client "IP_DA_server", "234 Proceed with negotiation."
DEBUG: Client "IP_DA_server", "SSL version: TLSv1/SSLv3, SSL cipher: ECDHE-RSA-AES128-GCM-SHA256, not reused, no cert"
Click to expand...

no more log lines regarding that connection... note that the cipher is different from my test computer connection..

SSL tickbox in DA cause DA error:
/usr/local/bin/curl returned error code 64
curl: (64) Requested SSL level failed
FTP information invalid.
Click to expand...

UPDATE: solution to this issue may be bad iptables rules that block/forward traffic away.
 
Last edited:
So just to be clear its not DA that failing to login, its ncftpls. Try running ncftpls from the command line.
 
floyd said:
Try running ncftpls from the command line.
Click to expand...

i tried to run it on my test client computer, not on DA server and i also got error:

ncftpls: cannot open FTPserverIPhere: username and/or password was not accepted for login.

but on same computer terminal the different FTP app (lftp) is able to login using same credentials on same computer.

NcFTPLs 3.2.4 (this is on my test computer, not on DA server - but it fails on both)
LFTP | Version 4.0.9

Why ncftp fails, how to fix it, what to try please? Maybe DA can replace ncftpls by something else or skip it and report error on first backup run in case of the problem?
 
Last edited:
So you must be entering something incorrectly in the DA backup system. Without knowing exactly what you are entering there is not much more I can do.
 
floyd said:
So you must be entering something incorrectly in the DA backup system.
Click to expand...

i have found that the failing command /usr/bin/ncftpls ftp://servIP/tmp -u user -p mypass

with error "username and/or password was not accepted for login."

cause log line in FTP server log: FTP command: Client "clientIPhere", "USER anonymous"

that is strange.. (anonymous user), because i defined normal linux user "-u user"

problem was that the -u and -p parameters are expected in the command before defining the FTP server address... The misleading error " "username and/or password was not accepted for login." then disappear. The ncftpls should have failed if -u and -p was not in correct order i guess...

In DA script, is it in correct order? Can anyone confirm?
 
Last edited:
I am seeing the same thing too. I don't do cronjob ftp backups using DA so I never saw it before. I use rsync.
 
floyd said:
Have you tried this:
Click to expand...
I had the same problem backing up to my QNAP NAS and tried this with a txt file I created with "ls > 1.txt". I than found that apparently I was blocked by my NAS on ip-base on my DA-host.

Unfortunately on my NAS the ip-tables were flooded with blocks being build up for months and I wasn't able to purge in the web interface because that became irresponsive on the number of entries.

So i connected with filezilla via SSH to my NAS, downloaded the files ipsec_allow.conf and ipsec_deny.conf from /etc/config, made a copy of them, emptied them with notepadd++ and uploaded the empty files back to my NAS in /etc/config.

Now the same test as above completed succesfully and after that my backups completed succesfully again.

Cause was of course the fact I was blocked from my DA-host ip after unsuccesfull logons earlier.

Hope this will help someone
 
You must log in or register to reply here.
Back
Top