При записи данных в файл через SSH возникает ошибка разрешения, даже при использовании sudo

Когда вы запускаете команду типа

sudo echo some text > file

перенаправление выполняется вашей оболочкой от имени обычного пользователя перед запуском sudo.

Редактировать, отвечая на комментарий:

Оболочка не рассматривает sudoкак что-то особенное по сравнению с другими командами, и она не знает, что sudoбудет выполняться с повышенными привилегиями.

Поведение оболочки будет таким же, как и при

/bin/echo some text > file

Когда оболочка анализирует одну из приведенных выше командных строк, она находит перенаправление. Таким образом, он сначала откроет файл, затем forkпроцесс для выполнения программы, dupдескриптор файла для stdoutи execпрограмму. Затем запускается либо /bin/echo, либо sudoс уже перенаправленным stdout.

В вашем случае открыть файл для перенаправления не удастся от имени обычного пользователя.

Попробуйте что-нибудь вроде

echo '*/1 * * * *' $BACKUP_USER /home/$BACKUP_USER/bin/$SCRIPT_NAME | sudo tee /etc/cron.d/discourse-backup >/dev/null

В этом случае файл является аргументом командной строки для sudo, который будет работать как root, а затем передать аргумент имени файла в tee, который затем будет выполняться с повышенными привилегиями. Это позволит teeоткрыть файл для записи.

2-е редактирование:Этот ответ был сосредоточен на решении проблемы, связанной с sudo, и перенаправлении, а не на других возможных проблемах. Как упомянул пользователь cas в комментарии, переменные должны быть заключены в кавычки либо по отдельности, либо как вся строка, например.

echo "*/1 * * * * $BACKUP_USER /home/$BACKUP_USER/bin/$SCRIPT_NAME"  | sudo...

В случае использования вопроса цитирование может быть менее важным по двум причинам. Аргументы используются только для echo, а вывод должен быть допустимой строкой crontab. Это в любом случае запрещает несколько «проблемных» символов в переменных. Но в целом всегда рекомендуется правильное цитирование.

Поскольку эта команда будет частью более длинной строки в кавычках, кавычки можно экранировать, например.

ssh -i./ssh-key user@server "
   ...
    echo \"*/1 * * * * $BACKUP_USER /home/$BACKUP_USER/bin/$SCRIPT_NAME\" | sudo... "

Как объяснил @Bodo, проблема заключается в том, что локальная оболочка интерпретирует метасимволы [в данном случае '>'] перед отправкой строки через ssh на удаленный хост.

Альтернативой использованию команды 'tee' является простое экранирование оскорбительного метасимвола обратной -косой чертой '\' [символом '>' или любой другой метапоследовательностью, например. '>>', '$1', '*'и т. д.], чтобы у вас было что-то вроде:

sudo echo '*/1 * * * *' $BACKUP_USER /home/$BACKUP_USER/bin/$SCRIPT_NAME \> /etc/cron.d/discourse-backup

Я также хотел бы отметить, что причина, по которой символы ' *' в операторе echo не создавали проблем, заключается в том, что они заключены в жесткую пару (одинарных )кавычек для запрета работы оболочки. расширение, которое в противном случае произошло бы локально.

Также обратите внимание, что в этом примере среды $BACKUP _USER и $SCRIPT определены локально, а не в удаленной системе. Если вы хотите использовать какие-либо среды, определенные в удаленной системе, вам нужно экранировать символ «$».

Краткое практическое правило. :Если передаваемая строка не заключена в кавычки или заключена в мягкие (двойные )кавычки, может потребоваться экранирование метапоследовательности. Если это в жестких (одинарных )кавычках экранирование обычно не требуется

Все это предполагает, что у вас есть права на запись в целевой файл. Если вы этого не сделаете, в качестве альтернативы можно использовать команду «tee», как объяснил @Bobo, или создать файл в месте, на которое у вас есть права, а затем переместить («mv» )на место.