Linux rsync без пароля

Как настроить команду rsync без пароля в Linux

Утилита rsync (удаленная синхронизация) копирует обычную иерархию файлов или каталогов локально или из локальной системы в другую систему в сети или из нее.

По умолчанию эта утилита использует OpenSSH для передачи файлов и тот же механизм аутентификации, что и OpenSSH; следовательно, она обеспечивает ту же безопасность, что и OpenSSH.

Утилита rsync запрашивает пароль, когда он ему нужен.

Хотя иногда вы не хотите, чтобы rsync запрашивал пароль.

Например, если вы хотите, чтобы задание rsync было запланировано в crontab, необходимо выполнить операцию rsync без пароля.

Существует два способа использования rsync без запроса пароля:

1. используйте переменную окружения RSYNC_PASSWORD
2. –password-file option.

1. Метод с использованием переменной среды

1. В этом методе мы устанавливаем переменную окружения RSYNC_PASSWORD перед использованием команды rsync.

Здесь «secret» – используемый пароль.

Теперь вы можете использовать команду rsync, и она больше не должна запрашивать пароль.

Вы также можете экспортировать переменную RSYNC_PASSWORD в скрипт, если хотите.

Но убедитесь, что скрипт доступен для чтения только вам, а не кому-либо еще.

2. Другой способ – указать переменную окружения RSYNC_PASSWORD в самой команде rsync.

2. Метод с использованием опции –password-file

1. В этом методе мы создаем файл паролей, как показано ниже.

Убедитесь, что файл паролей не доступен для чтения всем пользователям (имеет разрешение 600).

2. Теперь запустите команду rsync с параметром –password-file и укажите файл пароля, который вы только что создали.

Для получения дополнительной информации см. Страницу руководства для rsync с:

Источник

eCommerce и не только

AddThis Smart Layers

воскресенье, 24 января 2016 г.

Настройка репликации rsync по SSH без пароля

При работе с кластерами часто необходимо делать синхронизацию файлов (репликацию) при помощи команды rsync.
Другим примером использования данной команды будет перенос файлов с одного сервера на другой при апгрейде или для создания резервных копий данных.

Если при одноразовом использовании rsync чаще всего вопросов нет, то при автоматизации процесса репликации возникает проблема авторизации.
Ведь при репликации файлов между серверами при помощи команды rsync мы устанавливаем соединение с удаленным сервером и каждый раз будет затребован пароль для идентификации пользователя.
Нам же нужно автоматизировать выполнение команды так, чтобы пароль не требовался, но при этом ни в коем случае нельзя нигде хранить пароль в текстовом виде.

В общем виде команда для репликации файлов будет выглядеть так:

При помощи команды выше мы синхронизируем содержимое пользовательской директории /home/user/ на локальном сервере в идентичную директорию на сервере 192.168.0.2, при этом мы должны идентифицироваться под пользователем [email protected].

В стандартном случае, после запуска этой команды система попросит авторизоваться:
И до тех пор, пока пароль не будет указан команда не будет выполнена.

Для того, чтобы можно было получать доступ к удаленному серверу без авторизации нам нужно сделать несколько довольно простых шагов.

1. Генерация пары ключей при помощи ssh-keygen

При этом система запросит ввести ключевую фразу (пароль) либо оставить ее пустой

Данный мануал не призван объяснять основы и принципы сетевой безопасности, поэтому напишу лишь буквально в двух словах об этом.
На самом деле, метод идентификации при помощи пары ключей является более надеждым чем идентификация при помощи обычного пароля лишь в том случае, когда используется двухуровневая авторизация. Т.е. недостаточно иметь пару ключей, нужно еще знать пароль (ту самую ключевую фразу). Если же пароля нет, то теоретически злоумышленник запросто получает доступ к удаленному серверу.

Читайте также:  Какие картриджи нужны для принтера brother

Но, как я уже написал, это тема для отдельной статьи.
Здесь же, для того чтобы упросить задачу мы намеренно создаем пару ключей без пароля.

2. Копирование публичного ключа на удаленный сервер

При этом система попросит ввести пароль пользователя [email protected]

