Чому ця робота 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. Cron напевно працює 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Це заплутано, оскільки я більше не щоденно виконую крон локально, але новий запис все одно з’являється щохвилини в журналах сервера. Файли 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-агента. Я буду встановлювати той самий сценарій через пару днів, щоб перевірити його та звітувати.}

Я щойно вирішив цю проблему, яка мене зайняла ..

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

Але я прочитав пост, який пояснив, що у crontab є своє середовище, яке не є коренем. Я вже це знав, але не розумів, який вплив він може мати на SSH при використанні SSH-AGENT

Але мій обмін ключами SSH проводиться за допомогою PassPhrase ... тому, якщо середовище інше, і мій RSYNC через SSH очікує парольну фразу, яку неможливо ввести => Інформація про налагодження SSH також вказує на помилку:

"debug1: read_passphrase: не можна відкрити / dev / tty: Немає такого пристрою чи адреси" => Ну так ні ні TTY = немає парольної фрази = не дозволено

На своїй машині я використовую "Keychain" для запуску агента SSH, тому мені не доведеться повторно вводити парольну фразу кожен раз, коли я пробую віддалене з'єднання. Keychain створює файл, який містить таку інформацію

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-агент для пересилання:

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

Конкретний приклад: у мене на сервері розробок є скрипт, який перетягує дані з "сервера даних", використовуючи rsync через ssh. Коли я заходжу на сервер розробників і запускаю його, все добре, але коли я запускаю з 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).

Що мене змусило тут - це те, що я випадково маю інше ім'я користувача на локальному хості ("нічний"), ніж на сервісі розробників ("juanr").

Зверніть увагу, як він позначає ключ на сервері розробників як "явний", але все ж використовує пересланий ключ з мого ноутбука для входу в систему. Виконання ssh-copy-idв цей момент нічого не вирішує, тому що він просто заново встановлює пересланий ключ, а не той, який з dev сервер. Якщо ви використовуєте SSH-копії ідентифікатор з пересилкою агента, вам потрібно вказати , який ключ для установки з прапором -i: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

Ви вже спробували стару хитрість очищення файлів хостів? Я маю на увазі:

rm ~/.ssh/known_hosts

Варто спробувати, оскільки ssh відновить його, і ви позбудетеся від черствих речей. Звичайно, ви також можете видалити частини, що належать даному IP / хосту.

Більше запитань: чи працює ваш cron під вашим UID або він працює як користувацький cron або root?

Використовуйте rrsyncсценарій разом із виділеним ключем ssh наступним чином:

REMOTE-сервер

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 віддаленому обслуговуванні.