CUCM and UCCX Backup Using DRS with Cygwin

Mark H · ‎11-25-2014

Hi everyone,

I'm attempting to have our CUCM and UCCX 8.5 installations back up to a Cygwin SSH/SFTP but unfortunately it's failing to add the server. It appears to me it's having issues with the encryption negotiation. The server works fine using FileZilla and other SFTP clients, even MeetingPlace 8.5 is archiving to the server fine.

Can anyone share some suggestions on solutions to this?

Here is the error from the master agent log:

2014-11-26 12:48:49,261 DEBUG [NetServerWorker] - drfNetServerWorker.drfNetServerWorker: Socket Object OutputStream to be created
2014-11-26 12:48:49,262 ERROR [NetServerWorker] - drfNetServerWorker.drfNetServerWorker: Unable to create input/output stream to client Received fatal alert: internal_error
2014-11-26 12:48:53,898 DEBUG [NetMessageDispatch] - drfMessageValidator.validateMessage(): Starting introspection for Message ID = 3200 Message Body =
  ========== BEGIN msgSubUpdateDestination_REQ ==========
  devicepath     : /
  devicetype      : NETWORK
  hostname  : ucb002.domain.local
  m_iBackupSetCount : 2
  password : hashedpasswordhere
  storagelocationname  : ucb002
  username   : username
  version : 1.0.0
  schedules : []
  ========== END msgSubUpdateDestination_REQ ==========
2014-11-26 12:48:53,898 INFO [NetMessageDispatch] - drfMessageReceiver::HandleMessage: Message ID3200 has been validated successfully
2014-11-26 12:48:53,898 DEBUG [NetMessageDispatch] - drfMessageHandler:HandleUpdateDestination: Received update destination request for the NETWORK Device.
2014-11-26 12:48:53,898 DEBUG [NetMessageDispatch] - drfMessageHandler:HandleUpdateDestination: Adding a new Device location: ucb002
2014-11-26 12:48:53,898 DEBUG [NetMessageDispatch] - drfMessageHandler:HandleUpdateDestination: The total number of configured Devices (pre update):1
2014-11-26 12:48:53,899 INFO [NetMessageDispatch] - Entering decryptPassword
2014-11-26 12:48:53,899 INFO [NetMessageDispatch] - decryptPassword was successful
2014-11-26 12:48:53,899 DEBUG [NetMessageDispatch] - drfMessageHandler:HandleUpdateDestination: Check whether SFTP is accessible.
2014-11-26 12:48:53,899 INFO [NetMessageDispatch] - Entering decryptPassword
2014-11-26 12:48:53,899 INFO [NetMessageDispatch] - decryptPassword was successful
2014-11-26 12:48:53,899 DEBUG [NetMessageDispatch] - drfUtils:getSshClient: Set sftp timeout of 60000 milliseconds
2014-11-26 12:48:54,018 DEBUG [NetMessageDispatch] - drfUtils:getSshClient: Send and Received Buff Sizes = 65535
2014-11-26 12:48:54,281 ERROR [NetMessageDispatch] - drfUtils:getSshClient: Message -> com.maverick.ssh.SshException: Failed to negotiate a transport component [arcfour256] [chacha20-poly1305@openssh.com] [Unknown cause]
2014-11-26 12:48:54,281 ERROR [NetMessageDispatch] - drfUtils:isSftpLocationAccessible: Error . Failed to create Ssh connection to device, stdErr: null
2014-11-26 12:48:54,281 ERROR [NetMessageDispatch] - drfMessageHandler:HandleUpdateDestination: Error - unable to access sftp server, stdErr: Unable to access SFTP server or SFTP server too slow to respond.
2014-11-26 12:48:54,282 DEBUG [NetMessageDispatch] - drfAlarm:sendAlarm: Sending Alarm: DRFSftpFailure
2014-11-26 12:48:54,282 DEBUG [NetMessageDispatch] - drfAlarm:sendAlarm: Alarm: DRFSftpFailure return = 0
2014-11-26 12:48:54,282 DEBUG [NetMessageDispatch] - drfAlarm:sendGenericAlarm: Sending Generic Alarm: DRFFailure
2014-11-26 12:48:54,282 DEBUG [NetMessageDispatch] - drfAlarm:sendGenericAlarm: Generic Alarm: DRFFailure return = 0
2014-11-26 12:48:54,282 DEBUG [NetMessageDispatch] - HandleUpdateDestination: Update destination response sent

Mark H · ‎12-10-2014

This was caused by later versions of OpenSSH disabling some weaker ciphers, I was able to resolve the issue by enabling all ciphers.

The instructions I used are found here.

Jason McDonald · ‎06-11-2015

Per the Cisco document linked below;

For Cygwin to function properly as your backup SFTP server, you must add the following lines to the sshd_config file:

The cipher key: ciphers aes128-cbc

The Unified Communications Algorithm: KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/drs/10_0_1/CUCM_BK_D220A91D_00_disaster-recovery-system-cucm-100/CUCM_BK_D220A91D_00_disaster-recovery-system-cucm-100_chapter_01.pdf