Bitrix error while copying ssh key - Исправление ошибок и поиск оптимальных решений проблем

Как исправить ошибку аутентификации SSH

Основные механизмы аутентификации пользователей при подключении через SSH — проверка пароля и сверка ключей. Их можно применять вместе или по отдельности, это настраивается в файле конфигурации SSH. Оба способа надежные, но иногда при их использовании можно столкнуться с ошибкой authentication failed. В этой статье разберемся, какие у этого сбоя могут быть причины и как их устранить.

В чем суть ошибки

У сообщения «authentication failed» перевод на русский предельно простой. Этот вывод в терминале говорит о том, что аутентификация пользователя не удалась.

Аутентификация — это проверка подлинности. Например, у вас есть сервер на cloud.timeweb.com . Вы настроили SSH для удаленного подключения. Чтобы система защиты вас пропустила, нужно пройти процедуру аутентификации – подтвердить, что это действительно вы.

Метод проверки подлинности закреплен в конфигурационном файле SSH. По умолчанию это аутентификация по паролю.

Другой вариант — использование пары SSH-ключей для проверки подлинности. В таком случае у пользователя на компьютере хранится закрытая часть ключа. На сервере располагается открытая часть. При попытке установить соединение эти части сравниваются. При совпадении доступ открывается. Если совпадения нет, появляется сообщение об ошибке — например, следующая ошибка SSH:

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

Ниже разберемся с наиболее частыми ситуациями.

Ошибка при использовании пароля

Обычно проблемы возникают из-за неверного имени пользователя или пароля. Также стоит обратить внимание на конфигурацию сервера — может стоять запрет на аутентификацию через пароль. Как это проверить:

Откройте файл конфигурации на сервере. Он находится по пути /etc/ssh/sshd_config.
Найдите строку PasswordAuthentication. По умолчанию у неё значение `yes`. Это значит, что проверка по паролю разрешена.
Если в вашем файле конфигурации параметр PasswordAuthentication имеет значение `no`, то подключиться по паролю не получится. Чтобы исправить ситуацию, измените значение на `yes`.

С паролем связано и появление ошибки su authentication failure. Вернее, с отсутствием парольной проверки у пользователя root. Если при такой конфигурации выполнить команду `su` без параметров, то вернется ошибка. Чтобы ее устранить, достаточно назначить пользователю root парольную защиту.

Ошибка при использовании ключей

Одна из самых распространенных проблем — использование не тех ключей при установке соединения. Часто это происходит, если с одного компьютера приходится подключаться к разным хостам. Самый простой способ не запутаться — давать понятные названия с указанием на то, для каких целей вы используете файлы аутентификации.

Использование большого количества ключей без явного указания нужного приводит еще к одной ошибке:

Причина сбоя — превышение числа попыток. Это случается из-за того, что SSH-клиент пытается подключиться к хосту, используя все доступные ключи. Исправить ситуацию можно с помощью опций IdentitiesOnly и IdentityFile. Пример запроса на подключение:

Чтобы каждый раз не прописывать это в командной строке при подключении, можно указать необходимую настройку в конфигурационном файле SSH

/.ssh/config. Пример такой настройки:

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

При использовании ssh-ключей может возникнуть еще одна ошибка:

Ее причиной может быть ввод неверной ключевой фразы.

Если вы потеряете ключевую фразу, восстановить ее будет невозможно. Вам нужно будет сгенерировать новую пару значений для Secure Shell.

Восстановление открытого ключа

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

Самый просто способ — использовать утилиту ssh-keygen.

Запустите терминал и выполните команду:

/.ssh/id_rsa — это путь к закрытому части, которая хранится на компьютере. В ответ вы получите последовательность символов. Это и есть открытая часть, которую необходимо добавить на сервер.

В среде Windows решить ту же задачу можно с помощью утилиты PuTTYgen, которая входит в набор PuTTY. В ней есть кнопка Load, через которую вы можете загрузить закрытый ключ. Для этого нужно лишь знать директорию, в которой он хранится на компьютере.

После импорта вы увидите окно с полем `Public key for…`. В нём отобразится открытая часть, которую можно скопировать и отправить на сервер.

Восстановить закрытую часть по открытой нельзя — это противоречит основам безопасности.

На что еще обратить внимание

У понятия « authentication failed» перевод дает весьма общее представление о причине сбоя. Проблема может крыться не только в пароле или ключах. Значение имеют также выставленные права доступа и алгоритмы шифрования.

Неправильная конфигурация клиента

Распространенная ошибка — использование клиента SSH/SFTP (SSH, PuTTY, Filezilla) без правильной настройки всех необходимых параметров, таких как хост, порт, имя пользователя или закрытый ключ.

Другая частая проблема возникает, когда вы используете неподдерживаемый сертификат. Например, пытаетесь добавить в PuTTY файл ключа *.pem вместо файла ключа *.ppk.

Противоречия в файле конфигурации

Убедитесь, что в файле /etc/ssh/sshd_config установлены параметры, которые не противоречат друг другу. Такое может быть, например, при отключении парольной проверки или запрете на подключение для пользователя root.

