SSH без пароля или аутентификация с использованием шифрованных ключей

Ключи SSH. Или метод Identity/Pubkey

При использовании метода идентификации Identity/Pubkey исключается использования статических паролей. Дабы каждый раз не набирать пароли, которые можно перехватить кейлоггером ну или просто подсмотреть, мы будем хранить на диске пару ключей, которые и будут использоваться для проверки подлинности. Вот некоторые из положительных моментов этого типа аутентификации:

• Никто не сможет войти на сервер с Вашей учетной записью, так как им необходимо обладать приватным ключом и кодовой фразой.
• Администратор сервера может вообще убрать пароль учетной записи, дабы исключить его дискредитацию.
• Вы можете использовать утилиту ssh-agent и он будет предоставлять аутентификационные данные за Вас.
• Вы можете устанавливать определенные ограничения, например запрещая перенаправление портов, выполнение определенных программ и т.д.

Как установить SSH-клиент в Windows 10

Клиент SSH является частью Windows 10, но это «дополнительная функция», которая не устанавливается по умолчанию.

Чтобы установить его, перейдите в «Настройки»> «Приложения» и нажмите «Управление дополнительными функциями» в разделе «Приложения и функции».

Нажмите «Добавить функцию» вверху списка установленных функций. Если у вас уже установлен SSH-клиент, он появится в списке здесь.

Прокрутите вниз, выберите «OpenSSH Client (Beta)» и нажмите «Установить».

Windows 10 также предлагает сервер OpenSSH, который вы можете установить, если хотите запустить сервер SSH на своем ПК. Вы должны установить его, только если вы действительно хотите запустить сервер на своем ПК, а не просто подключиться к серверу, работающему в другой системе.

Шаг 2: Создание нового пользователя SSH

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

root@vps:~# adduser remuserbak

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

Введите надежный пароль и, при желании, введите любую дополнительную информацию. Это не обязательно, и вы можете просто нажать ENTER в любом поле, которое хотите пропустить.

Активировать сервер и клиент OpenSSH в Windows 10

Начиная с Fall Creators Update, Windows 10 приносит с собой клиент и сервер на базе OpenSSH так что любой пользователь, который хочет его использовать, может сделать это без проблем. Эти функции не являются обязательными, поскольку они могут понадобиться не всем пользователям, поэтому нам придется вручную включить их, чтобы использовать их.

Чтобы установить OpenSSH клиент и / или сервер ОС Windows 10 , что нам нужно сделать, это открыть меню конфигурации операционной системы и перейти в раздел «Приложения> Приложения и функции> Дополнительные функции.

Здесь мы увидим раздел о дополнительных функциях Windows. Мы можем увидеть все те, которые мы установили и активировали в операционной системе, и установить те, которые нам нужны, если у нас их еще нет. Для этого нам нужно будет нажать " Добавить функцию ».

Мы увидим все функции и дополнительные возможности, которые предлагает нам Windows 10. Нас интересуют клиент и сервер SSH. Мы можем искать их вручную, но самый быстрый способ — ввести " SSH »В поисковой системе, чтобы быстро найти и сервер, и клиента.

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

Как их удалить

Если наступит время, когда нам больше не понадобится этот клиент или этот сервер, мы сможем отключить эти дополнительные функции Windows. Не для того, чтобы освободить место, поскольку между клиентом и сервером они едва достигают 30 МБ, а для того, чтобы функции были в порядке и во избежание того, что из-за ошибки кто-то может удаленно подключиться к нашему ПК.

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

Когда удаление будет завершено, эти службы больше не будут доступны.

Вариант первый: генерируем ключи на linux.

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

Запускаем утлиту ssh-keygen

Программа спросит куда сохранить ключи и предложит задать пароль. Смело нажимаем два раза enter и получем результат. Теперь у нас есть два ключа, которые были сохранены в директорию .ssh: id_rsa — приватный ключ и id_ — публичный ключ. Ключи выглядят в виде текста. По этому их можно легко скопировать и вставить в нужный файл.

Заходим в папку .ssh. На сервере выполняем cat id_ > authorized_keys — так мы запишем наш ключ в нужный файл На сторону клиента можно скопировать текст ключа id_rsa. Меняем файлу права chmod -c 0600 id_rsa. 

Теперь заходим на удаленный сервер уже без пароля.

Копируем содержимое ключа id_rsa, вставляем куда-нибудь в блокнотик и сохраняем без расширения. Открываем программу PuTTy Key Generator и загружаем наш ключ кнопкой «Load»

