Почему эта работа rsync + ssh cron выдает ошибки «Отказано в доступе (publickey)»?

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

Целевой сервер настроен только для доступа по ключу SSH (без пароля). Так как мой основной SSH-ключ для этого сервера защищен парольной фразой, я создал второй SSH-ключ (не защищенный парольной фразой) + пользователь, который будет использоваться для автоматического резервного копирования - таким образом, мне не нужно присутствовать, чтобы вводить мою парольную фразу при запуске cron ,

Я использую cron и rsync, и все команды работают по отдельности, но не срабатывают при объединении.

Самое дальнее, что у меня есть, пока идет поиск неисправностей

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/"

который возвращает ошибку

Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.0]

Любые советы о том, как решить эту проблему дальше?

Вот что я пробовал до сих пор, и у меня нет идей:

1. Крон определенно бежит ps aux | grep cron

2. Ничего необычного в / var / log / syslog Sep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

3. SSH в терминале к удаленному серверу в качестве резервного пользователя ssh backups-user@XX.XX.XX.XX

4. Запуск команды в Терминале работает отлично rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

5. Указание пути к пользовательскому ключу резервного копирования вручную не имеет никакого эффекта rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

6. Замена неработающей команды простой тестовой командой работает echo "Hello world" > ~/Desktop/test.txt

7. Крики / ругательства на компьютере не имели никакого эффекта (но я временно почувствовал себя лучше).

Изменить 1:

Вот мой файл crontab и скрипт, который он вызывает.

...
# m h  dom mon dow   command
MAILTO=""
* * * * * sh /home/tom/Documents/Scripts/offsite-backup

и

#!/bin/bash

rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

Изменить 2:

Просто для пояснения, /var/log/auth.logна целевом сервере есть строка. Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootЭто сбивает с толку, потому что я больше не запускаю cron каждую минуту локально, но новая запись по-прежнему появляется каждую минуту в журналах сервера. Файлы Crontab для всех пользователей (включая root) на сервере пусты и ничего не делают.

Кроме того, пользователь «только резервные копии» был создан только на сервере и с ограниченными правами, с выделенным ключом SSH, скопированным на мой настольный компьютер. Я предполагаю, что это путь, потому что все работает при запуске команд вручную.

Выложенный выше файл crontab предназначен для меня, пользователь 'tom' на моем настольном компьютере. Я хочу, чтобы он вызывал скрипт, который должен входить на сервер как пользователь «только для резервного копирования». Я просто попытался запустить скрипт резервного копирования (а не команду внутри него), и он успешно подключился и работал. Я запустил его на своем рабочем столе как пользователь 'Tom', тот же самый пользователь, который создал работу cron, которая не будет работать. Вот вывод из журнала сервера, соответствующий этому успешному входу в систему

Sep 11 08:35:31 <hostname> sshd[25071]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Sep 11 08:35:32 <hostname> sshd[25071]: Accepted publickey for backups-only from <desktop IP> port 54242 ssh2: RSA e2:e6:07:27:c1:continues...
Sep 11 08:35:32 <hostname> sshd[25071]: pam_unix(sshd:session): session opened for user backups-only by (uid=0)
Sep 11 08:35:32 <hostname> systemd-logind[638]: New session 12 of user backups-only.
Sep 11 08:36:00 <hostname> sshd[25133]: Received disconnect from <desktop IP>: 11: disconnected by user
Sep 11 08:36:00 <hostname> sshd[25071]: pam_unix(sshd:session): session closed for user backups-only

Поскольку все работает нормально из командной строки, ошибка Permission denied (publickey)означает, что часть SSH rsyncиспользует файл идентификации, отличный от указанного имени пользователя.

Из комментария Яна к исходному вопросу мы можем указать файл идентификации в rsyncкоманде, используя -e 'ssh -i /path/to/identity.file' ....

Использование приведенной ниже команды для запуска новой среды в cron и указание полного пути к файлу, по-видимому, решает проблему:

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/"

_{Я все еще очень заинтересован в этом открытии. Вероятно, это связано с cron, тем, что он начинается с минимальных переменных среды, и с ssh-agent. Я создам тот же сценарий через пару дней, чтобы проверить его и доложить.}

Я только что решил эту проблему, которая держала меня занятым ..

Невозможно соединиться в RSYNC через SSH, несмотря на то, что указана идентификационная информация для SSH ... Ничего не сделано ... Rsync говорит "отказано в разрешении" и ssh сообщает мне "read_passphrase: не удается открыть / dev / tty: нет устройства или адреса этот тип"

Но я прочитал пост, в котором объясняется, что у crontab есть свое собственное окружение, отличное от root. Я уже знал это, но я не понимал, какое влияние это может оказать на SSH при использовании SSH-AGENT.

Но мой обмен ключами SSH выполняется с помощью PassPhrase ... поэтому, если среда отличается, и мой RSYNC через SSH ожидает парольную фразу, которая не может быть введена => Информация отладки SSH также указывает на ошибку:

