System Backup - Remote Transfer (SCP) - Backup Log / Message System Inaccurate

S

Spook

Verified User
Joined
Jan 3, 2006
Messages
132
Just for kicks when working with the FTP side of the Admin Tools / System Backup trying to get data off-site, I flipped the option to SCP and tried it.

Message system shows:

Performing sanity checks: Completed
Checking load average: Completed
Checking free disk space: Completed
Performing DNS backup
Stage 1 DNS backup: Completed
Stage 2 DNS backup: Completed
Performing MySQL backup
Stage 1 MySQL backup: Completed
Stage 2 MySQL backup: Stage 3 MySQL backup:
Dumping database da_roundcube: Completed
Dumping database mysql: Completed
Dumping database performance_schema: Completed
Performing backup transfer to xxx.xxx.29.17: Completed
Performing cleanup operations: Completed

Don't quite know how, I've never set the authorized_keys2 or done any other preparations for the SCP backup type.

I was sort of thrilled to see how easy it was until I checked and realized nothing had been transferred to the remote system. I didn't really expect anything but was still a bit stoked for a couple minutes. Kinda like ordering something to eat and being informed that's all gone.

I looked through logs for a but after not finding anything within a couple mins I went back to fiddle with FTP transfers.

CentOS 6 & 6.5 + DA 1.45.0 CB 1.2
 
I swapped /root/.ssh/id_dsa.pub keys between the two DA servers -- more specifically:

A. id_dsa.pub -> B. authorized_keys2
B. id_dsa.pub -> A. authorized_keys2

Dig into the /usr/local/sysbk/conf.sysbk and saw:
Code: 
PRVID_FILE="/root/.ssh/id_dsa"
A few tests result in the 'completed message' but no backup files going either direction.

Seems very little makes it into the logs I could find. The only tell-tale signs were a lone "Firewalled Packet:" entry in /var/log/messages on each server.
Code: 
A. Mar 31 15:19:16 srv1 kernel: [4485987.035204] Firewalled packet:IN=venet0 OUT= MAC= SRC=xxx.xxx.29.107 DST=xxx.xxx.136.10 LEN=48 TOS=0x00 PREC=0x00 TTL=57 ID=57576 DF PROTO=TCP SPT=53685 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0

B. Mar 31 15:18:51 srv2 kernel: Firewalled packet:IN=eth0 OUT= MAC=00:18:3c:f8:4f:5C:00:25:8b:83:75:d0:58:20 SRC=xxx.xxx.136.10 DST=xxx.xxx.29.107 LEN=60 TOS=0x00 PREC=0x00 TTL=57 ID=55108 DF PROTO=TCP SPT=56258 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0
..so I dig around looking for a way to adjust the port for sysbk to send to scp and didn't come up with anything. So adjusted the firewall and sshd_config to allow ssh port 22. The restarted both services.

Same results.

Only few things I can think of would be try to get scp to log more or see if it can output debug info -- anything that might put more clues in the logs.

AFAIK in I pop in the original iptables firewall with no save match rules then the server would be pretty much wide open..

I'm assuming the SCP is more secure with the admin password than FTP, so I'll keep plugging away at it.

I am also assuming that the dsa key handling for this feature is to be handled by root -- not supposed to match the user (admin) and be in /home/admin/.ssh

Unless there are logs I've not been able to find this feature seems pretty tricky.

Any suggestions or enlightenment welcome.
 
I had already been using password less login from home using RSA keys (authorized_keys) and figured that I would go ahead and try SSH between the two DA systems before making new keys..

I guess this first test is not quite the same as the KB article since I didn't swap public keys and put into authorized_keys. Although did establish /root/.ssh/known_hosts on each machine.

This worked fine from shell of each machine. The initial connection was paused for confirmation of the RSA server fingerprints. The keys being exchanged are /etc/ssh/ssh_host_rsa_key[.pub] of each machine.

I'm guessing that although I deviated some from the KB article ( http://help.directadmin.com/item.php?id=516 ) it's sufficient to see that the SSH was okay between the two remote servers?

Code: 
A -> B

[root@a]# ssh -p 2217 [email protected]
The authenticity of host '[xxx.xxx.29.107]:2217 ([xxx.xxx.29.107]:2217)' can't be established.
RSA key fingerprint is 31:50:92:d9:87:a4:2f:4a:45:91:09:1f:1a:32:09:0e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[xxx.xxx.29.107]:2217' (RSA) to the list of known hosts.