Распространенный пример конфликта: у параметра PasswordAuthentication установлено значение `yes`, а у параметра PermitRootLogin — значение `no` или `without-password`. Из-за этого сервер не понимает, как проверять пользователей, и не пускает никого.

Настройка прав доступа

У OpenSSH строгие правила к тому, кто должен быть владельцем файлов и какие на них должны быть выставлены права доступа.

Убедитесь, что на сервере выставлены следующие доступы:

./ssh принадлежит текущему аккаунту.

/.ssh/authorized_keys принадлежит текущему аккаунту.

На клиенте также проверьте разрешения следующих файлов:

/ .ssh / config – 600.

Почему важен владелец? Например, вы настраивали доступ через Secure Shell от имени одного пользователя, а затем пытаетесь подключиться под другим аккаунтом, у которого нет прав даже на чтение содержимого защищенных директорий с аутентификационными данными.

Использование устаревших алгоритмов

В OpenSSH начиная с седьмой версии не поддерживаются старые ключи, которые используют алгоритм цифровой подписи — DSA. Ключи ssh-dss считаются слишком слабыми для того, чтобы можно было доверять им защиту подключения к серверу.

Если у вас старые ключи, оптимальное решение — сгенерировать и добавить на хосты новые, которые основаны на более стойких алгоритмах.

Есть и альтернатива, но пользоваться ей придется на свой страх и риск. Речь идет об изменении файла конфигурации /etc/ssh/sshd_config. Если установить параметру PubkeyAcceptedKeyTypes значение `+ssh-dss`, то можно будет использовать ключи, сгенерированные с помощью устаревшего алгоритма цифровой подписи.

Дополнительные опции могут понадобиться и на SSH-клиенте. Например, при подключении к серверу с ПО, которое давно не обновлялось. В частности, такие проблемы возникают при подключении к хостам на CentOS 6, поддержка которой прекращена в конце 2020 года. Чтобы исправить эту ошибку, необходимо добавить опцию `-oHostKeyAlgorithms=+ssh-dss`:

Ошибки на сторонних сервисах

Проблемы аутентификации могут возникать и при использовании сторонних сервисов. Например, при подключении к VK API пользователи сталкиваются с сообщением user authorization failed invalid session . Устранить такой сбой самостоятельно не получится — нужно обращаться в поддержку.

Заключение

Причина ошибки аутентификации может быть как на стороне клиента, так и на стороне сервера. Начинайте диагностику с самого простого: проверьте правильность имени пользователя и пароля, если он используется, выбор SSH-ключа в агенте. Если это не помогает устранить сбой, проверьте конфигурацию подключения и права доступа к файлам, которые OpenSSH использует для проверки подлинности пользователей.

Источник

Добавление нового хоста в пул

Делаю на VPS так:
1. Manage Hosts in the pool > 1. Add new host in the pool
Ввожу «server2» и выдаёт ошибку:

ANSIBLE_COPY_ERR: 2 ANSIBLE_COPY_MSG: The error occurred, server return 106: please view log file /opt/webdir/logs/ssh_keycopy.log Error when upload sshkey to host server2. Please view log in /opt/webdir/logs/ssh_keycopy.log

Следую рекомендации и смотрю файл логов

01-16-15_22:21:05: SSH_INIT — get key text from file 01-16-15_22:21:05: SSH_INIT — root connect to server2:22 01-16-15_22:21:05: SSH_CONNECT — Could not resolve hostname server2:22

Цитата
Денис Богданов написал: 01-16-15_22:21:05: SSH_CONNECT — Could not resolve hostname server2:22

Была такая же проблема при разворорачивании на amazon.
Хотя хост был доступный.

Помог 3 пункт: Reboot host.

Так же самая ситуация. не создается 2й пул!

Пишет:
10-20-15_14:36:25: SSH_INIT — get key text from file
10-20-15_14:36:25: SSH_INIT — root connect to 192.168.10.188:22
10-20-15_14:36:25: SSH_CONNECT — No route to host 192.168.10.188:22

Такая же ошибка, почему молчат разработчики?

Только что проделал данную процедуру, все ок.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Цитата
Александр Суворов написал: Только что проделал данную процедуру, все ок.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Цитата
Александр Суворов написал: Только что проделал данную процедуру, все ок.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Перезагружали виртуальную машину?

Нет, ничего не перегружал. Сразу заработало. Нужно лишь дождаться завершения задачи.
Проверить можно чз меню 5.

Никакого фаирвола между машинами нет?

Цитата
Александр Суворов написал: Только что проделал данную процедуру, все ок.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Перезагружали виртуальную машину?

Никакого фаирвола между машинами нет?

вот ошибка файла ssh_keycopy.log:

12-22-15_20:31:11: SSH_INIT — get key text from file
12-22-15_20:31:11: SSH_INIT — root connect to 192.168.56.102:22
12-22-15_20:31:11: SSH_CONNECT — No route to host 192.168.56.102:22

