ssh -vv для начала

Обычным ssh соединяется? Проверь логи ssh клиента и сервера.

ну если права на .ssh точно правильные, то тебе следует вспомнить, что ed25519 еще не везде поддерживается, а rsa уже не везде поддерживается и bспользвать ключ, который поддерживается обеими сторонами.

chmod 0644 ~/.ssh/authorized_keys

неправильный ответ. Должно быть

-rw-------

Это на приватный, а на публичный УМВР

[mandala@vm236086 ~]$ ls -l ./.ssh/
итого 4
-rw-r--r-- 1 mandala mandala 398 фев 27 11:19 authorized_keys

dwell и переименуй публичный в authorized_keys, в качестве бреда. У меня помню когда то затык был где то, и это решило, потом воспроизвести не смог. Мои кривые руки, но я даже не понял где косячил.

што?

drwx------  2 user user  4096 Mar  5 19:39 ./
drwxr-xr-x 46 user user  4096 Mar  5 19:17 ../
-rw-------  1 user user   102 Mar  5 19:39 authorized_keys
-rw-------  1 user user 23189 Feb  9 15:37 config
-rw-------  1 user user 25700 Jun 29  2017 config_2017-06-29
-rw-rw-r--  1 user user 25498 May  4  2017 config_pg2
-rw-------  1 user user   227 May  2  2017 id_ecdsa
-rw-r--r--  1 user user   175 May  2  2017 id_ecdsa.pub
-rw-------  1 user user   399 Jan 27  2017 id_ed25519
-rw-r--r--  1 user user    95 Jan 27  2017 id_ed25519.pub
-rw-------  1 user user 12424 Mar  1 03:26 known_hosts
-rw-r--r--  1 user user  3992 May  4  2017 known_hosts.old

-rw-r--r--  1 user user   175 May  2  2017 id_ecdsa.pub

У тебя тоже самое, нет, у меня глюки? ТС говорил о публичном именно.

Дядь, иди умойся. Как следует глаза промой. Я указал на неправильные права на файле authorized_keys

На сервере бэкапов точно приватный ключ есть?<br> Что пишет в логах, при попытке подключения с сервера бэкапов?

А по моему у тебя глаза слиплись, сам не видишь что показываешь. Как демон ssh прочитает публичный ключ если ты ему -rw------- выставишь?

Однако мы не видели ни вывода ssh-клианта от ТС-а, ни логов с сервера, и хз что у него там с правами на приватный, тут согласен.

Анонимус неодобряет

Забодал, в authorized_keys хранятся публичные ключи, 644 для него правильно.

Вот меня тоже смущают команды из ОП-а, но я списал на бред по памяти.

Значит, у автора всё работает.

Это у меня с Мандэлой всё работает. А ты летать не умеешь, а выпендреваешься.

может вы оба всё-таки умоетесь и сходите узнаете как правильно? https://www.google.ru/search?ie=UTF-8&hl=ru&q=authorized_keys permiss...

или на вас 4.2 накидать?

Накатай 5.2, потому что ты упрямый осёл, и почитай маны. Тебе русским языком говорят - работоспособность authorized_keys в 644 проверена на практике.

Ты сам выложил выхлоп:

drwx------  2 user user  4096 Mar  5 19:39 ./
drwxr-xr-x 46 user user  4096 Mar  5 19:17 ../
-rw-------  1 user user   102 Mar  5 19:39 authorized_keys
-rw-------  1 user user 23189 Feb  9 15:37 config
-rw-------  1 user user 25700 Jun 29  2017 config_2017-06-29
-rw-rw-r--  1 user user 25498 May  4  2017 config_pg2
-rw-------  1 user user   227 May  2  2017 id_ecdsa
-rw-r--r--  1 user user   175 May  2  2017 id_ecdsa.pub
-rw-------  1 user user   399 Jan 27  2017 id_ed25519
-rw-r--r--  1 user user    95 Jan 27  2017 id_ed25519.pub
-rw-------  1 user user 12424 Mar  1 03:26 known_hosts
-rw-r--r--  1 user user  3992 May  4  2017 known_hosts.old

