Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

sphen

Member

Registered: 2020-06-13

Posts: 45

Trial of DC 1.1.1.2?

I am testing out DC on my pre-ESXi 7.0 hypervisor. I am getting this error:

SIGTERM (13) condition was trapped: check logs for more details

but the logs dont show anything. in researching the release history is this because the trial link provides v1.3.0.1? Is there a way to get the compatible 1.1.1.2 version for testing?

Thanks.

admin

Administrator

Registered: 2017-04-21

Posts: 2,072

Re: Trial of DC 1.1.1.2?

Only 1.3 branch is compatible with ESXi 7.0
Post your backup job and output, otherwise we are just guessing
You may receive that error on a full remote volume, some typo in the remote path, lack of permissions to write, etc..
Look for the log files in the remote end. Depending on the type of remote server ESXi or Linux, you will find them in <install-root>/var/log/ /var/log/xsi/. Then check the error.log file: tail -n30 error.log

sphen

Member

Registered: 2020-06-13

Posts: 45

Re: Trial of DC 1.1.1.2?

Thanks. I am testing between ESXi 6.7 and a remote synology over ssh. The synology is set with ssh/keys etc and i am able to auth as root. The xsibackup binary is in /usr/bin on the synology with execute permissions. Destination directory should be good as we are logging in as root and permissions are good.

The only things in error.log locally or remote are from previous runs with obvious errors.

The command I am running:

./xsibackup --replica "VMs(Radius)" root@X.X.X.X:22:/volume1/backup --compress

At the destination under /volume1/backup it creates the folder for the VM as well as an empty .map folder within. No other files are present.

The output of the command:

|---------------------------------------------------------------------------------|
||-------------------------------------------------------------------------------||
|||   (c)XSIBackup-DC 1.3.0.1: Backup & Replication Software                    |||
|||   (c)33HOPS, Sistemas de Informacion y Redes, S.L. | All Rights Reserved    |||
||-------------------------------------------------------------------------------||
|---------------------------------------------------------------------------------|
                   (c)Daniel J. Garcia Fidalgo | info@33hops.com
|---------------------------------------------------------------------------------|
System Information: ESXi, Kernel 6 Major 7 Minor 0 Patch 0
-----------------------------------------------------------------------------------------------------------
License: unlicensed trial version
-----------------------------------------------------------------------------------------------------------
SSH: Sat Jun 13 17:03:27 EDT 2020
-----------------------------------------------------------------------------------------------------------
Remote system: linux
-----------------------------------------------------------------------------------------------------------
PID: 2100055, Running job as: root
-----------------------------------------------------------------------------------------------------------
(c)XSIBackup-DC replicating data to /volume1/vertical
-----------------------------------------------------------------------------------------------------------
Unknown cipher type 'aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc'
Skipping invalid VM '13'
Skipping invalid VM '13'
New backup/replica: Radius | folder
-----------------------------------------------------------------------------------------------------------
Backup start date: 2020-06-13 21:14:44
-----------------------------------------------------------------------------------------------------------
2020-06-13 21:14:44 | Backing up 15 files, total size is 64425637988
-----------------------------------------------------------------------------------------------------------
    NUMBER	                                                   FILE             SIZE       PROGRESS
-----------------------------------------------------------------------------------------------------------
     1/15                                              Radius-flat.vmdk         60.00 GB | Done   0.00%
-----------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------

SIGTERM (13) condition was trapped: check logs for more details
-----------------------------------------------------------------------------------------------------------
Cleaning up...
-----------------------------------------------------------------------------------------------------------
Removed <tmp> dir        OK
-----------------------------------------------------------------------------------------------------------
Unlocked backup          OK
-----------------------------------------------------------------------------------------------------------
Removed PID              OK
-----------------------------------------------------------------------------------------------------------

Thank you for your help! Wish the logs actually said something.

admin

Administrator

Registered: 2017-04-21

Posts: 2,072

Re: Trial of DC 1.1.1.2?

