Backup to remote has auth issues

jndawson

Well-Known Member
Aug 27, 2014
343
37
78
Western US
cPanel Access Level
DataCenter Provider
We decided to set up a remote server for backups rather than store them on the local server.

The backup server has Proftpd running and the backup user (backup) is set up and accessible using FileZilla, and other non-cpanel servers.

We've tried setting up the backup configuration using both password and key authentication - both fail.

Using the password, the error on the cpanel server is:
Code:
Error: Validation for transport “bu1” failed: The Net::SFTP::Foreign object failed to instantiate: bad remote message received
The remote server shows this in the logs:
Code:
Jun 21 12:36:59 bu1 sshd[52292]: Accepted password for backup from xxx.xxx.xxx.253 port 53282 ssh2
Jun 21 12:37:00 bu1 sshd[52292]: pam_unix(sshd:session): session opened for user backup by (uid=0)
Jun 21 12:37:00 bu1 sshd[52296]: Received disconnect from xxx.xxx.xxx.253: 11: disconnected by user
Jun 21 12:37:00 bu1 sshd[52292]: pam_unix(sshd:session): session closed for user backup
Jun 21 12:37:00 bu1 sshd[52299]: Accepted password for backup from xxx.xxx.xxx.253 port 53284 ssh2
Jun 21 12:37:00 bu1 sshd[52299]: pam_unix(sshd:session): session opened for user backup by (uid=0)
Jun 21 12:37:00 bu1 sshd[52304]: Received disconnect from xxx.xxx.xxx.253: 11: disconnected by user
Jun 21 12:37:00 bu1 sshd[52299]: pam_unix(sshd:session): session closed for user backup
Jun 21 12:37:00 bu1 sshd[52309]: Accepted password for backup from xxx.xxx.xxx.253 port 53286 ssh2
Jun 21 12:37:01 bu1 sshd[52309]: pam_unix(sshd:session): session opened for user backup by (uid=0)
Jun 21 12:37:01 bu1 sshd[52325]: Received disconnect from xxx.xxx.xxx.253: 11: disconnected by user
Jun 21 12:37:01 bu1 sshd[52309]: pam_unix(sshd:session): session closed for user backup
The docs are pretty simplistic, and appear to indicate the root private key is the key that should be used, but that fails.
Using key authentication with key located at /root/.ssh/id_rsa, we get:
Code:
Error: Validation for transport “bu1” failed: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
Remote server logs:
Code:
Jun 21 12:40:30 bu1 sshd[52716]: Connection closed by xxx.xxx.xxx.253 [preauth]
Jun 21 12:40:31 bu1 sshd[52719]: Connection closed by xxx.xxx.xxx.253 [preauth]
Jun 21 12:40:32 bu1 sshd[52721]: Connection closed by xxx.xxx.xxx.253 [preauth]
Somebody noted somewhere that the key needs to be related to the remote user.
Using key authentication and generating a key to be located at /backup/.ssh/id_rsa, we get:
Code:
Error: The following parameters were invalid: privatekey
Remote server logs show:
Code:
Nothing
Turns out generating a private key for user 'backup' is impossible using the backup configuration interface; perhaps because the user doesn't exist on the cPanel box.

So we grab the private and public keys for user 'backup' from the remote server and add them to the cpanel server. We get:
Code:
Error: Validation for transport “bu1” failed: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
Remote logs show:
Code:
Jun 21 13:11:31 bu1 sshd[55436]: Connection closed by xxx.xxx.xxx.253 [preauth]
Jun 21 13:11:32 bu1 sshd[55438]: Connection closed by xxx.xxx.xxx.253 [preauth]
Jun 21 13:11:33 bu1 sshd[55441]: Connection closed by xxx.xxx.xxx.253 [preauth]
Jun 21 13:12:35 bu1 su: pam_unix(su:session): session closed for user backup
Most related forum posts or other Internet resources relate convoluted fixes that look like more trouble than they need to be - we haven't tried any of those.

What are we doing wrong?
 
Last edited by a moderator:

24x7server

Well-Known Member
Apr 17, 2013
1,913
99
78
India
cPanel Access Level
Root Administrator
Twitter
Hi,

Are you able to execute the commands properly when you connect to the FTP backup server?
Have you validated the remote FTP backup server through the cPanel backup?
If you are not able to get over it, I think you may need to take help from a professional system administrator or you can raise a ticket to the cPanel support directly. They may assist you with this..
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,884
2,254
463
Error: Validation for transport “bu1” failed: The Net::SFTP::Foreign object failed to instantiate: bad remote message received
Hello,

Could you clarify if you are using SFTP as the destination type for backups, or FTP? You referenced FTP in your post, but the error output suggests SFTP. This is important because FTP and SFTP run on different protocols (SFTP runs over SSH).

Thank you.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,884
2,254
463
Hello,

We do have an internal case (CPANEL-5133) that's open to address an issue where the validation attempt for SFTP backup destinations fail when the remote destination runs Windows 10. Could you confirm if the remote destination is running Windows 10? If so, I'll monitor the case and update this thread with more information as it becomes available. In the meantime, the workaround is to use another protocol (e.g. FTP) for backup purposes.

Thank you.
 

jndawson

Well-Known Member
Aug 27, 2014
343
37
78
Western US
cPanel Access Level
DataCenter Provider
Hello,

We do have an internal case (CPANEL-5133) that's open to address an issue where the validation attempt for SFTP backup destinations fail when the remote destination runs Windows 10. Could you confirm if the remote destination is running Windows 10? If so, I'll monitor the case and update this thread with more information as it becomes available. In the meantime, the workaround is to use another protocol (e.g. FTP) for backup purposes.

Thank you.
Centos 7.3
OpenSSH_6.6.1
ProFTPd version 1.35

(Windows 10? Really? Who would do such a thing?)
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,884
2,254
463
Hello,

Could you open a support ticket using the link in my signature so we can take a closer look?

Thanks.
 

jndawson

Well-Known Member
Aug 27, 2014
343
37
78
Western US
cPanel Access Level
DataCenter Provider
We opened a support ticket and the tech confirmed that we needed to authenticate the key, which had been authenticated, which wasn't working, which is why we opened the ticket. So, no real actual help.

However, for some reason, we were able to auth using the password when we couldn't before. At some point, we may revisit this, but it's working now.