А теперь смотрим что ТС говорит:

chmod 0644 ~/.ssh/authorized_keys

Т.е. ровно тоже самое что ты показываешь «как правильно». Отдуплись уже. Я тебе с боевого сервера дал выхлоп с этим же

[mandala@vm236086 ~]$ ls -l ./.ssh/
итого 4
-rw-r--r-- 1 mandala mandala 398 фев 27 11:19 authorized_keys

Видишь имя хоста? Думаешь это я так по пьяному угару локалхосты называю? Или ради тебя тут выдумываю?

Другое дело, что ТС там по ходу полную ерунду сделал, а не пару ключей.

Как демон ssh прочитает публичный ключ если ты ему -rw------- выставишь?

Во-первых, он обычно работает от рута, которому на права пофиг. Во-вторых, форкнется и сменит юзера на нужного.

Ну мы не знаем что там у ТС, он вон вообще замолчал. В ОПе ерунда какая-то. Однако -rw-r--r-- на публичный — это вот нормально, а -rw------- — это на приватный который у ТС-а должен лежать на том сервере, куда он бекап rsync-ом и тянет.

А targitaj ошибся где и что, я его поправил, а он тут дебош устроил.

ГЛАЗА ПРОТРИ. ТАМ 600, а не 644

*фейспалм* ты там пьяный штоль? или обдолбался клеем?

Я вижу 0700 на директорию и 0644 на файл. Я вот даже проверил:

drwx------ 2 mandala mandala      4096 фев 27 11:43 .ssh

Что не так то?

Ты извини, но кажется ты ободрался. На удаленном хосте:

0700 на ~/.ssh и 0644 на ~/.ssh/authorized_keys

Я не прав, у ТС в ОПе в принципе все нормально, так что все таки ждем ssh -vv и логов сервера

Про права на клиенте нам вообще ни чего не сказали еще.

Так, пацаны в чате посмотрели у себя, для authorized_keys допустимо и 600 и 644, это не должно быть причиной проблемы. Попробуй ключ ecdsa, он сейчас вроде как всем-всем поддерживается.

Смотри что делал ТС, перевожу с его языка на понятный:

На удаленном сервере:

$ mkdir ~/.ssh
$ chmod 0700 ~/.ssh
$ touch ~/.ssh/authorized_keys
$ chmod 0644 ~/.ssh/authorized_keys

Теперь на клиенте, который запускает rsync через ssh на удаленный сервер и забирает бекап:

$ ssh-copy-id -i ~/.ssh/id_key.pub user@host

Теперь от пускает на клиенте типа

$ rsync -avz -e ssh /home/user user@host

И получает тыкву. Что у него с правами на ключ на клиенте он нам не сказал!

Ну вот, слава яйцам, разобрались. Ждем ТС-а.

Я не замолчал, просто на почту оповещения об ответах не приходили :) На клиенте на id_rsa.pub 644 права.

root@qry:~# ssh -vv OpenSSH_6.0p1 Debian-4+deb7u6, OpenSSL 1.0.1t 3 May 2016 usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] [user@]hostname [command]

На клиенте какие права на id_rsa приватный? Покажи вывод на сервере бекапов:

$ ls -l ~/.ssh

Используй тег [code] выхлоп [/code] — чтобы каша не получалась вместо форматирования.

Эту команду тоже не сервере бекапов (который запускает rsync)

$ ssh -vv user@host

Где user — твой пользователь на удаленном сервере с которого нужно сделать бекап, host — адрес сервера с которого нужно снять бекап.

На удаленном сервере авторизация по ключу включена? проверь строки на сервере в файле /etc/ssh/sshd_config

PubkeyAuthentication yes

На сервере сделай

tail -f /var/log/auth.log