Please, note that since some recent update in (c)Synology DSM, only root user is allowed to login via SSH.

Apart from other minor details that we see (--compress argument does not exist, it is [b]--compression[/b] and that feature is applied by default, so there's no need for it), you are clearly receiving a message stating all you need to know:

Unknown cipher type 'aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc'

OpenSSH is letting you know it can't negotiate a cipher.

Most people assume things work in a given way, it might be logical that they believe they should be like that, the problem comes when they are viscerally closed to accept they might work in a different way. We aren't stating that it is your case, just uncovering a key general principle.

The thing is that OpenSSH DOES NOT work the way most people assume it does or it should. We won't enter into why OpenSSH developers arrange things in that way, they do some really awkward things, nonetheless that's the way it is, and going against reality is not a good idea.

So, if just a single cipher in the list of user proposed ciphers fails, you will receive that message and the tunnel will drop. Things work differently when ciphers are autonegotiated, (c)XSIBackup-DC allows the user to set ciphers though.

The default set of user ciphers are set in the [b]xsibackup.conf[/b] file into the ./etc directory, you may tweak that to your needs or you may use the [b]--ssh-ciphers[/b] argument, which will allow to set that per backup job.

You can get a list of available ciphers in each side of the SSH tunnel by running

ssh -Q cipher

Now you can use one or more of the commonly available ciphers in your (c)XSIBackup-DC job.

[b]/!\ Keep on reading[/b]. Still the thing does not end there though, as ciphers' use can also be controlled in the /etc/ssh/sshd_config file in your Synology NAS, or eventually any other Linux device, thus you may still be rejected your user cipher even though it is present in the list of available ones. This is general behaviour and, as stated, can be extended to any Linux OpenSSH enabled host.

Even if you see that the output of [b]ssh -Q cipher[/b] is:

3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

And the Cipher configuration in your /etc/ssh/sshd_config file is:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc

If you try to use [b]chacha20-poly1305@openssh.com[/b]

You will receive SEGFAULT 13 (broken pipe) and if you increase the level of verbosity in [b](c)XSIBackup-DC[/b] to maximum (--verbosity=10), you will still see this:

SSH Out: unable to negotiate with 192.168.3.90 port 22: no matching cipher found. their offer: aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc

The solution is simple: add [b]chacha20-poly1305@openssh.com[/b] to the list of allowed ciphers in the [b]sshd_config[/b] file

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc,chacha20-poly1305@openssh.com

Our experience is that [b](c)XSIBackup-DC[/b] will work with the default set of ciphers up until our DMS reference version

root@NAS01:~# more /etc.defaults/VERSION
majorversion="6"
minorversion="2"
productversion="6.2.1"
buildphase="GM"
buildnumber="23824"
smallfixnumber="0"
packing="iSCSI"
packing_id="1"
builddate="2018/09/07"
buildtime="16:57:11"

sphen

Member

Registered: 2020-06-13

Posts: 45

Re: Trial of DC 1.1.1.2?

Thank you for the direction. Thanks for pointing out the config file under ./etc as that looks very useful as well.

I was able to get it to start by tweaking the ssh ciphers as stated. Interestingly enough, the synology is not the issue in my case but the ESXi host. When running

ssh -Q cipher

on the ESXi host, it is missing

blowfish-cbc
cast128-cbc

as well as:

chacha20-poly1305@openssh.com

These ciphers are all present on the Synology. I found another thread on the forum stating that you found that chacha20-poly1305@openssh.com is unavailable in ESXi 6.7 which is what my test host is running.  Either way, defining a compatible set it working now, and this is over a WAN connection so we should be good. Thank you.

admin

Administrator

Registered: 2017-04-21

Posts: 2,072

Re: Trial of DC 1.1.1.2?

Thank you for the feedback, we will be easing ssh cipher management in next version, as per the current version 1.3.0.1 curstom ciphers are only employed for file transfer, which may lead to apparently contradictory outcomes in some cases. Since 1.3.0.2 user ciphers will be used in every SSH communication to unify all inner SSH operations.