Почему эта работа 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
Источник

8 ответов

Решение

Так как все работает нормально из командной строки, ошибка 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. Я создам тот же сценарий через пару дней, чтобы проверить его и доложить.

Источник

Немного опоздал на вечеринку, но у меня была та же проблема. Локальный пользователь crontab -lпоказал мою ежедневную задачу резервного копирования:

        0   5   *    *    5    /repos/local-bin/backup-backups daily-6

Работал, когда я позвонил /repos/local-bin/backup-backups daily-6напрямую. Работал, когда я назвал базовый rsyncкоманда само собой. Сработало, когда я вошел в системы, которые пытался создать резервную копию. показал, что в агенте/связке ключей моей среды ключи, которые мне нужны, хранятся должным образом и легко доступны.

Итак, следуя совету основного ответа, я добавил в /repos/local-bin/backup-backups, немедленно запустил задачу cron, скопировал вывод из env, добавил перед каждой строкой, открыл новый терминал, запустил env -i sh, и вставил exportкоманды в него. Затем я запустил свой sshкоманда от ранее, и это не удалось. Окончательно! Я заметил, что среда cron получала pid для агента ssh, поэтому он должен работать...

Я запустил и увидел, что последние созданные мной SSH-ключи не были добавлены в агент/связку ключей этой среды... но некоторые из моих других ключей были добавлены?? Что странно, потому что он работал с агентом, который я использовал вне этой среды... о, подождите! Я использую кошелек/агент KDE за пределами этой среды (мой рабочий стол) и использую ssh-agent непосредственно внутри этой среды (моя терминальная среда)! Поэтому я нажал Ctrl+Alt+F2, чтобы выйти из KDE, запустил ssh-add -l, увидел, что в нем тоже отсутствуют нужные мне ключи, и запустил add-ssh-keysсценарий. Обычно это делается автоматически во время загрузки/входа в систему, но это были только что созданные ключи SSH, которые нужно было добавить как в мою связку ключей KDE (что я сделал правильно), так и в мой не-KDE ssh-агент (что я забыл сделать) . Надеюсь, это поможет кому-то еще избежать нескольких часов таскания за волосы :)

Источник

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

Если вы видите такое поведение при отладке скрипта на удаленном хосте, это потому, что даже при -e "ssh -i /path/to/key" flag, 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-copy-id с переадресацией агента, вам нужно указать, какой ключ устанавливать с флагом -i: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host,

Источник

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

Невозможно соединиться в 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 работает без каких-либо проблем.

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

Источник

Вы уже попробовали старый трюк очистки файлов 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 для дистанционного обслуживания.

Источник
Другие вопросы по тегам