Примечание: Команда ssh-copy-id по умолчанию пытается подключаться к удаленному серверу по порту 22. Если же этот порт закрыт и доступ по ssh возможен по другому порту, например 2020, необходимо указывать это явно.

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

Либо, в случае когда используется нестандартный порт, например 2020:

На этот раз пароль запрошен не будет.

2. Синхронизация файлов при помощи rsync

Еще раз запустим синхронизацию при помощи rsync

В случае с нестандартным портом команда будет выглядеть следующим образом:

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

И последнее примечание: для корректной работы rsync на обоих серверах должна быть установлена идентичная версия сервиса openSSH.
Проверить это можно при помощи команды

В моем случае в ответ я получаю на обоих серверах

Источник

Rsync через ssh

У нас есть два сервера:

1) 1.1.1.1 — основной сервер (файлы, почта, что угодно иное), пользователь user1.
2) 2.2.2.2 — сервер, на котором хранятся резервные копии, пользователь user2.

Считаем, что раньше вы не настраивали доступ по ssh к серверам по ключам, а используете пароли. Заодно от паролей избавимся.

Идея: находясь на сервере 2.2.2.2, мы запускаем процесс копирования данных с основного сервера 1.1.1.1 (к себе, на 2.2.2.2).

Проверяем коннект ssh с паролем

Если мы с сервера 2.2.2.2 не сможем с паролем соединиться по ssh к 1.1.1.1, то дальше можно и не продолжать.

Готовим почву

На серверах установим rsync:

yum install xinetd rsync

Редактируем конфиг xinetd для rsync:

.
disable = no
# flags = IPv6
.

Создадим отдельного пользователя rsync без домашней директории и /sbin/nologin. Да, я люблю вместо общего nobody для важных задач создавать отдельных пользователей. Никогда не знаешь наперед, когда придется анализировать, что и где глючит.

Редактируем (создаем) минимальный конфиг rsync на сервере 1.1.1.1:

service xinetd restart

netstat -lnpt | grep 873
tcp 0 0 . 873 . * LISTEN 16269/xinetd

Ок, xinetd слушает порт rsync и при запросе запустит его.

На сервере 2.2.2.2 (с которого будем коннектится) сгенерируем сертификат для доступа без пароля:

/.ssh/id_rsa -q -P «» -b 4096

  • -q — silense
  • -f — имя файла ключа
  • -P «» — пустой пароль
  • -b 4096 — размер ключа, бит

Просмотрим публичный ключ, который надо будет скопировать на 1.1.1.1, куда будем впоследствии подсоединяться:

На сервере 1.1.1.1 (откуда будем копировать файлы).

Скопируем этот ключ на сервер 1.1.1.1, на который будем логиниться, в директорию пользователя user1, под которым будем логинитсья, в файл

Если директории .ssh на 1.1.1.1 не существует, создадим ее:

/.ssh/authorized_keys
chmod 0644

/.ssh/authorized_keys копируем содержимое публичного ключа, созданного на сервере 2.2.2.2 (файл id_rsa.pub) и перезапускаем sshd:

# service sshd restart

Все, мы готовы проверить соединение с 2.2.2.2 на 1.1.1.1 по ssh:

ssh -i /home/user2/.ssh/id_rsa -p 22 user1@1.1.1.1

Если соединение прошло, можно двигаться дальше. Если нет — надо обязательно понять, где проблема (firewall, ошибка copy/paste ключа, забыли restart sshd, что-то еще).

Запускаем rsync через ssh