"debug1: read_passphrase: не могу открыть / dev / tty: нет такого устройства или адреса" => Ну да нет TTY = нет парольной фразы = не разрешено

На моей машине я использую «связку ключей» для запуска агента SSH, поэтому мне не нужно повторно вводить фразу-пароль каждый раз, когда я пытаюсь выполнить удаленное соединение. Цепочка для ключей генерирует файл, который содержит следующую информацию

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent.18891; экспорт SSH_AUTH_SOCK; SSH_AGENT_PID = 18893; экспортировать SSH_AGENT_PID;

==> Команда SSH-AGENT возвращает ту же информацию.

Итак, в конце концов, именно эта информация, относящаяся к текущему сеансу, позволяет в будущем выполнять аутентификацию текущего сеанса без необходимости вводить фразу-пароль, потому что это уже сделано ранее и запомнено ...

==> Решение есть ... этого достаточно в скрипте, запущенном crontab, и "найти" файл, содержащий эту информацию, или сделать это в командной строке ds crontab ...

пример: 14 09 * * *. /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh foo@my-server.fr:. >> / var / log / check_connexion.log 2> & 1 или используйте команду «source /home/foo/keychain/foo.server.org-sh» в сценарии, который запускает соединение с использованием SSH.

=> С этим источником, больше не беспокойтесь. Информация о SSH_AUTH_SOCK и SSH_AGENT_PID загружается в среде Crontab и поэтому известна, RSYNC через SSH работает без каких-либо проблем.

Это занимало меня, но теперь это работает :)

Предостережение для тех, кто использует SSH Agent Forwarding:

Если вы видите такое поведение при отладке скрипта на удаленном хосте, это потому, что даже с -e "ssh -i /path/to/key"флагом ssh будет использовать ваш локальный (переадресованный) ключ, а не ключ на сервере.

Конкретный пример: у меня есть скрипт на сервере dev, который извлекает данные с «сервера данных», используя rsync через ssh. Когда я захожу на сервер dev и запускаю его, все хорошо, но при запуске из cron я получаю отказано в разрешении. Добавляя некоторую многословность процессу SSH (флаг -vv), я заметил следующее:

debug2: key: /home/nighty/.ssh/id_rsa (0x562d8b974820),
debug2: key: /home/juanr/.ssh/id_rsa (0x562d8b962930), explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/nighty/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 1a:19:08:9f:80:16:b1:db:55:42:9a:52:b2:49:9b:0a
debug1: Authentication succeeded (publickey).

Что меня здесь прояснило, так это то, что по чистой случайности у меня на локальном хосте другое имя пользователя («спокойное»), чем на сервере dev («juanr»).

Обратите внимание на то, как он помечает ключ на сервере dev как «явный», но все еще использует переадресованный ключ с моего ноутбука для входа в систему. Выполнение ssh-copy-idв этот момент ничего не решает, поскольку он просто переустанавливает переадресованный ключ, а не тот из dev сервер. Если вы используете SSH-копии идентификатор с пересылкой агента, вам нужно указать , какой ключ для установки с флагом -i: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

Вы уже попробовали старый трюк очистки файлов hosts? Я имею в виду:

rm ~/.ssh/known_hosts

Стоит попробовать, так как ssh перестроит его, и вы избавитесь от устаревших вещей. Конечно, вы также можете удалить части, принадлежащие данному IP / хосту.

Дополнительные вопросы: ваша задача cron выполняется под вашим UID или она работает как пользователь cron или root?

Используйте rrsyncскрипт вместе с выделенным ключом ssh следующим образом:

Удаленный сервер

mkdir ~/bin
gunzip /usr/share/doc/rsync/scripts/rrsync.gz -c > ~/bin/rrsync
chmod +x ~/bin/rrsync

ЛОКАЛЬНЫЙ компьютер

ssh-keygen -f ~/.ssh/id_remote_backup -C "Automated remote backup"      #NO passphrase
scp ~/.ssh/id_remote_backup.pub devel@10.10.10.83:/home/devel/.ssh

УДАЛЕННЫЙ компьютер

cat id_remote_backup.pub >> authorized_keys

Добавьте к новой добавленной строке следующее

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

Так что результат выглядит

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...vp Automated remote backup

МЕСТНЫЙ

Вставьте в ваш crontabследующий скрипт с xразрешения:

#!/bin/sh
echo ""
echo ""
echo "CRON:" `date`
set -xv
rsync -e "ssh -i $HOME/.ssh/id_remote_backup" -avzP devel@10.10.10.83:/ /home/user/servidor 

Источник: http://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/

Чтобы попытаться отладить, добавьте в ssh часть "ssh -v" таким образом, вы можете получить подробный режим с некоторой полезной информацией.

Изменить: со страницы руководства:

-v      Verbose mode.  Causes ssh to print debugging messages about its progress.  This is helpful in debugging connection,
             authentication, and configuration problems.  Multiple -v options increase the verbosity.  The maximum is 3.

Я думаю, что вы не настроили файл sshd_config должным образом. Проверьте это PermitRootLogin yesи PubkeyAuthentication yes для дистанционного обслуживания.