UCM Backup/ Disaster Recovery target not working

[GH2110]

Good afternoon, all!

I'm retiring a server that, among other things, is the SFTP target for my customer's UCM Disaster Recovery System. This is a Debian 10 server with ProFTPD as the SFTP server. I can access this using WinSCP as a client and use any of the configured FTP users and move any file I want. However, when I try to add the new Debian server as a target, UCM Disaster Recovery says

Update failed : Unable to access SFTP server. Please ensure the username and password are correct.

Needless to say, the username and passwords are correct. 

This is running over port 22 as designed. 

What might I be missing in configuring this new server?  This is the last thing to move off the old Windows server and decommission it.

Thanks to all for looking!

Gregg

[Sadav Ansari]

Hi,

1: Some time window defender and firewall services causing issue so  deactivate

This  services your machine where your SFTP server installed.

2: You may have the path wrong.  For some SFTP servers you need to specify with a leading dot for example "./CUCM", on others the path would be "/CUCM"   You could check with a command line SFTP client, connect to the server and try changing the path, see what syntax works.

3: Set the new username

 

 password on SFTP server and save and apply it, Same username password enter on your Backup device which you are using during backup you should be use correct backup device check sftp server ip and username password.

4: Try a forward slash "/" intead of the backslash "\".

Also check if you can ping this IP address from the CUCM using "utils network ping" command and also check if the SFTP server is running and configured fine.

Pls rate if its “Helpful”. If this answered your question pls click “Accept As Solution”

[GH2110]

Hello, Sadav!

No joy on any of these - I can ping the Debian server from the UCM system admin page, tried both "/" and "./" as paths, and tried three different users that work using WinSCP.  Looks like I'll have to go deeper on this!

[Nithin Eluvathingal]

I assume you are updating the  existing CUCM backup device, Try adding new SFTP  as  a new  backup device, use path asper the SFTP user. if the backup folder is your root folder  for the user, you need to use only "/". if the old and new are of same ip delete the old device and add new.

Since you are moving from windows to linux, hope this information will be useful."If you are not sure of Network Directory Path then try user home directory as "./" in case of linux sftp server".

Globalscape, Cygwin, Open SSH and Titan are the SFTP servers tested with CUCM. 

 Form the error you shared  it looks like reachability issue or provided credential are not correct . Check if you can reach the new server on port 22.

is there anything on Debian SFTP blocking CUCM ?

[GH2110]

Hello, Nithin!

Unfortunately, no joy on these.  I don't want to delete the old server as it's still active, and the new IP is reachable from the UCM servers. Also checked any firewall on Debian - no iptables or UFW on the new server.  I can reach the server on port 22 using PuTTy and WinSCP connecting with SFTP.  Looks like I'll be taking SSH apart on this server.

[Nithin Eluvathingal]

When checking how to configure ProFTPD as SFTP, I was able to see configuration asking to change listening port to 2222. Are you using 22 or 2222, if its 2222 the backup will not work.

[Roger Kallberg]

Apart from what already suggested by my peers try with a simple user name and password combination that does not contain any special characters. This is to rule out that something would be wrong with how CM sends this information to the SFTP service.

[GH2110]

Hello, Roger!

My username and password on this are strictly alphanumeric - no special characters at all.  I think I'll be disassembling SSH and packet tracing to see what's happening

[Elliot Dierksen · Accepted solution]

in sshd_config on the backup target:

KexAlgorithms +diffie-hellman-group1-sha1
KexAlgorithms +diffie-hellman-group-exchange-sha1

Ciphers +aes128-cbc
Ciphers +3des-cbc

[GH2110]

Hello, Elliot!

I added the KexAlgorithms and Ciphers directives and immediately had trouble getting SSHD to run. There may be something with the OpenBSD SSH server on this Debian box. Also will try a tCP dump to catch packets coming from the UCM servers.

Thanks!

[Elliot Dierksen]

You can try commenting those directives out one at a time. I would suggest starting with the 3des-cbc line first. It is one of the maddening things about DRS that it has particular needs for ciphers and key exchange algorithms, but it just gives you a 'general target fault' if it doesn't get what it wants. You can use RTMT to download DRS logs and see what is going one. I wrote those additions to the sshd_config file so they shouldn't(!!!) mess with what is there, and so that they could be easily commented out if need be. There should probably be something in /var/log/(whatever log file sshd is using) that should tell you what it doesn't like. I think all the more modern (as in V10.0+) will use aes128-cbc. The older ones (as in 9.0 or older) want 3des-cbc. The key exchange stuff is a bit hit or miss.

[GH2110]

Hello, Elliot!

I added these to the OpenBSD SSH daemon and was able to successfully add the new Debian server as a backup target for UCM

Thanks!