Мы будем копировать файлы /data/* с сервера 1.1.1.1 на сервер 2.2.2.2 в папку /backup/.

Формат простой: rsync [опции] [откуда] [куда]

rsync -avz -e «ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null» —progress 1.1.1.1:/data/data.zip /backup/

rsync -avz -e «ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null» —progress user1@1.1.1.1:/data/* /backup/

rsync -avz -e «ssh -p 22» —progress user1@1.1.1.1:/data/* /backup/

-e «ssh . « — указываем, что хотим все передавать по ssh;
-p 22 — указываем порт, на котором работает ssh на сервере 1.1.1.1;
-a, —archive – архивный режим, включает рекурсивное копирование и сохранение прав и владельца;
-v — расширенный вывод;
-z — использовать компрессию данных;
user1 — локальный пользователь сервера 1.1.1.1, настроенный на логин по ssh по ключу.

Читайте также:  Ssc service utility для принтеров epson l210

Естественно, пользователь user1 должен иметь права доступа в /data/.

Вот и все. После копирования проверим, создался ли файл на сервере 2.2.2.2:

Источник

Как заставить Rsync копировать без SSH

Как отучить Rsync от использования SSH при копировании по сети.
В доках пишется, что он использует SSH по-умолчанию — как избавиться от этого гребаного умолчания и перейти на родной порт Rsync = 873 ?

Сервер поднят на 192.168.1.200
Запускаю на клиенте команду без ключа -e для копирование видеофайлов с сервера :

По умолчанию rsync попытается использовать транспорт ssh. Если вы хотите использовать ранее созданный сервер rsync, нужно указать это явно:

Точно также можно синхронизировать файлы с rsync из удаленного сервера:

Но можно спросить, а чем через ссш не устраивает?

смотри свой rsyncd.conf

синтакис вызова такой: rsync -av ipaddr::mydir /tmp/target

не забудь rsyncd стартануть

Эту ссылку уже и мусолю полдня, но что-то совсем туплю, не соображу никак .

SSH — Atom не вытягивает, скорость падает вместо 100 до 20 Mbps
Поэтому и ключик z не подходит.

Если нетрудно, перепишите мой пример правильно, а то сегодня совсем не соображаю.

Кстати! То, что сделал я, ничем не отличается от «первой ссылке в гугле».

Так что просьба не футболить по гуглам, а подправить мой случай

смотри свой rsyncd.conf
не забудь rsyncd стартануть

А чего там смотреть? Я его настроил, и демон запусил иначе как у меня уже копируется по ssh

синтакис вызова такой: rsync -av ipaddr::mydir /tmp/target

А вот этот синтаксис уже поинтересней, чем «Первая ссылка в uугле», поскольку в нем используется двойное двоеточие — ::

Но все равно пока не выходит малахитовый цветок, выдается ошибка:

А чего там смотреть? Я его настроил, и демон запусил иначе как у меня уже копируется по ssh

при копировании по ssh демон rsyncd не используется

ERROR: The remote path must start with a module name not a /

при таком синтаксисе ты указываешь не путь, а имя ресурса, который описан в rsyncd.conf

либо используй синтаксис как показали выше — rsync://

либо используй синтаксис как показали выше — rsync://

Имхо, это «либо» более универсальное, потому что не нужно для разных ситуаций переделывать rsyncd.conf, так ведь?

Но весь прикол в том, что мой пример принципиально не отличается от «синтаксиса выше», сравните сами:

тебе же говорят, вот так надо

Чукча, тебе же написали:

Хорошо, хорошо, я уже заметил свою ошибку (вписал chukcha@, а надо rsync:// )

Выполнил в точности по-вашему:

В логах вот такая хрень:

-e ключ добавь. я хз почему, я пользуюсь конфигом.

Да нафига мне этот ключ, он же SSH включает, от которого как раз и хочу избавится

Двоеточие после хоста лишнее.

А кусок с таргетом зачем откусили? :=)

Значит, по вашему нужно так?

Монтируй удаленный каталог через nfs, smb и используй rsync без всяких ssh.

Значит, и используя rsync:// необходимо прописать в rsyncd.conf «модуль», как сказали выше.

P.S. rsync очень чувствителен к слешу после последнего каталога. Если его нет — копируется, как и ожидается, каталог, а вот если его указать, то копируется только содержимое.

gag
Хотелось бы без прописывания path = /home/shar в конфиге, но раз без это пока не получается, хусим, прописал.

Теперь оно хотя бы запрашивает пароль — чей?
Попробовал прописать от chukcha на сервере — получаю ошибку:

Что за пароль оно спрашивает?

Монтируй удаленный каталог через nfs, smb и используй rsync без всяких ssh.

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

Тогда надо ещё разрешить пользователю доступ, добавив после path :

Читайте также:  Как сбросить счетчик на принтере brother dcp 7065dnr

Он уже был добавлен. Но раз он запрашивает пароль, значит он должен быть где-то прописан?
Где-то уже в гуглах попадалось в какие-то ‘secrets’-файлы

А, тогда, может, попробовать без (у меня эта строчка как раз закомментирована, и копирую без пароля). Иначе, да, смотреть в мане формат файла с паролями.

тоже была закомментирована, но команда c rsync почему-то все равно требовала пароль.
Поскольку не знал, какой, расскоментировал эту строку и создал файл /etc/rsyncd.scrt в который поместил

Теперь при запуске команды с rsync ввожу этот пароль — а фигушки, та же хрень!

Не, я имел ввиду строчку auth user , чтобы rsync был в анонимном режиме.

Если с пользователем/паролем, то надо не забыть указать конкретного пользователя: rsync://[USER@]HOST/SRC .

Ок, закомментировал строчку auth user, и — ура! — избавился от этого надоедливого пароля/
Вернусь к нему позже, когда разберусь с новыми ошибками :=)

И вот, вроде начало получатся :=)
Как продвинусь дальше, сообщу о результатах.

Теперь зачем мне это все надо:

Есть старый комп, на Атоме-510, из которого хочу соорудить бекап-сервер.
Однако ввиду своей древности SSH он не тянет ни в какую — слишком слаб, и скорость по SSH падает со 100 до 20 Mbps.
Поэтому пытаюсь настроить бекап чисто по Rsync без SSH и прочих оболочек.

Логика работы бекап-сервера — в режиме «подскока», т.е.:
— десктоп, который нужно бекапировать, в дневное время обычно включен;
— бекар-сервер должен, например, в обед, в 13:00 включиться (задается в BIOS), выгрести с десктопа изменившиеся файлы и выключиться.

Если такое получится, тогда попробую перейти на Rsnapshot, который как раз и базируется на Rsync.

Однако ввиду своей древности SSH он не тянет ни в какую — слишком слаб, и скорость по SSH падает со 100 до 20 Mbps.

А если поиграть с типом шифра? Раньше arcfour было удобно использовать, сейчас вроде выкинули, но может что на замену есть.

Прямо в самом начале man rsync указано двойное двоеточие (double colon). Читай маны! https://www.meme-arsenal.com/memes/da81aca6f6c41ae22e0f7501523b77ac.jpg

Тогда надо не просто поиграть, а вообще его выкинуть, но не знаю как.
Но такое решение тоже плохо, ведь с десктопа приходится связываться с удаленными серверами, а для них нужен полноценный SSH.

Прямо в самом начале man rsync указано двойное двоеточие (double colon).

Прежде чем сюда обратиться, начитался манов до одурения. Ваше двойное двоеточие тоже не сработало, см. выше.
Но в конце-концов добился желаемого результата!

Вот она, волшебная строка :=)

———-
И что в результате получил:

— если раньше на Атоме, т.е. на клиентском компьютере, его ядра на процессе SSHD захлебывались вплоть до 80-100%, а скорость копирования по сети не поднималась выше 20 МБайт/с,
— то теперь процесс rsync отбирает всего 12-16%, т.е. проц отдыхает, а скорость соответственно держится в пределах 70-80 МБайт/с.
Такой результат меня устроил более чем. Поэтому запустил бекапирование в 5 потоков, и оно жужжит, аж деревья гнутся :=)

Всем, кто помог разобраться в этом хитроумном вопросе — преогромное спасиба! :=)

PS. Хотя это еще не все, есть еще некоторые интересные соображения.

Ваше двойное двоеточие тоже не сработало

Больше 20 лет у всех работает, а у тебя не работает. Не находишь, что это очень странно?

Хотя какое-то время процесс rsync начинает отбирать и до 100%.
Не знаю, с чем это связано.

Больше 20 лет у всех работает, Больше 20 лет у всех работает, а у тебя не работает.

Моя недоработка. Ок, какие преимущества может дать вариант с «двойным двоеточием»?

Погоняй ещё тесты с SSH, по-братски

Щас затяжной бекап идет, если не забуду, позже

zolden
Попробовал первый вариант —

А, я вообще только в обсуждении варианты смотрел, ну да Бог с ними

Там ссылаются на несколько детальных тестов, может что подчерпнете.

Источник

Поделиться с друзьями
КомпСовет
Adblock
detector