Цитата
Юрий Руп написал: No route to host 192.168.56.102:22

Цитата
Юрий Руп написал: вот ошибка файла ssh_keycopy.log:

12-22-15_20:31:11: SSH_INIT — get key text from file
12-22-15_20:31:11: SSH_INIT — root connect to 192.168.56.102:22
12-22-15_20:31:11: SSH_CONNECT — No route to host 192.168.56.102:22

Цитата
Денис Диденко написал: Не может соединиться с этим хостом. Вы хотя бы читайте что вам пишут.

Цитата
Александр Суворов написал: ip как выдаются в сети виртмашинам?

Цитата
Александр Суворов написал: в настройках виртмашины сетевые карты в каком режиме стоят — Bridge, Nat, Host и т.п?

В натройках сети стоит: Тип подключения — Виртуальный адаптер хоста; Имя — Virtualbox Host-Only Ethernet adapter

Пробовал тип ставить NAT — такаяже ошибка.

Цитата
Юрий Руп написал: Уважаемый, я вижу что написано, так и спрашиваю потому, что не знаю как решить эту проблему, если вы знаете, подскажите, буду очень признателен.

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

Да я же уже все написал:
В натройках сети виртуальной машины стоит: Тип подключения — Виртуальный адаптер хоста; Имя — Virtualbox Host-Only Ethernet adapter
Виртуальная машина: VMBitrix5.1.5-virtualbox — в самой машине (linuxe) вообще ничего не трогал, все по умолчанию. Если нужен лист какогото файла — скажите какого.
IFCONFIG машины:
eth0 Link encap:Ethernet HWaddr 08:00:27:A9:8C:3B
inet addr:192.168.56.101 Bcast:192.168.56.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fea9:8c3b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1180 (1.1 KiB) TX bytes:1298 (1.2 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

До 192.168.56.101 с компа пингутеся. Да и сайт на этом адресе нормально работает. А вот второй хост никак не создать.

Цитата
Юрий Руп написал: Эх, а проблема та так и не решена. Может кто за это время решил.

2я машина точно сконфигурирована заранее — пароли юзерам root и bitrix сменены при первом входе?

Источник

Содержание

Добавление нового хоста в пул
Почему не могу скопировать свой ssh на другую ноду?
Оказывается контроль версий с Git на VM Bitrix это очень просто

Добавление нового хоста в пул

Делаю на VPS так:
1. Manage Hosts in the pool > 1. Add new host in the pool
Ввожу «server2» и выдаёт ошибку:

ANSIBLE_COPY_ERR: 2 ANSIBLE_COPY_MSG: The error occurred, server return 106: please view log file /opt/webdir/logs/ssh_keycopy.log Error when upload sshkey to host server2. Please view log in /opt/webdir/logs/ssh_keycopy.log

Следую рекомендации и смотрю файл логов

01-16-15_22:21:05: SSH_INIT — get key text from file 01-16-15_22:21:05: SSH_INIT — root connect to server2:22 01-16-15_22:21:05: SSH_CONNECT — Could not resolve hostname server2:22

Цитата
Денис Богданов написал: 01-16-15_22:21:05: SSH_CONNECT — Could not resolve hostname server2:22

Была такая же проблема при разворорачивании на amazon.
Хотя хост был доступный.

Помог 3 пункт: Reboot host.

Так же самая ситуация. не создается 2й пул!

Такая же ошибка, почему молчат разработчики?

Только что проделал данную процедуру, все ок.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Цитата
Александр Суворов написал: Только что проделал данную процедуру, все ок.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Цитата
Александр Суворов написал: Только что проделал данную процедуру, все ок.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Перезагружали виртуальную машину?

Никакого фаирвола между машинами нет?

Цитата
Александр Суворов написал: Только что проделал данную процедуру, все ок.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Перезагружали виртуальную машину?

Никакого фаирвола между машинами нет?

вот ошибка файла ssh_keycopy.log:

12-22-15_20:31:11: SSH_INIT — get key text from file
12-22-15_20:31:11: SSH_INIT — root connect to 192.168.56.102:22
12-22-15_20:31:11: SSH_CONNECT — No route to host 192.168.56.102:22

Цитата
Юрий Руп написал: No route to host 192.168.56.102:22

Цитата
Юрий Руп написал: вот ошибка файла ssh_keycopy.log:

12-22-15_20:31:11: SSH_INIT — get key text from file
12-22-15_20:31:11: SSH_INIT — root connect to 192.168.56.102:22
12-22-15_20:31:11: SSH_CONNECT — No route to host 192.168.56.102:22

Цитата
Денис Диденко написал: Не может соединиться с этим хостом. Вы хотя бы читайте что вам пишут.

Цитата
Александр Суворов написал: ip как выдаются в сети виртмашинам?

Цитата
Александр Суворов написал: в настройках виртмашины сетевые карты в каком режиме стоят — Bridge, Nat, Host и т.п?

В натройках сети стоит: Тип подключения — Виртуальный адаптер хоста; Имя — Virtualbox Host-Only Ethernet adapter

Пробовал тип ставить NAT — такаяже ошибка.

Цитата
Юрий Руп написал: Уважаемый, я вижу что написано, так и спрашиваю потому, что не знаю как решить эту проблему, если вы знаете, подскажите, буду очень признателен.

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

До 192.168.56.101 с компа пингутеся. Да и сайт на этом адресе нормально работает. А вот второй хост никак не создать.

Цитата
Юрий Руп написал: Эх, а проблема та так и не решена. Может кто за это время решил.

2я машина точно сконфигурирована заранее — пароли юзерам root и bitrix сменены при первом входе?

Источник

Почему не могу скопировать свой ssh на другую ноду?

Простой 2 комментария

Потому что после опции -i должен идти путь к файлу с открытым ключом.

Use only the key(s) contained in identity_file (rather than looking for identities via ssh-add(1) or in the default_ID_file). If the filename does not end in .pub this is added. If the filename is omitted, the default_ID_file is used.

Note that this can be used to ensure that the keys copied have the comment one prefers and/or extra options applied, by ensuring that the key file has these set as preferred before the copy is attempted.

Что вы сказали — то команда и пытается сделать: использовать ключ root@192.168.1.150 которого не находит, о чем вам и сообщает.

Источник

Оказывается контроль версий с Git на VM Bitrix это очень просто

Лет 5 назад я работал с системой контроля версий — это была SVN.
Такая себя громоздкая и неповоротливая. Но все же система контроля версий.

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

Очень пугала неизвестность, т.к. практического опыта работы с mercurial или git не было. И из-за этого вопрос всё откладывался и откладывался.

Но на практике оказалось, что всё достаточно просто и с этим вопросом (при отсутствии знаний Git совсем) можно разобраться за пару дней, а с наличием знаний и вовсе за час-два.

В своем посте хочу привести пример настройки репозитория в самом простом варианте.

Зачем вам репозиторий?
Если у вас нет репозитория, то ваша работа с сайтом, это как операция на открытом сердце. Любая ваша ошибка нарушает работоспособность сайта.
Пока сайт в разработке, это вроде некритично, но вот после запуска — это становится огромной проблемой!

Приведу два примера

Пример 1
Есть одна виртуальная машина или сервер (это не важно для нас сейчас).
В папке /home/bitrix/www — располагается файловая структура вашего сайта, например, site.com.
Для разработки нам необходима копия сайта
/home/bitrix/ext_www/dev.site.com, на домене dev.site.com
В обеих папках у нас будут локальные репозитории Git, которые будут работать с удаленным репозиторием.

Пример 2
Отличается тем, что файловая структура сайтов лежит на разных серверах.
Например,
сервер 1 /home/bitrix/www, site.com
сервер 2 /home/bitrix/www, dev.site.com

1. Проверяем есть ли у нас Git
На виртуальной машине версии 5 все уже установлено.
Подключаетесь к вашему серверу по ssh, авторизовываетесь под пользователем bitrix и вводите команду

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

Если Вы проводили инсталяцию git самостоятельно, то не забудьте запретить доступ к папка git вашего сайта в настройках nginx и apache (htaccess).

2. Настраиваете файл .gitignore
Создаете в корне сайта файл .gitignore и настраиваете его.
Приведу пример, в котором мы исключаем из репозитория все что относится к ядру сайта и включаем, только то что нужно.
Коллеги в комментариях подсказали, что можно и вовсе исключить из индекса папку bitrix, для этого нужно использовать папку /local

6. Настройка удаленного репозитория
После того как вы настроили работу репозитория локально, надо выгрузить хранилище на сервер.
В качестве сервера можно выбрать https://bitbucket.org/
Бесплатный сервис, который предоставляет приватные репозитории.
Вы можете выбрать любой сервис, который вам больше по душе.
Настройка авторизации на этих сервисах отлично опасана в интернетах, поэтому я не буду раздувать пост и приведу основные команды для настройки начала работы.

Для начала нам понадобится сгенерировать ssh-ключи
Это делается командой

По умолчанию, если ничего не будете менять, этой командой вы сгенерируете два ключа, приватный id_rsa и публичный id_rsa.pub
они будут в папке /home/bitrix/.ssh/

Далее вам нужно взять содержимое публичного ключа и вставить в настройки аккаунта bitbucket.org
Вы можете открыть файл приватного ключа в редакторе кода и скопировать одной строкой его содержимое. Или вывести на экран содержимое файла командой

Важное замечание! Ключ в bitbucket нужно вставлять в настройках вашего профиля, а не репозитория!

После того как вы настроили ключи, проверьте соединение

В результате вы должны увидеть сообщение об успешно коннекте к сервису.

Если увидите ошибку, то выполняйте соединение с выводом логов

Теперь все должно быть хорошо!

7. Передача синхронизация репозитория
Сервисы тоже отлично подсказывают как синхронизировать репозитории и выдают команды для вашего проекта, поэтому так же кратко.

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

your_company — ваш логин bitbucket.org
your_repo — название вашего репозитория в bitbucket.org

Т.к. локальный репозиторий уже подготовлен, то нам осталось его передать в удаленное хранилище

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

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

Если вы настраиваете репозитории, имея одну рабочую копию сайта, то вам достаточно будет скопировать файловую структуру, это и будет вторым готовым к работе репозиторием.
Кратко о процессе:
1. Создаете дополнительный сайт на виртуальной машине с помощью меню виртуальной машины
2. В папку созданного сайта копируете всю структуру

9. Заключение
В итоге мы настроили
1. Локальный репозиторий продакшен сайта
/home/bitrix/www
2. Удаленный репозиторий на bitbucket
3. Локальный репозиторий сайта разработки
/home/bitrix/ext_www/dev.site.com или папка на другом сервере

Схема работы следущая:
1. Вся разработка ведется на сайте разработки
2. Все изменения отслеживаются командой

Готово!

Update: полезное видео по теме

10. Выводы и использованная литература
Быстро, всего за 9 шагов, можно настроить самую простую работу с репозиториями и сильно упростить себе жизнь.

По поводу работы с системой Git

рекомендую ознакомится с книгой-документацией, очень понятная и полезная
http://git-scm.com/book/ru/v1 или http://git-scm.com/book/ru/v2 (тут не все на русском)
Великолепная шпаргалка по командам GIT:
https://github.com/nicothin/web-develo. master/git

Ну и конечно же, гугл.

Ежедневная работа с Git http://habrahabr.ru/post/174467/
Моя шпаргалка по работе с Git http://eax.me/git-commands/
Организация командной разработки интернет-проекта (с использованием Git и 1С-Битрикс) http://habrahabr.ru/post/219569/
Ежедневный Git http://habrahabr.ru/post/28268/

Очень хороший комментарий от Ивана ниже
http://dev.1c-bitrix.ru/community/web. 4#com62944

I) Как указали выше, папку .git лучше располагать на уровень выше корня сайта. Это не только понизит шансы утечки содержимого .git, но и позволит контролировать служебные механизмы, которым не место в корневом каталоге и подкаталогах сайта: скрипты для запуска по расписанию, unit-тесты и пр.