Я тебе еще раз, русским языком, говорю. НЕ ИСПОЛЬЗУЙ RSA. Оно DEPRECATED. Чего тебе непонятного? Всё, сдох rsa, забудь о нём. Используй ecdsa и ed25519.

Что, вам уже квантовые компьютеры завезли?

Однако ssh-keygen из коробки генерирует именно RSA, видать разрабы OpenSSH дебилы полные. Да и RSA это не один алгоритм, и от длинны ключа многое зависит

Я не большой специалист по криптографии, так что доверюсь искаропки разрабам OpenSSH и не буду парить себе мозг.

Хотя я не прав, рекомендуют ecdsa/ed25519.

А rsa суют в дефолт в первую очередь для обратной совместимости с длиннищуей длинной ключа для пущей безопасности.

Длинный ключ и медленно. А короткий и правда потенциально не безопасен.

НЕ ИСПОЛЬЗУЙ RSA. Оно DEPRECATED.

Блджад, ляг и проспись.

OpenSSH ставит самый низкий приоритет rsa. Основная проблема: совместимость и упоротость некоторых разрабов сторонних клиентов.

Основная проблема ECDSA в том, что от него нет пользы, кроме вреда. Совместимость в жопе, потенциальные бэкдоры, тормоза.

Единственный профит - ключи меньше. Но у тебя тут не смарткарта, на терабайтный диск пару тысяч бит как-нибудь влезут.

Мне пофигу, я юзаю дефолтные rsa (2048 сейчас вроде), я просто почитал чейнджлоги по части ECDSA/ED25519 и сам себя поправил. RSA не деплекатед конечно, но факт что он «ценится» авторами опенссш дешевле других — это факт.

Может для других сфер использования криптографии (не ssh) и критична производительность, вот rsa и хоронят ускоренно... Мне пофиг, я тех сфер не касаюсь.

но факт что он «ценится» авторами опенссш дешевле других — это факт.

Ничего не знаю об их заморочках.

критична производительность, вот rsa и хоронят ускоренно

Ещё раз, rsa в общем случае быстрее. Но для ssh на современных интелях это действительно не важно.

с разморозкой https://www.google.ru/search?q=rsa deprecated уже год на ЛОРе об этом говорим

с разморозкой https://www.google.ru/search?q=rsa deprecated уже год на ЛОРе об этом говорим

Погоди, я тоже так могу: https://www.google.ru/search?q=rsa is best algorithm for public-key cryptography

Захочешь сказать что-то конкретное - зови.

конкретно, в ubuntu 16.04 по-умолчанию нет поддержки rsa. Достаточно конкретно?

конкретно, в ubuntu 16.04 по-умолчанию нет поддержки rsa. Достаточно конкретно?

Хоспаде, как с тобой трудно. В каком куске убунту нет поддержки rsa? Что, прямо из ssh, openssl, ядра везде выпилили? Где линк?

По-умолчанию в openssh выключено. Так-то до полного исключения далеко. Здесь и сейчас речь не про теоретическую поддержку, а про решение проблемы. Метод исключения предлагает исключить все возможные причины, включая отключенный rsa. Использовать ed25519 я не предлагаю, потому что в том же wheezy его ЕЩЕ нет. Поэтому ecdsa. Потому что поддержка есть практически железобетонно.

Не касаясь того, что вместо метода исключения можно тупо заглянуть в логи.

Я только что скачал изошник 16.04, установил его в виртуалку, скопировал в неё мой публичный rsa ключ и залогинился по этому ключу. Там обыскал все конфиги от ssh клиента и сервера и не нашёл ни одного места, где что-то хоть отдалённо напоминающие rsa было бы отключено. Даже ssh-keygen по умолчанию тупо генерирует rsa. Забодал. Пока.

Хм, посмотрел - действительно. Какая-то странная путаница. Но я точно помню, что были проблемы с rsa. Может быть, из-за длины по-умолчанию?