Address xxx.xxx.136.10 maps to example.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Last login: Mon Mar 31 02:43:52 2014 from comcartel.jackedupmyrate!
[root@b]#

B -> A

[root@b]# ssh -p 2217 [email protected]
The authenticity of host '[xxx.xxx.136.10]:2217 ([xxx.xxx.136.10]:2217)' can't be established.
RSA key fingerprint is fc:d5:8f:20:94:c8:8e:9c:ee:15:d8:0e:40:27:60:45.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[xxx.xxx.136.10]:2217' (RSA) to the list of known hosts.

reverse mapping checking getaddrinfo for example.com [xxx.xxx.29.107] failed - POSSIBLE BREAK-IN ATTEMPT!
Last login: Mon Mar 31 02:44:15 2014 from comcartel.jackedupmyratestoo!
[root@a]#
 
I believe that has to do with the file:
Code: 
/root/.ssh/known_hosts
where you'd want to clear out the values for the external IP.
It's probably got a key from some other instance, hence the panic message.

Also check the reverse IP lookup of the IP.. check:
/etc/hosts

as it might be checking the reverse IP lookup which points to the wrong IP (from the host, via PTR)
 
I'm pretty certain the reverse IP lookup is not 'correct' in that I have yet to even create valid nameservers, have a valid zone file or anything related to DNS. Nothing resolves yet, strictly IP only, by choice for the time being.

I'm pretty sure once I move on to DNS I need to get the provider to do something for me for working reverse IP functionality.

RE: known_hosts : it does have the IP "[xx.xx.xx.xx]:<port>" before ssh-rsa -- Deleting up to the ssh-rsa could remove the panic? Nevermind.. I tried that and surprise, known_hosts file wants the host in there with the key. hehe -- repeating the connection prompts about the FP, confirmation and add the host + key string back into the known_hosts file..

Seems like the SCP transfer wouldn't use known_hosts though..? Seems to be more like the key arrangement between PuTTY and either box, using authorized_keys[2] ? ..where there apparently isn't any [host : port] preclude to the 'ssh-rsa|dss' key start.
 
Last edited:
I managed to get a mimic of the command line sysbk constructs working with a basic test.

This is also with an alternate port using the id_dsa & id_dsa.pub key pair that DA install creates and places into /root/.ssh upon installation.

With a few modifications to the script and a little tweak to the DA skin on the system backup page this really could be easy IMO.

I looked at the reseller back and guess all other remote transfer options are classic FTP with the ncFTP that is installed.

I know classic FTP is a widely available protocol, sort of like export to CVS, however I am surprised that given scp and openssh are installed with DA that there is no use of them for the non-sysbk remote scp and sftp transfers. Then again I kind of find certificate implementation a bother. Will surly bother with them for http and smtp/pop/imap but what else is there..

Anyhow after I iron out the wrinkles and make more comment on this, I'll try to get a sort of how-to together for anyone who might want to use this feature or those who gave up on it in the past.

Ultimately it seems sort a of forgotten DA feature. Maybe the historical discussions simply rolled off into the archives..

Either way, I'll take scp & dsa over classic ftp.
 
BTW, it appears that saving the system backup configuration reconstitutes a new conf.sysbk file populated with the DA field data.

Took me few mins figuring out why scp stopped working for me before I noticed the variable I added was no longer in there, thus the modified internals.sysbk was left hanging. :-)

I searched around but only came up with the sysbk.tar as the possible source of these newly created & populated conf.sysbk files..

Seems I have two possible options:

- limit modifications to the internals.sysbk file
- replace the conf.sysbak in the tar file with my version

..or, maybe a port field + variable added at JBMC :-)

I suppose non-standard port numbers can't hide for ever but nonetheless it does seem like port selection in DA was skipped on the sysbk.
 
Thanks for the feedback.

FYI, the conf.sysbk does have a template, so if you want to customize it, run the following
Code: 
cd /usr/local/directadmin/data/templates/custom
cp ../conf.sysbk .
and DA will use that one instead.

The main reason that Sysbk doesn't get as much attention is that it doesn't come with a one-click restore.
It is powerful in it's own way, very flexible for paths, etc, so improvements can be considered for future versions.

John
 
Hi John,

I thank you for the information on the templates. I will give that a try. In hindsight seems my observation on conf.sysbk reconstitution was sorta noobish. I have only known the existence of 'templates' through reading and have never looked into them at all.

Ah, well.. Trying to crash course too much at one time.

I do understand with the sysbk restore. It's an interesting package, perhaps one day I will try to compliment it with a restore counterpart.
 
You must log in or register to reply here.
Back
Top