II) Папку bitrix не стоит включать в .gitignore, так как если не контролировать ядро Битрикс, то:

1. Разработчикам будет уже недостаточно просто склонировать репозиторий для начала работы. Придется добывать недостающие файлы. Причем, если работа над проектом ведется несколько лет, его состояние редко позволит использовать «cp -r», как указано в статье. Как показывает опыт, вместо этого придется заниматься трудоемким избирательным копированием.

2. Разработчики бывают разными и сколько не запрещай, в команде обязательно найдется человек, который поправит что-нибудь в ядре. В этом случае, появляется шанс, что в продуктивную среду уйдет код, который приведет к аварии. Это возможно, если код активно использует измененное ядро, а тестирование функциональности проводилось только на копии этого разработчика.

Если включить файлы ядра в систему контроля версий, то изменения в файлах ядра становится возможным отслеживать и автоматически запрещать на уровне перехватчиков (hooks). Также можно настроить отправку уведомлений таким разработчикам с напоминанием правил работы с Битрикс.

3. Недопустимыми правками часто не брезгуют и операторы заказчика. Если не контролировать файлы ядра, такие изменения в продуктивной среде становится трудно отследить. Хоть Битрикс и сделал для этого собственный инструмент, Git в таких случаях помогает гораздо надежней.

