We are backing up the Publishers config via sftp (ssh) to a Unix server with ssh running.
Looking at the CallManager logs - we are getting consistent failures, then succeses at connecting via ssh to the backup server.
Detail from the Unix server:
Feb 3 02:00:00 admnpr01 ssh-server-g3: 701 Auth_method_failure, Username: callmgr, Auth method: publickey, Session-Id: 6BF68A81CC5DC02752471F14BF4D97CEF5C5B403
Feb 3 02:00:01 admnpr01 ssh-server-g3: 723 Keyboard_interactive_password_auth_error, Username: callmgr, Algorithm: password, "Could not exchange kbdint messages.", Session-Id: 6BF68A81CC5DC02752471F14BF4D97CEF5C5B403
Feb 3 02:00:01 admnpr01 ssh-server-g3: 723 Keyboard_interactive_password_auth_error, Username: callmgr, Algorithm: password, "Authentication failed for user `callmgr'.", Session-Id: 6BF68A81CC5DC02752471F14BF4D97CEF5C5B403
Detail from the logs which shows faiklures (f) and successes (s):
start key kbi fail kbi success login failure end copy
6BF68A81CC5DC02752471F14BF4D97CEF5C5B403 02:00:00 02:00:00 02:00:01 02:00:03 f
2359534D645D04D8A69B28F2421B53F5041BB8E3 02:00:01 02:00:02 02:00:03 s
27F3D091381898908F1DAD7DF81F25E33431B864 02:00:03 02:00:03 02:00:04 02:00:06 f
497C6EDFD6738EBB0F5A2D68E38FB990114060F7 02:00:04 02:00:05 02:00:06 s
As best i can tell, CUCM is trying to use a key to authenticate (fails) then tries kbi (Keyboard Interface) and fails. Then it trys kbi again and manages to successfully connect.... :o)
Can anyone shed light on what the default 6.1(2) backup tries to do? I thought it only used ssh with a username/password that we have set from the Backup GUI. The Unix sftp server logs would suggest it is trying a key, then username password, then username password again ?
Any ideas appreciated. 5 unsuccessful logins in a row lock the account on the sftp server - doh!