Ubuntu 22.04 LTS and CUCM 10.5.2 unable to set up a sftp connection

[floatingpurr]

After setting-up an sftp server on Ubuntu 22.04 LTS following this guide 

https://www.digitalocean.com/community/tutorials/how-to-enable-sftp-without-shell-access-on-ubuntu-20-04

I can't connect to it from CUCM 10.5.2. Here is the log

admin:file get tftp Ringlist.xml
Please wait while the system is gathering files info ...done.
Sub-directories were not traversed.
Number of files affected: 1
Total size in Bytes: 2657
Total size in Kbytes: 2.5947266
Would you like to proceed [y/n]? y
SFTP server IP: 192.168.0.233
SFTP server port [22]:
User ID: sftpuser
Password: ********
Download directory: ./

Could not connect to host 192.168.0.233 on port 22. Please verify SFTP settings.

Please, note that such a server works properly with common clients (e.g., the sftp command, win scp )

I have already tried to add the following settings to sshd_config:

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

Ciphers +aes128-cbc
Ciphers +3des-cbc

but with no luck.

How can I fix that?

[TechLvr]

The Key Algorithms and Ciphers you are using are correct. 
The problem is that CUCM 10.5.2 does not seem to work with Ubuntu or other many other SFTP servers. 
I recently had to deal with the exact same issue on CUCM 10.5.2. I tried the same algorithms on Ubuntu 14.06, 16.06, and 22.04 without any luck. 

My solution was to use Cisco Prime Collaboration Deployment version 10.5.2 as SFTP. This software requires NO licenses.
Use link below for detailed instructions and how to set up the SFTP. 
https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/prime-collaboration/215541-use-prime-collaboration-deployment-as-a.html

Be sure to install PCD version 10.5.2 if you go that route. I initially tired with PCD 12.5 but it did NOT work either.
Here is the link to download PCD.
https://software.cisco.com/download/home/285963825/type/286287305/release/10.5(2) 

I tried many other STFP servers besides Ubuntu without success so I hope this post will help you. 

[floatingpurr]

Hi @TechLvr, thanx for sharing your experience and your hints. According to these threads:

• https://community.cisco.com/t5/unified-communications-infrastructure/cucm-sftp-backup-to-linux-fail/td-p/2805926
• https://supportforums.cisco.com/discussion/12407216/cucm-backup-openssh 

It works, if you configure your sftp following the needs of the CUCM. I'm looking for it. 

[Jonathan Schulenberg]

The frustrating problem is that even if you can get an SFTP server other than PCD to work (which is just running OpenSSH, like any other GNU/Linux distro), it won’t be supported by TAC. Cisco used to support TitanFTP (commercial Windows app), Cygwin, and OpenSSH but they changed a few years ago to only supporting PCD. I do not believe they specified why publicly but my hypothesis is an internal policy between TAC and the BU: the latter is required to certify a specific product, not merely a protocol for the former to support it. This is why CCX doesn’t support IMAP4/SMTP generally but only specific versions of Exchange or G Suite.

This is important because DRS does not checksum the the backup on the SFTP server after uploading it. I have seen a 3rd-party SFTP server corrupt the backup, seemingly cut off the upload early, rendering it unusable; DRS marked the backup as successful though.

IMO this is not an area to color outside the lines. Unfortunately that means you should stick with PCD.

[floatingpurr · Accepted solution]

This fixed for Ubuntu 22.04 LTS and CUCM 10.5.2:

Ciphers +aes128-cbc,aes256-cbc,3des-cbc
KexAlgorithms +diffie-hellman-group14-sha1
HostkeyAlgorithms +ssh-rsa
# If you authenticate using a keypair:
PubkeyAcceptedAlgorithms +ssh-rsa

 Thanks to @Jonathan Schulenberg for his caveat. If DRS doesn't checksum upon uploading files, a backup can be corrupted on any sftp server, even the one bundled with PCD. Am I correct?

[Jonathan Schulenberg]

Correct. Using PCD just gives you a degree of CYA if something goes wrong; Cisco can't tell your boss that it's implicitly your fault for doing something they didn't test or support. Ah, politics.

Ultimately the only way to know any backup strategy is actually working is to test the restore process periodically, usually in an island/isolated environment. It's astounding how few customers actually go to the trouble, or perhaps I should say have time/personnel to go to the trouble though.