4. Если не контролировать ядро, актуализировать файлы на всех копиях разработки после обновления Битрикс может стать очень затруднительно. Особенно, когда число таких копий приближается к сотне.

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

6. Не существует ни одной объективной причины, почему ядро нужно исключать из контроля версий. Многие опасаются, что производительность Git существенно упадет из-за количества файлов в каталоге bitrix. Это напрасное опасение — практика показывает, что Git прекрасно справляется с этой задачей.

III) Не стоит использовать сторонние сервисы (BitBucket, GitHub и прочие) для чужих коммерческих проектов. Это часто противоречит требованиям NDA, может стать причиной утечек кода, а также, учитывая последние законодательные тенденции, и вовсе однажды оказаться незаконным.

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

При этом, для того чтобы сделать центральный репозиторий, достаточно выбрать подходящий сервер (желательно внутри сети) и набрать там команду git init —bare. И все. В итоге, получается полноценный репозиторий, доступ к которому всегда находится под полным контролем.

Источник

SSH-ключи используются для идентификации клиента при подключении к серверу по SSH-протоколу. Используйте этот способ вместо аутентификации по паролю.

SSH-ключи представляют собой пару — закрытый и открытый ключ. Закрытый должен храниться в закрытом доступе у клиента, открытый отправляется на сервер и размещается в файле authorized_keys.

Создание SSH-ключей в Linux на примере CentOS
Создание SSH-ключей в Windows с PuTTYgen
Отключение аутентификации по паролю

Создание SSH-ключей в Linux на примере CentOS

