ls -объявление */ не будет отображать скрытые каталоги

Да, сообщение похоже от remoteserverC.

Вы используете plink для подключения как testadminк linuxserverB и запускаете там скрипт с sudo -u user_a. Таким образом, скрипт будет работать как user_a@linuxserverB.

Поскольку спецификация цели scp не включает имя пользователя, команда scp, встроенная в perl-скрипт, будет пытаться подключиться к user_a@remoteserverC. По-видимому, либо неправильное имя пользователя, либо соответствующие ключи недоступны для этого (, либо в соединении доступно больше ключей, чем количество попыток аутентификации, разрешенных remoteserverC ).

Первый вопрос: имеет ли user_a@remoteserverCсмысл? Если user_aне существует на удаленном сервере C, то ваша спецификация источника копирования должна включать имя пользователя для удаленного сервера C, например some_other_user@remoteserverC.com:/a/b/c/filetocopy.txt.

Если это не решит проблему, проверьте журналы на удаленном сервере C и выясните, какие попытки аутентификации отклоняются и почему. Возможно, пользовательский файл ~/.ssh/authorized_keysнедостаточно защищен на удаленном сервере C, и в результате демон сервера sshdигнорирует список авторизованных ключей. Файл authorized_keysнужно защитить, чтобы в него мог писать только сам пользователь (или root ). Если это так, в сообщении журнала должен быть указан файл или каталог, права доступа sshdкоторого неудовлетворительны.