Invalid ftp password on Admin Backup/Transfer with non-character password

W

winggundamth

Verified User
Joined
Feb 1, 2009
Messages
7
I have problem with backup via FTP. I went to Admin Backup/Transfer and setting everything to backup with cron and transfer to my another server via ftp. When I click submit button, it showing error "Invalid ftp password".

I think it is happen because of my password in consist with

Code: 
; ' ,

so I have change password to only english character and numeric and it went fine. How can I backup with password that consist above character cause I have ftp that auto generate with above character?
 
Same problem with caracter like "%", "&", it showing error "Invalid ftp password".
 
It might be a bug and the shell might be interpreting them as commands. I am not sure how they are parsed, but directadmin support should see this thread. I had this problem before with a shell script and couldnt figure it out until I escaped the non standard characters.
 
Hello,

I checked the code and what DA is checking for with ftp passwords are the four characters:
Code: 
&  =  '  "
Those are pretty much the only things that are off limits (less of course things that just don't belong, like newline characters, etc..)

The quotes ' " can likely be added as exceptions to be allowed.. but the & = characters are explicitly added for ftp passwords, so they may not be able to be removed from the block. (likely due to how the password is passed to ncftp.. would have to check).

Let me know specifically which characters you need the most and we can take a look at testing those cases.

John
 
Thank you for this reply! I also have this issue on my username but i managed to fix this with your information, so it's all fine for now!

Thanks again!
 
Im having the same problems with a password with a ! and @ in it? Somebody familiar with that?
 
I can confirm that with DA 1.45.0 CB 1.2 there is issue with at least one of these "$" and/or "#" being in an "admin" password -- perhaps it's not DA specifically, but as a package weather it be php, ncftp, mysql or whatever that is the weak link.

Experimenting with Admin Tools -> System Backup -> Remote Transfer (FTP) between two servers. One with CentOS 6 and the other with CentOS 6.5, both running DirectAdmin 1.45.0

If I wasn't so worn out looking through logs, trying debug mode, manual FTP and such I'd check the problem characters a little more.

It sure would be nice to have a complete list of problem symbols, adding ASCII symbols is good practice for password strength.

I've not worked with the other backup types that offer remote transfer yet, all user types which can be affected with the issue should be made aware of all problem characters when selecting or changing their password.

Of course it would be better to eliminate the worry completely if possible.
 
Last edited:
Hello,

In regards to password with the "System Backup", that's only an interface to the 3rd party script "sysbk".
Check:
/usr/local/sysbk/conf.sysbk

For the $ and # characters, those would likely fail in that config, because it's a /bin/sh shell..
Try changing it from $ to \$ and $ to \#, and we can go from there.

John
 
..modify the password saved inside conf.sysbk, correct? Will give it a try.

The sysbk script is only used for system backup? This topic was a little hard to follow which backup was being referred to in some of the posts..

Is it correct to assume (prior msgs apparently refer to other backup types) that the symbols being trouble in other backup types (reseller, admin -> domains(?), user, etc) are now corrected? ..the prior posts do mention:

& = ' " ! % ; , then me having trouble with # and/or $

I use random passwords and change them every so often on many sites. If no alerts on saving the new password I usually logout then login to confirm functionality and go about my business, not thinking too far ahead about certain site areas lacking pw synchronicity down the road.

I guess that many DA owners have crossed this hurdle and just move on or have other alternative backup methods or rely on provider backups.

The noobs like me though, who are going to try and use system backup / sysbk it could save some time to have an alert in DA somewhere if a user account has access to sysbk. ..and of course, hopefully the install process will avoid creating a fresh admin pw with something that could be trouble with sysbk. :)

..also could circumvent the need for someone with root access to modify conf.sysbk
 
System backup (sysbk) is not the best choice for backups (though you may want to make one at the very beginning to help if you ever need a bare-metal restore), because there's no restore function and in fact many files which it backs up, if restored, could cause problems if you're building to a newer verion of your OS Distribution.

Sysbk was originally designed for a lot of configuration by knowledgeable admins who knew exactly which files they needed to back up, and DirectAdmin staff did a remarkable job of creating an interface to it. But afterwards they created the Admin Level Reseller Backup, which is much better at backing up specifically what you need to backup and restore users, even across systems.

Only system administrators (admin level) have access to System Backup.

John's point is that the DirectAdmin interface doesn't block any characters. So if someone will test by adding the backslashes as required before special characters, and that works, hopefully we can talk him into adding some special handling into it's password input fields to apply the backslash (which works as an escape character for characters which otherwise would have a special meaning to the shell) automatically.

So the first step is for someone to test.
hopefully the install process will avoid creating a fresh admin pw with something that could be trouble with sysbk.
Click to expand...
My recollection is that the DirectAdmin supplied passwords don't use special characters.

Jeff
 
I've now spent some time examining the backup features and can better see the differences now.

I was aware the sysbk was more system/server admin related and not that suitable for the eventual hosting business side of things. I suppose my focus on this less used backup feature (sysbk) is because I am, this time around, going slow specifically to ensure I have a certain level of sysadmin competence before worrying about the rest.

Taking that into account, the backup of specific files and system level config changes are of importance as I am still tweaking things at a low level.

I do now see better that down the road, what remaining quirks may exists in sysbk and/or integration may get such infrequent use that it's somewhat trivial to worry about it.

Nonetheless, the initial exposure to this feature isn't without it's setbacks for more than a few people I'll guess. As you pointed out Jeff, and after looking at the integration of sysbk to DA over the past day or so, I too appreciate the fine job DA does interacting with the sysbk script.
 
You must log in or register to reply here.
Back
Top