На клиентской стороне должен быть установлен пакет ssh (openssh). На серверах FirstVDS с шаблонами по умолчанию необходимое ПО уже установлено.

yum -y install openssh-server openssh-clients

На клиентском компьютере в командной строке выполните команду генерации ключей:

ssh-keygen

Введите путь файла, в который будут помещены ключи. Каталог по умолчанию указан в скобках, в примере /домашний_каталог/.ssh/id_rsa. Если хотите оставить расположение по умолчанию, нажмите Enter.

Пароль (passphrase) используется для ограничения доступа к закрытому ключу. Пароль усложнит использование ключа третьими лицами в случае утраты. Если не хотите использовать секретную фразу, нажмите Enter без заполнения строки.

Успешно сгенерировав пару ключей, вы увидите уведомление:

Открытый ключ хранится в файле /домашний_каталог/.ssh/id_rsa.pub, закрытый — /домашний_каталог/.ssh/id_rsa.

Скопируйте открытый ключ на сервер в файл /домашний_каталог/.ssh/authorized_keys. Одной строкой:

cat ~/.ssh/id_rsa.pub | ssh root@ip-адрес-сервера 'cat >> ~/.ssh/authorized_keys'

Или откройте этот файл на сервере редактором vi и вставьте строку с открытым ключом после ssh-rsa.

Ещё один способ скопировать ключ в authorized_keys — команда echo, которая помещает строку в конец файла.

echo ssh-rsa строка-публичного-ключа >> /root/.ssh/authorized_keys

Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.

Создание SSH-ключей на Windows с PuTTYgen

Если вы используете ОС Windows, то подключиться по SSH к вашему (Linux) серверу можно через PuTTY или OpenSSH. Генерация ключей в этом случае выполняется также при помощи этих программ. В примере мы используем клиент PuTTY.

Запустите приложение PuTTYgen, которое устанавливается вместе с PuTTY.

Выберите тип ключа SSH2-RSA и нажмите Generate.

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

После завершения создания ключей открытый ключ выводится на экран, закрытый хранится в памяти приложения. Чтобы сохранить эти ключи нажмите Save public key и Save private key. Укажите расположение файлов с ключами.

При сохранении закрытого ключа, если не заполнено поле Key passphrase, появится запрос «Хотите ли вы сохранить ключ без секретной фразы?»

Теперь открытый ключ необходимо скопировать на сервер в файл authorized_keys. Используйте WinSCP или другой клиент для работы с файлами на удалённом Linux-сервере. Вы можете скопировать файл с открытым ключом целиком на сервер, чтоб его копия хранилась в папке .ssh

Откройте файл authorized_keys через WinSCP и файл, в который вы сохранили открытый ключ (public), на локальном компьютере текстовым редактором. Скопируйте значение ключа, сохраните и закройте файл в WinSCP.

При запуске PuTTY укажите путь к закрытому ключу на локальном компьютере. Для этого во вкладке Connections → Auth выберите необходимый путь.

Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.

Отключение аутентификации по паролю

Подключитесь к серверу по SSH, используя пароль, и откройте файл sshd_config для редактирования.

vi /etc/ssh/sshd_config

Убедитесь, что указан правильный путь к открытым ключам SSH, поставьте значение параметра PasswordAuthentication no.

Перезапустите службу sshd.

service sshd restart

Подключитесь к серверу по SSH без использования пароля. Например, запустите PuTTY, проверьте, что во вкладке Connections -> Auth содержится путь к закрытому ключу и откройте подключение.

В случае успешной аутентификации по SSH-ключу вы получите доступ к командной строке сервера и сообщение вида Authenticating with public key «rsa-key-20170510», где rsa-key-20170510 — имя применённого закрытого ключа, указанное вами в файле authorized_keys.

Этот материал был полезен?

Источник

I tried to set up private/public key authentication on my server (CentOS). Here are the steps I made:

Generated a public/private keypair with puttygen
Copied the public key to the server and appended it with the cat command to the file /root/.ssh/authorized_keys
Checked suggested file ownership and permissions for .ssh (700) and .ssh/authorized_keys (600)
Restarted the sshd service
In the Putty config under Connection > SSH > Auth, selected the privat key

But when I try to connect with Putty, I get the message «Server refused our key». I am prompted for password then, and that works.

I also raised the authentication log level, here is the output for a failed attempt:

    Aug 30 12:55:01 localhost sshd[44558]: debug3: fd 5 is not O_NONBLOCK