Далее открываем клиент PuTTy. Как обычно в главном окне указываем куда подключаемся, а с левой стороны выбираем «Connection -> Auth», в окошке выбираем наш ключ.

Подключаемся, видим предупреждение и подтверждаем «Yes»

И мы попадаем на сервер без пароля

Принцип работы ssh_config

Параметры конфигурации SSH соединения можно прописать с помощью трех указанных ниже способов*:

1. в опциях, задаваемых с помощью командной строки;
2. в настройках файла конфигурации конкретного пользователя ~/.ssh/ssh_config;
3. в общесистемном конфигурационном файле (для всех пользователей данного локального компьютера) /etc/ssh/ssh_config;

*Примечание: наибольший приоритет имеет командная строка, затем идет ~/.ssh/ssh_config и в последнюю очередь уже /etc/ssh/ssh_config.

Покажем на простом примере, как создать и отредактировать под Ubuntu ssh config file для конкретного пользователя локальной машины.

• Если файл ssh_config не создан, то необходимо его создать с помощью команды:

touch ~/.ssh/config

• На следующем этапе нужно отредактировать данный файлв nano ~/.ssh/config таким образом:

Host freehostUA HostName Port 22 User root

Где: Host — это alias (псевдоним) для нашего SSH-соединения, HostName — IP адрес VPS (или имя хоста, если включен DNS), Port — номер порта, User — имя пользователя.

С помощью несложных настроек мы создали alias для нашего VPS на , таким образом, соединиться с нашим удаленным сервером можно будет с помощью простой команды в терминале:

ssh freehostUA

Ниже опишем, что означают параметры, используемые в ssh_config, а также дадим примеры типовых настроек.

Linux подобную ОС Ubuntu можно установить на наш VPS хостинг.

Параметры ssh_config

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

man ssh_config

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

• Host — alias (псевдоним), произвольное наименование хоста.
• HostName — IP адрес удаленного сервера или имя хоста (если настроен DNS).
• Port — номер порта (если он нестандартный, по умолчанию используется порт 22).
• User — имя пользователя.
• IdentityFile — указывается путь к SSH-ключу, который используется для аутентификации при соединении с удаленным сервером (как правило, применяется в том случае, когда ключи не хранятся в директории «по умолчанию»).
• IdentitiesOnly — сообщает клиенту SSH, какой именно ключ следует использовать для аутентификации на сервере (а не любые ключи, которые находятся в папке для ключей «по умолчанию»). В некоторых случаях может использоваться вместе с параметром IdentityFile, если этот параметр прописан в файле ssh_config, то будут проверены все ключи, даже те, которые пользователь введет в командной строке.
• ServerAliveInterval и ServerAliveCountMax — ssh-клиент будет запрашивать ответ от удаленного хоста, даже если он не получает никаких данных в указанный интервал времени. Эти параметры помогут предотвратить сбрасывание соединения по причине отсутствия активности.
• CertificateFile — используется опционально, совместно с параметром IdentityFile для точного указания сертификата, который необходимо предоставить для аутентификации.
• PreferredAuthentications — параметр, который устанавливает в каком порядке будут использоваться методы аутентификации (по умолчанию: gssapi-with-mic, hostbased аутентификация, аутентификация на базе SSH-ключей, keyboard-interactive и вход по паролю).
• SetEnv и SendEnv — эти параметры разрешают ssh-клиенту передавать локальные переменные среды на указанный удаленный хост, при этом сервер должен быть настроен для приема этих переменных. Для этого системный администратор должен на удаленном сервере в файле /etc/ssh/sshd_config установить значение Yes для параметра AcceptEnv.
• HostKeyAlias — клиенту SSH дается указание использовать псевдоним ключа (key alias) из файла ~/.ssh/known_hosts вместо HostName. Данный параметр будет полезен для хостов с динамическими IP-адресами.
• ProxyJump — с помощью этой опции можно организовать SSH Jump Server (jump host или bastion host), используя флаг –J при написании команды.
• ForwardAgent и AddKeysToAgent — эта опция служит для организации безопасного проброса ключа (agent forwarding), позволяет осуществить доступ удаленного хоста к локальному SSH-агенту пользователя.

*Примечание: ниже покажем на примерах, как использовать данные опции в файле ssh_config.

Настройка безопасности SSH – Заключение

Для верности, перезагрузим настраиваемые хосты. Если вы где-то накосячили с настройками , вас ждёт жирный сочный факап. Исправить который можно будет только подключившись через консоль сервера и заменив текущий файл sshd_config на бекап.

