Fix the sshd fatal no hostkey alg preauth Error
Beginning with Redhat Enterprise Linux and CentOS 7, the default settings for sshd do not create a DSA host key. This can result in the following error: sshd[pid]: fatal: no hostkey alg [preauth] . This can cause session setup failures for older ssh clients. To allow those connections, perform the below steps. Bear in mind that this change was made to improve security, and this workaround allows weaker encryptions on the affected connections.
Сервер OpenSSH
Эта секция руководства по Ubuntu Server представляет мощную коллекцию инструментов для удаленного контроля и обмена данными с сетевыми компьютерами, названная OpenSSH. Вы также изучите некоторые конфигурационные настройки, доступные для серверного приложения OpenSSH, и то как изменять их на вашей Ubuntu системе.
Серверный компонент OpenSSH, sshd, постоянно ожидает клиентские подключения от любого клиентского приложения. Когда обнаруживается запрос на соединение, sshd устанавливает корректное соединение в зависимости от соединяющегося клиентского приложения. Например, если удаленный компьютер подсоединяется с помощью клиентского приложения ssh, сервер OpenSSH устанавливает сессию удаленного управления после авторизации. Если удаленный пользователь подсоединяется к серверу OpenSSH с помощью scp, сервис OpenSSH на сервере инициирует защищенное копирование файлов между сервером и клиентом после авторизации. OpenSSH может использовать много методов аутентификации, включая простой пароль, открытый ключ и билеты Kerberos.
Установка
Установка клиента и сервера OpenSSH очень простая. Для установки клиентского приложения OpenSSH на вашей системе Ubuntu используйте команду в терминале:
Для установки серверного приложения OpenSSH и связанных файлов используйте такую команду в терминале:
Пакет openssh-server может быть выбран для установки во время процесса установки Ubuntu Server Edition.
Конфигурация
Вы можете настроить поведение по умолчанию серверного приложения OpenSSH, sshd, редактируя файл /etc/ssh/sshd_config. Для информации по конфигурационным директивам, используемым в этом файле, вы можете посмотреть соответствующую страницу руководства, задав следующую команду в терминале:
Существует множество директив в конфигурационном файле sshd, управляющих такими вещами, как настройки соединений и способы авторизации. Далее примеры конфигурационных директив, которые могут быть изменены редактированием файла /etc/ssh/sshd_config.
Скопируйте файл /etc/ssh/sshd_config и защитите его от записи с помощью следующих команд в терминале:
Далее примеры конфигурационных директив, которые вы можете изменить:
Чтобы установить TCP порт прослушивания для вашего OpenSSH 2222 вместо стандартного 22, измените директиву Port таким образом:
Чтобы sshd допускал вход с использованием открытых ключей, просто добавьте или измените строку:
Если строка уже присутствует, убедитесь, что она не закомментирована.
Чтобы позволить вашему OpenSSH серверу показывать содержимое файла /etc/issue.net в качестве шапки пред авторизацией, просто добавьте или измените строку:
Все изменения производятся в файле /etc/ssh/sshd_config.
После изменений в /etc/ssh/sshd_config, сохраните файл и перестартуйте серверное приложение sshd для применения изменний, используя команду в терминале:
Ключи SSH
Для создания ключей введите в терминале клиента:
Это сгенерирует ключи использующие метод цифрового алгоритма подписи (DSA). В процессе у вас спросят пароль. Просто нажмите Enter на запрос о создании ключа. По умолчанию открытый ключ сохраняется в файл
/.ssh/id_dsa.pub, в то время как секретный в
/.ssh/id_dsa. Теперь скопируйте файл id_dsa.pub на удаленный компьютер и добавьте его к
В конце дважды проверьте права доступа файла authorized_keys, чтобы только авторизованные пользователи имели права на чтение и запись. Если права установлены некорректно, измените их:
Теперь у вас есть возможность соединиться по SSH с этим узлом без ввода пароля.
Основы использования протокола SSH
SSH — (Secure Shell — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP- соединений (например, для передачи файлов). Далее рассматривается OpenSSH (демон sshd) альтернатива проприетарного ПО от SSH Communications Security. OpenSSH (открытая безопасная оболочка) — набор программ, предоставляющих шифрование сеансов связи по компьютерным сетям с использованием протокола SSH.
Какой порт у SSH? SSH сервер обычно прослушивает соединения на TCP -порту 22. 
Настройка SSH доступа к вашему серверу
Перед любыми действиями с настройками SSH держите второе окно с открытой SSH-сессией, так как при ошибочных действиях повторно подключиться к серверу вы сможете только через VNC-клиент (если вам хостер его предоставил).
Шаг 1: Логинемся под пользователем root
И делаем свое черное дело список здесь список здесь.
Потом вы подумали, что это очень легко работать под правами root, нужно усложнить себе работу и ввести новую сущность — бесправного пользователя и обязательно дать ему имя как ваш ник в Одноглазиках (сорри, вы продвинутые тогда берите из VK)! Чтобы когда вы в логах (/var/log/auth.log) увидите как хакеры пробуют взломать вашего демона SSH и не догадались о вашем нике из Одноглазиков — это победа!! Вы можете гордиться вашим ником в социальных сетях — его никто не знает. И значит можно пароль поставить как на домашний роутер admin. Я шутил!
По делу: не работайте от root, пожалуйста!
Пример подключения к удаленному нестандартному серверу, который настраивал нестандартный админ, для этого используем ключ -p задания порта и ключ -i для задания ssh ключа (в случае беспарольной аутентификации):
Шаг 2: Создание нового пользователя SSH
Cоздадим пользователя с правами которого будем работать с сервером, для примера создается новый пользователь с именем remuserbak, но вы должны заменить его на имя пользователя, которое вам нравится:
Вам будет задано несколько вопросов, начиная с пароля учетной записи.
Введите надежный пароль и, при желании, введите любую дополнительную информацию. Это не обязательно, и вы можете просто нажать ENTER в любом поле, которое хотите пропустить.
Шаг 3: Предоставление административных привилегий
На втором шаге был создан пользователь remuserbak, но администрировать с ним сервер нельзя, ибо нет у него прав таких! Придется дать ему возможность становится рутом, как говорится с чего начали — тем и закончили.
Чтобы избежать необходимости выходить из системы обычного пользователя и снова входить в систему как учетная запись root, мы можем настроить так называемые привилегии суперпользователя или root для нашей обычной учетной записи. Это позволит нашему обычному пользователю запускать команды с административными привилегиями, помещая слово sudo перед каждой командой.
Чтобы добавить эти привилегии нашему новому пользователю, нам нужно добавить пользователя в группу sudo. По умолчанию пользователям, которые являются членами группы sudo, разрешено использовать команду sudo.
От имени пользователя root выполните команду usermod, чтобы добавить нового пользователя в группу sudo (замените имя пользователя своим новым пользователем:
Проверим командой id добавился ли пользователь в группу sudo
Теперь, когда вы войдя в систему как обычный пользователь remuserbak, можете ввести sudo перед командами, чтобы выполнять действия с привилегиями суперпользователя (root).
Шаг 4: Защита демона sshd
После установки сервера SSH, первым делом исправить файл sshd_config. В нем запретить удалённый доступ пользователя root и разрешить доступ только для доверенных пользователей. Настраиваем от непривилегированного пользователя, используя sudo.
Первое действие перед правкой любого файла — это бекап этого файла, делаем:
Посмотреть текущее настройки демона ssh
Отключение SSH-логин для пользователя root, используя параметр PermitRootLogin no.
После внесения изменений в sshd_config — перегружаем демона SSH.
При таком способе перезагрузки демона SSH текущее соединение не прерывается. Теперь при попытке залогинеться с пользователем root, в логах вы увидите запись:
Всё, у вас демон SSH минимально защищен!
Дополнительные параметры sshd_config, которые можно менять, под ваши задачи и условия, но не делайте это без нужды и предварительно изучите руководство man 5 sshd_config
Шаг 5: Расширенная защита демона sshd
Шаг 6: Дополнительно о SSH, Зачем файл ssh sshrc?
man sshd раздел SSHRC рассказывает об использовании файла /etc/ssh/sshrc. Если этот файл создан с правами на выполнение, то он будет запускать после успешного логина пользователя, но до запуска оболочки пользователя, например bash.
Настройка беспарольной авторизации multiple ssh private keys
Про беспарольную авторизацию в ssh с помощью ключей не пишет разве что ленивый. Зачастую бывает нужно использовать разные ssh-ключи для различных групп серверов/хостов. Например по ролям, территориальному признаку, логину … ну и вообще..
Набирать каждый раз полный путь к файлу с ключем, а главное помнить в каких случаях какой ключ нужен — лень. Да, лень двигатель прогресса.
Вместо использования паролей, с помощью ssh-keygen можно создать ключи DSA или RSA, которыми пользователи могут аутентифицироваться. Ключи RSA являются наиболее широко используемыми и создаются по умолчанию. Немножко терминов:
Итак: делаем ssh-ключи для беспарольной авторизации.
Мы обзавелись ключами, раскидали их публичные части (pub) в authorized_keys соответствующих удаленных хостов (например командой ssh-copy-id):
Для включения аутентификации по ключам, публичный ключ (расширение .pub) должен быть помещен в файл
/.ssh/authorized_keys на удаленном компьютере, например так:
или второй способ копирования более простой и правильный, но не передающий в отличии от первого способа, что происходит в реальности
Теперь определим с каким ключём куда ходить:
с содержимым, например
теперь будут подтягиваться соответствующие настройки. Конечно, при подключении к удаленному серверу, который не определен в
/.ssh/config — будет по умолчанию, или стандартные ключи
/.ssh/id_rsa, или логин/пароль если иначе не прописано в конфиге.
Подробно ключи утилиты ssh-keygen
Утилита ssh-keygen служит для генерация, преобразование и управление ключами. По умолчанию генерирует RSA ключ (ключ -t позволяет задать тип ключа). При генерации запрашивается парольная фраза для 3DES (рекомендуется 10-30 символов). Забытую парольную фразу восстановить невозможно. Число бит по умолчанию — 1024 (минимум — 512 бит, увеличение длины ключа замедляет работу). Комментарий по умолчанию — имя-пользователя@имя-хоста. Имя файла для хранения публичного ключа образуется из имени файла для частного ключа добавлением суффикса ".pub". Ключ хоста должен иметь пустую парольную фразу.
Обычно каждый пользователь, желающий использовать SSH с RSA или DSA аутентификацией, запускает его единожды для создания аутентификационного ключа в $HOME/.ssh/identity, $HOME/.ssh/id_dsa или $HOME/.ssh/id_rsa.
Обычно эта программа генерирует ключи и спрашивает название файла в котором надо сохранить приватный ключ. Публичный ключ будет сохранен в файле с тем же именем, только к нему будет добавлено расширение ".pub". Программа также спросит у вас ключевую фразу. Ключевая фраза может быть пустой, это означает, что ключевая фраза не используется (ключ машины должен иметь пустую ключевую фразу), или это может быть строка произвольной длины. Ключевая фраза схожа с паролем, за исключением того, что ключевая фраза может состоять из набора слов, знаков препинания, цифр, пробелов или любого набора символов, какой вы пожелаете. Хорошими считаются ключевые фразы из 10-30 символов, не являющиеся простыми предложениями или легко угадываемыми (английская проза имеет только 1-2 бита энтропии на символ и обеспечивает очень плохие ключевые фразы) и содержать чередование букв, цифр и не буквенно-цифровых, набранных в верхнем и нижнем регистре, знаков. Ключевая фраза может быть позднее изменена при помощи опции -p.
Не существует возможности восстановить утерянную ключевую фразу. Если ключевая фраза утеряна или забыта, вы должны создать новый ключ и скопировать соответствующий публичный ключ на другие машины.
Для RSA1-ключей в файле ключа имеется поле комментария, который служит только для удобства пользователя, чтобы было проще идентифицировать ключ. Комментарий может вам сообщить для чего этот ключ или чем он полезен. Комментарий инициализируется при создании для "user@host", но может быть изменен при помощи опции -c.
После генерации ключа будут приведены инструкции куда его надо поместить для активации.
Пример. Скрипт. Копирование файла с удаленного компьютера.
Задача. На удаленном компьютере Anacron запускает скрипт для резервирования БД PostgreSQL один раз в сутки. Нужно создать скрипт который будет копировать удаленные backup-копии на локальный сервер бекапов. Скрипт запустим при помощи Использование планировщика cron в Linux.
Поместим публичный ключ файл
/.ssh/authorized_keys на удаленном компьютере.
Скрипт:
Пример. ssh-keygen. Ключи для Azure
Создание ssh ключей для виртуальной Linux в Microsoft Azure. Для создания и использования ключей SSH с Azure выполните описанные ниже действия.
SSH для частого использования
/.ssh/id_dsa.pub (ваш публичный ключ).
3. Можно заходить с первой машины на вторую без пароля. Если не получается — проверьте, нет ли в конфиге sshd удаленной машины строки «PubkeyAuthentication no», а также права на все используемые файлы: на .ssh нужны права 700, на все, что в ней — 600.
Во-вторых, изучаем ssh-agent. Он позволяет вводить Passphrase к ключу только один раз (при подгрузке ключа), а не при каждом логине. Плюс еще некоторые бонусы.
1. Удостоверяемся, что запущен ssh-agent: «ps -C ssh-agent». Если нет — запустите через него терминал, например «ssh-agent roxterm»
2. Подгружаем ключ. «ssh-add
/.ssh/id_dsa», должно ответить, что ключ добавлен. Note: здесть имя файла необходимо указывать, только если оно отличается от дефолтного.
3. Заходим на вторую машину без пароля.
3.9. Говорят, что на OpenBSD надо выставить переменную указывающую на SSH_AUTH_SOCK (что бы это ни значило 🙂 ), иначе агент-форвардинг не работает.
4. Уходим со второй машины и заходим обратно, отдав параметр -A команде ssh. После этого без пароля заходим на третью машину, на которой уже настроена авторизация по ключам. Думаем «ЫЫЫ, прикольно!», ибо на второй-то машине приватных ключей нет!
В-третьих, забываем про флаг -A, поскольку в файле
/.ssh/config (права 600) пишем строку «ForwardAgent yes»
Если все ваши похождения по SSH заканчиваются на машинах, досягаемых в один прыжок, дальше можно не читать. Для случаев, когда имеется точка входа в сеть администрируемых машин (или даже цепочка из них), рекомендую дочитать.
В-четвертых, настраиваем ssh-proxy.
Ситуация: У меня есть сервер alpha, имеющий адрес alpha.pupkin.net, а также сервер beta с адресом 192.168.1.17, находящийся в сети, доступной с alpha, но недоступной с моей тачки. Причем на локальной машине мой юзер называется david, а на всех остальных — v.pupkin. Я пишу в
/.ssh/config следующую уличную магию:
Host *
ForwardAgent yes