Aug 30 12:55:01 localhost sshd[44558]: debug1: Forked child 44752.
Aug 30 12:55:01 localhost sshd[44558]: debug3: send_rexec_state: entering fd = 8 config len 803
Aug 30 12:55:01 localhost sshd[44558]: debug3: ssh_msg_send: type 0
Aug 30 12:55:01 localhost sshd[44558]: debug3: send_rexec_state: done
Aug 30 12:55:01 localhost sshd[44752]: debug3: oom_adjust_restore
Aug 30 12:55:01 localhost sshd[44752]: Set /proc/self/oom_score_adj to 0
Aug 30 12:55:01 localhost sshd[44752]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Aug 30 12:55:01 localhost sshd[44752]: debug1: inetd sockets after dupping: 3, 3
Aug 30 12:55:01 localhost sshd[44752]: Connection from 91.15.164.238 port 58557 on 82.165.78.188 port 22
Aug 30 12:55:01 localhost sshd[44752]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.70
Aug 30 12:55:01 localhost sshd[44752]: debug1: no match: PuTTY_Release_0.70
Aug 30 12:55:01 localhost sshd[44752]: debug1: Enabling compatibility mode for protocol 2.0
Aug 30 12:55:01 localhost sshd[44752]: debug1: Local version string SSH-2.0-OpenSSH_6.6.1
Aug 30 12:55:01 localhost sshd[44752]: debug2: fd 3 setting O_NONBLOCK
Aug 30 12:55:01 localhost sshd[44752]: debug3: ssh_sandbox_init: preparing rlimit sandbox
Aug 30 12:55:01 localhost sshd[44752]: debug2: Network child is on pid 44753
Aug 30 12:55:01 localhost sshd[44752]: debug3: preauth child monitor started
Aug 30 12:55:01 localhost sshd[44752]: debug1: SELinux support disabled [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: privsep user:group 74:74 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: permanently_set_uid: 74/74 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: SSH2_MSG_KEXINIT received [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit:  [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit:  [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: reserved 0  [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,rsa2048-sha256,rsa1024-sha1,diffie-hellman-group1-sha1 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: ssh-rsa,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1305@openssh.com,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1305@openssh.com,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-etm@openssh.com [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-etm@openssh.com [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: none,zlib [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: none,zlib [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit:  [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit:  [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_parse_kexinit: reserved 0  [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: mac_setup: setup hmac-sha2-256 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: mac_setup: setup hmac-sha2-256 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: kex: curve25519-sha256@libssh.org need=32 dh_need=32 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_send entering: type 120 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_receive_expect entering: type 121 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_receive entering [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_receive entering
Aug 30 12:55:01 localhost sshd[44752]: debug3: monitor_read: checking request 120
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_send entering: type 121
Aug 30 12:55:01 localhost sshd[44752]: debug1: kex: curve25519-sha256@libssh.org need=32 dh_need=32 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_send entering: type 120 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_receive_expect entering: type 121 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_receive entering [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_receive entering
Aug 30 12:55:01 localhost sshd[44752]: debug3: monitor_read: checking request 120
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_send entering: type 121
Aug 30 12:55:01 localhost sshd[44752]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_key_sign entering [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_send entering: type 6 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_receive_expect entering: type 7 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_receive entering [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_receive entering
Aug 30 12:55:01 localhost sshd[44752]: debug3: monitor_read: checking request 6
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_answer_sign
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_answer_sign: signature 0x7f0b70e15390(271)
Aug 30 12:55:01 localhost sshd[44752]: debug3: mm_request_send entering: type 7
Aug 30 12:55:01 localhost sshd[44752]: debug2: monitor_read: 6 used once, disabling now
Aug 30 12:55:01 localhost sshd[44752]: debug2: kex_derive_keys [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: set_newkeys: mode 1 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug2: set_newkeys: mode 0 [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Aug 30 12:55:01 localhost sshd[44752]: debug1: KEX done [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug1: userauth-request for user root service ssh-connection method none [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug1: attempt 0 failures 0 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_getpwnamallow entering [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_send entering: type 8 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive_expect entering: type 9 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive entering [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive entering
Aug 30 12:55:04 localhost sshd[44752]: debug3: monitor_read: checking request 8
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_answer_pwnamallow
Aug 30 12:55:04 localhost sshd[44752]: debug3: Trying to reverse map address 91.15.164.238.
Aug 30 12:55:04 localhost sshd[44752]: debug2: parse_server_config: config reprocess config len 803
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_send entering: type 9
Aug 30 12:55:04 localhost sshd[44752]: debug2: monitor_read: 8 used once, disabling now
Aug 30 12:55:04 localhost sshd[44752]: debug2: input_userauth_request: setting up authctxt for root [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_start_pam entering [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_send entering: type 100 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_inform_authserv entering [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_send entering: type 4 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_inform_authrole entering [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_send entering: type 80 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug2: input_userauth_request: try method none [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive entering
Aug 30 12:55:04 localhost sshd[44752]: debug3: monitor_read: checking request 100
Aug 30 12:55:04 localhost sshd[44752]: debug1: PAM: initializing for "root"
Aug 30 12:55:04 localhost sshd[44752]: debug1: PAM: setting PAM_RHOST to "p5b0fa4ee.dip0.t-ipconnect.de"
Aug 30 12:55:04 localhost sshd[44752]: debug1: PAM: setting PAM_TTY to "ssh"
Aug 30 12:55:04 localhost sshd[44752]: debug2: monitor_read: 100 used once, disabling now
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive entering
Aug 30 12:55:04 localhost sshd[44752]: debug3: monitor_read: checking request 4
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_answer_authserv: service=ssh-connection, style=
Aug 30 12:55:04 localhost sshd[44752]: debug2: monitor_read: 4 used once, disabling now
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive entering
Aug 30 12:55:04 localhost sshd[44752]: debug3: monitor_read: checking request 80
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_answer_authrole: role=
Aug 30 12:55:04 localhost sshd[44752]: debug2: monitor_read: 80 used once, disabling now
Aug 30 12:55:04 localhost sshd[44752]: debug1: userauth-request for user root service ssh-connection method publickey [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug1: attempt 1 failures 0 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug2: input_userauth_request: try method publickey [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug1: test whether pkalg/pkblob are acceptable [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_key_allowed entering [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_send entering: type 22 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive_expect entering: type 23 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive entering [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive entering
Aug 30 12:55:04 localhost sshd[44752]: debug3: monitor_read: checking request 22
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_answer_keyallowed entering
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_answer_keyallowed: key_from_blob: 0x7f0b70e1ca10
Aug 30 12:55:04 localhost sshd[44752]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Aug 30 12:55:04 localhost sshd[44752]: debug1: trying public key file /root/.ssh/authorized_keys
Aug 30 12:55:04 localhost sshd[44752]: debug1: fd 4 clearing O_NONBLOCK
Aug 30 12:55:04 localhost sshd[44752]: debug2: key_type_from_name: unknown key type '----'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing keytype
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: check options: '---- BEGIN SSH2 PUBLIC KEY ----rn'
Aug 30 12:55:04 localhost sshd[44752]: debug2: key_type_from_name: unknown key type 'BEGIN'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing keytype
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: advance: 'BEGIN SSH2 PUBLIC KEY ----rn'
Aug 30 12:55:04 localhost sshd[44752]: debug2: key_type_from_name: unknown key type 'Comment:'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing keytype
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: check options: 'Comment: "rsa-key-20170830"rn'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: advance: '"rsa-key-20170830"rn'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: check options: 'AAAAB3NzaC1yc2EAAAABJQAAAQEAkO9lXNIVuohGAOsCQy+NDIJv7a+a6z6ekmSprn'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: advance: ''
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: check options: 'HfFduHAvOadeX/HDidL1696CVOHjX8fJ7ITTCaFl2ljI06lobZ2baDAsezpMhut9rn'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: advance: ''
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: check options: 'xmovTOmTJK3pOAI9E1S3Hmhum0QViFsE5oCiMHwZixLmWoeZt09ZwSZyQZAvtHTUrn'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: advance: ''
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: check options: '73bviqiky/j2xYpG+5QKyViyCEAa6KbJKnGpLw8UTf0rEBhUES9wLBt4vU3AZuQdrn'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: advance: ''
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: check options: 'evfZSr3lDBlCCdX3vyJJP8m4x3+8YMSvJSfKa9MErWpxjNE+4GMhyexNILSP+lgyrn'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: advance: ''
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: check options: '5tqWIehpSekThkJLpi0KPvGiK/bm7oXMVNLN0KdLAf/MKUzB9w==rn'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing whitespace
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: advance: ''
Aug 30 12:55:04 localhost sshd[44752]: debug2: key_type_from_name: unknown key type '----'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing keytype
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: check options: '---- END SSH2 PUBLIC KEY ----rn'
Aug 30 12:55:04 localhost sshd[44752]: debug2: key_type_from_name: unknown key type 'END'
Aug 30 12:55:04 localhost sshd[44752]: debug3: key_read: missing keytype
Aug 30 12:55:04 localhost sshd[44752]: debug2: user_key_allowed: advance: 'END SSH2 PUBLIC KEY ----rn'
Aug 30 12:55:04 localhost sshd[44752]: debug2: key not found
Aug 30 12:55:04 localhost sshd[44752]: debug1: restore_uid: 0/0
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_answer_keyallowed: key 0x7f0b70e1ca10 is not allowed
Aug 30 12:55:04 localhost sshd[44752]: Failed publickey for root from 91.15.164.238 port 58557 ssh2: RSA 4c:13:08:b4:06:eb:ea:98:54:69:50:3e:cf:22:9e:da
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_send entering: type 23
Aug 30 12:55:04 localhost sshd[44752]: debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug1: userauth-request for user root service ssh-connection method gssapi-with-mic [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug1: attempt 2 failures 1 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug2: input_userauth_request: try method gssapi-with-mic [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_send entering: type 42 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive_expect entering: type 43 [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive entering [preauth]
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_receive entering
Aug 30 12:55:04 localhost sshd[44752]: debug3: monitor_read: checking request 42
Aug 30 12:55:04 localhost sshd[44752]: debug1: Unspecified GSS failure.  Minor code may provide more informationnKey table file '/etc/krb5.keytab' not foundn
Aug 30 12:55:04 localhost sshd[44752]: debug3: mm_request_send entering: type 43
Aug 30 12:55:04 localhost sshd[44752]: debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" [preauth]

Источник