Почему этот rsync + ssh задание крона, дающее мне 'Разрешение, отклоненное в ' ошибках (с открытым ключом)?

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

rm ~/.ssh/known_hosts

Это стоит попробовать, поскольку ssh восстановит его, и Вы избавитесь от устаревшего материала. Можно, конечно, также удалить части, принадлежащие данному IP / Хост.

Используйте 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 для удаленного техобслуживания.

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

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

, Но я читал сообщение, которое объяснило, что crontab имеет свою собственную среду, которая не является тем же как корнем. Я уже знал, что, но я не понял влияние, которое это могло оказать на SSH при использовании SSH-АГЕНТА

, Но мои ключевые обмены 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 / регистрируются / check_connexion.log 2> & 1 или использование команда "источник/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 будет использовать локальный (переданный) ключ, а не тот на сервере.

Конкретный пример: у Меня есть сценарий на dev сервере, который вытягивает в данных из "сервера данных" с помощью rsync по ssh. Когда я вхожу в dev сервер и выполняю его, все хорошо, но при выполнении от крона, я отклонил разрешение. При добавлении некоторого многословия к процессу 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.