sudo cp /etc/ssh/sshd_ /etc/ssh/sshd_config

Ну или ручками найдя в нём ошибку.

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

LinuxSSHUbuntuUbuntu ServerОсновы

Финальная настройка сервера

Последний шаг настройки SSH — отключение возможности входа на сервер по паролю, в файле конфигурации.

nano /etc/ssh/sshd_config

Раскомментируйте или добавьте значениe:

PasswordAuthentication no

После чего перезапустите службу SSH.

sudo service ssh restart

Настройка авторизации по сертификату SSH — завершена!

Как настроить SSH сертификаты для входа на Ubuntu сервер и вариант исправить ошибку SSH Server refused our key , обсуждалось в этой статье. Я надеюсь, что теперь вы сможете настроить вход на сервер и клиент SSH с использованием сертификатов. Однако, если вы столкнетесь с каким-то проблемами при настройке сервера и клиента SSH, не стесняйтесь написать в комментариях. Я постараюсь помочь.

Сетевые настройки SSHv2

Сетевых настроек будет много, но большинство из них тривиальны – “что использовать” и “как фильтровать трафик”, поэтому по разделу на каждую заводить смысла нет.

Блок будет выглядеть примерно так:

Port 22 AddressFamily inet IgnoreRhosts yes UseDNS no ListenAddress x.x.x.x TCPKeepAlive yes #VerifyHostKeyDNS no #UseRoaming no

Часть настроек понятна – например Port 22 привязывает сервис SSH к указанному номеру порта, который можно при необходимости изменить – как минимум, чтобы боты-подбиратели-паролей не стучались, а ListenAddress явно указывает, на каких L3-адресах принимать запросы на подключение (ограничение актуально в случае нескольких адресов и/или сетевых интерфейсов, либо в сценарии “у хоста могут появляться на ходу новые сетевые интерфейсы, и это не значит, что на них надо ждать SSH-подключений”). Другие же настройки менее очевидны.

AddressFamily inet говорит о том, что мы будем ждать подключений только по IPv4. Если у вас используется IPv6 и подключения к SSH-серверу возможны по нему – добавьте AddressFamily inet,inet6.

TCPKeepAlive yes будет нужен, чтобы на сетевом уровне определять отключившихся пользователей и прекращать их сеансы. Выключение этого механизма, которое иногда рекомендуется “для экономии трафика” (слёзы, а не экономия) приведёт к ситуации, когда ssh не сможет в ряде случаев понять, что пользователь не просто неактивен, а уже никогда не сможет продолжить работу в данной сессии. Поэтому включаем.

IgnoreRhosts yes отключает древний механизм создания списка узлов (обычно в ), с которых возможен вход без аутентификации.

UseDNS no будет нужна, чтобы отключить проверку PTR-записи у подключающегося абонента – помимо того, что во внутренней сети, да и при подключении из внешних тоже наличие PTR совершенно необязательно, данная мера лишь замедляет подключение, а уровень безопасности не поднимает – максимум, что делает – пишет в журнал warning про “подключающийся не сказал своё настоящее FQDN-имя”. Хотя возможна ситуация, когда проверка эта включена, а DNS на узле не работает (например, указывает на неправильный IP-адрес DNS-сервера) – в этом случае возможен сценарий, что подключиться к узлу не получится. Но это совсем не “защитная мера” а, скорее, ещё одна причина отключать эту проверку, т.к. из-за неё, получается, растёт количество задействованных подсистем, а следовательно падает общая надёжность работы системы.

VerifyHostKeyDNS no отключает механизм SSHFP, который практически не используется в сетях, а вот запросы на тему “а есть ли такая экзотическая запись в вашем DNS” – отправляются. Конечно, если у вас в сети SSHFP используется, то отключать его не надо. Это по своей логике клиентская настройка, но почему-то иногда встречаются мысли “включить её на сервере”. Я её добавил в этот список и закомментировал, чтобы подчеркнуть данный момент – не нужно в настройках сервера эту опцию указывать.

UseRoaming no выключает поддержку роуминга – экспериментального расширения OpenSSH, которое должно было обрабатывать сценарии вида “начал админить из одного места, потом перешёл в другое и продолжил оттуда”. По факту функционал этот оказался никому не нужен и никаких прорывных нововведений не добавил, а вот проблемы безопасности – вплоть до уязвимостей с PoC – принёс. Поэтому в явном виде отключаем. Как и предыдущий параметр – клиентский, т.е. здесь приведён потому что опять же в ряде гайдов пишется “выключите везде, и на клиенте, и на сервере”. Это не так, только на клиенте.