SSH авторизация по сертификатам через Putty

SSH (secure shell, безопасная оболочка) представляет собой шифрованный протокол для администрирования и взаимодействия между серверами. Во время работы с сервером Ubuntu вы, скорее всего, будете проводить большую часть времени в вашем терминале, подключенном через SSH к вашему серверу.

Загружаем ключ ssh на сервер

Теперь нужно скопировать созданный нами ключ на сервер. Для этого подключаемся к ssh с помощью следующей команды:

ssh-copy-id [email protected]

Команда “ssh-copy-id” скопирует ключ на ваш сервер, в папку .ssh. Далее все как обычно, имя под которым вы входите по ssh и ip вашего сервера.

Теперь пробуем войти по ssh без ввода пароля. А если вдруг по какой то причине ключ ssh сам не смог скопироваться, нам нужно сделать это вручную. Для этого наберите команду:

cat ~/.ssh/id_ | ssh [email protected] «mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys»

Не забудьте поменять в команде [email protected] на свои данные.

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

Загружаем ключ ssh на сервер

sudo nano /etc/ssh/sshd_config

В конфигурационном файле найдите строку:

PasswordAuthentication yes

И замените слово “yes” на “no”. Возможно, эта опция будет закомментирована, вам нужно убрать решетку “#” раскомментировав ее. После чего сохраните конфиг и перезагрузите сервис ssh командой:

sudo service ssh restart

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

Настройка ssh клиента

В Debian настройки клиентской части ssh делятся на глобальные и пользовательские. Глобальные клиентские настройки находятся в файле /etc/ssh/ssh_config и применяются ко всем пользователям. Пользовательские настройки могут находиться в домашнем каталоге пользователя, в ~/.ssh/config и применяются к одному пользователю. Файл пользовательских настроек не создаётся автоматически в отличие от файла глобальных настроек клиентской части ssh. Для большинства выполняемых задач подойдут настройки по умолчанию, но для удобства использования, так сказать для тюнинга или для выполнения нестандартных задач клиентские настройки изменяются. Рассмотрим вкратце некоторые из этих настроек. Полезно помнить о приоритетах настроек: высший приоритет имеют ключи командной строки, затем следуют настройки пользователя, а после них используются глобальные настройки клиентской части.

Параметр Host. Ограничивает множество хостов, к которым применяются последующие (до ближайшей новой директивы Host) директивы, по указанным шаблонам (хост должен соответствовать хотя бы одному шаблону). Шаблон, состоящий из одного символа *, соответствует любому хосту. Под хостом в данном контексте понимается аргумент имя_хоста передаваемый в командной строке (т.е. никаких преобразований перед сравнением не выполняется).

Параметр HostName. Устанавливает соответствие между псевдонимами, сокращениями и настоящими именами хостов. По умолчанию используется имя, передаваемое в командной строке. Допустимо непосредственное указание IP-адресов.

Параметр Port. Порт на удалённой машине, к которому следует подключаться. Значение по умолчанию — 22

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

В качестве примера я создам файл пользовательских настроек /home/selifan/.ssh/config следующего содержания:

Читайте также:  Как разделить жёсткий диск в Windows и macOS

Host sunup

HostName

Port 2203

User andrey

Host windbag

HostName

Port 2280

Настройка ssh клиента

User joker

Host

HostName

Port 2222

User forester

Теперь при подключении к компьютерам , windbag или по ip адресу мне не нужно вспоминать, ни имя пользователя, ни ssh порт подключения, достаточно после ssh набрать имя сервера. Просто и удобно! Описания всех параметров, значений и некоторых примеров находятся в man ssh_config. Продолжаем настраивать SSH и читаем «Генерация ключей SSH».

Помните, что у нас вы можете не только купить готовый сайт или заказать его разработку, но и подобрать подходящий тариф поддержки сайта, заказать продвижение сайта в поисковых системах, а так же зарегистрировать домен в одной из двухсот доменных зон и выбрать недорогой тариф хостинга! Айтишник РУ

Об авторе:

Меня зовут Андрей Золкин. Из более, чем пятнадцати лет работы в сфере информационных технологий, десять лет работаю с системами, базирующимися на открытом исходном коде. На страницах сайта веду блоги по CMC Joomla и Debian GNU/Linux.

Ещё статьи о Debian

    • SSH Подключение с использованием открытого ключа…

      Для подключения с авторизацией по открытому ключу сначала нужно сгенерировать секретный ключ на стороне клиента. Делаем это с правами обычного пользователя: $ ssh-keygen –t rsa В процессе генерации пары ключей сначала будет предложено ввести желаемое название…

    • Опции

      Ниже я привожу список этих опций сгруппированных по типу — не так как в man — странице. Формат конфигурационного файла не сложный. Строки начинающиеся с символа # являются комментариями. Все остальные строки это директивы,…

    • Изменяем приветствие в SSH Debian

      Все, кто совершал вход в систему Debian через консоль или посредством SSH, видели следующее сообщение: The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described…

    • Настройка FTP сервера в Debian 5 (Lenny)

      В этой статье я опишу настройку FTP сервера на базе Debian 5 (Lenny). Будем использовать vsftpd. VSFTPD (Very Secure FTP Daemon) — как следует из названия, очень защищённый демон FTP, с хорошей производительностью, поддерживаются: IPv6,…

    • Настройка сети в Debian 9

      В этой статье я опишу простую настройку сети для сервера под управлением ОС Debian 9 (Stretch). Эта статья является переработкой моей более ранней статьи «Настройка сети в Debian». Она была справедлива для версий старше Debian 9. В Debian 9 многое…

    • Установка Debian

      Эта статья об установке операционной системы Debian GNU/Linux. Тема статьи достаточно обширна и это скорее тема для книги, нежели для статьи. Мне бы хотелось сделать статью «на вырост», т. е. со временем дополняя её ссылками на другие…

Используемые источники:

  • -ssh-ubuntu-16-04
  • -debian/
  • -servera/ustanovka-i-nastroyka-ssh-ubuntu

Импортируем закрытый ключ в PuTTY

PuTTY – прекрасный и наверное самый лучший SSH клиент для масдая. Который работает без нареканий и обладает всем необходимым функционалом. Бесплатный. Всё в нём хорошо. Но именно на этом поприще они решили отличиться и добавить чуть-чуть геморроя в процесс.

Вместе с PuTTY поставляется утилита PuTTYgen (PuTTY Key Generator).

Импортируем закрытый ключ в PuTTY
  1. Запускаем PuTTYgen
  2. Нажимаем кнопку Load
  3. Тип файлов выбираем All Files, выбираем свой текстовичок
  4. Видим сообщение об успешном импорте ключа. При желании можно указать комментарий ( Key comment)
  5. Жмём кнопку Save private key, соглашаемся с отсутствием пароля у ключа

Шаг — Аутентификация на сервере Ubuntu с использованием ключей SSH

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

Читайте также:  Особенности переноса Windows 10 с hdd на ssd

Процесс входа выглядит так же:

  • ssh username@remote_host

Если вы заходите на удалённый хост по SSH в первый раз, вы можете увидеть вывод следующего вида:

ВыводThe authenticity of host ‘ ()’ can’t be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

Это означает, что ваш локальный компьютер не узнал удалённый хост. Напечатайте “yes” и нажмите ENTER для продолжения.

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

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

Подключение по ключам

Для Linux

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

Подключение по ключам

1. В терминале выполните команду:

ssh-keygen

2. Программа спросит, куда нужно сохранить ключи.

Generating public/private rsa key file in which to save the key (/home/demo/.ssh/id_rsa):

Подключение по ключам

3. Чтобы сохранить ключи в домашнюю директорию .ssh/id_rsa, нажмите Enter.4. Программа запросит пароль для ключа — passphrase. Нажмите Enter, чтобы пропустить этот шаг. Иначе пароль нужно будет вводить при каждом соединении с использованием ключа.

Enter passphrase (empty for no passphrase):Enter same passphrase again:

5. Приватный и публичный ключи созданы.

~/.ssh/id_rsa — приватный ключ.~/.ssh/id_ — публичный ключ.

Подключение по ключам

6. Чтобы загрузить публичный ключ на сервер в файл ~/.ssh/authorized_keys, запустите на локальном компьютере команду:

ssh-copy-id -i /home/demo/.ssh/id_ [email protected]

Для Windows

SSH-Windows-клиент PuTTY умеет генерировать приватный и публичный ключи пользователя для их применения при подключении по SSH.

Подключение по ключам

Для этого используется поставляемая в комплекте утилита

1. При запуске утилиты нажмите кнопку “Генерировать”.2. Программа предложит вам подвигать мышью для создания случайной последовательности данных, затем генерируются ключи.3. После создания ключи нужно сохранить на компьютер в виде текстовых файлов (Пункт “Сохранить сгенерированные ключи”, кнопки “Открытый ключ” и “Личный ключ” соответственно для публичного и приватного ключей).

4. Наверху справа в поле “Ключ” будет виден текстовый дамп публичного ключа для сохранения на удаленном сервере (хосте). 5. Для этого на сервере в домашнем каталоге создайте папку “.ssh”, а внутри нее — файл “autorized_keys”. 6. Отредактируйте этот файл любым текстовым редактором (например, mcedit) и сохраните туда дамп ключа с экрана утилиты

7. После этого в самой программе PuTTY укажите имя пользователя для автовхода:

Подключение по ключам

8. Подключите в файл SSH приватный ключ, предварительно сохраненный в утилите :

9. После выполнения этих операций соединение с удаленным сервером по протоколу SSH произойдет без ввода пароля за счет пары публичный + приватный ключ:

Мы рекомендуем использовать пару приватный+публичный ключ как самый безопасный способ соединения по SSH.

Настройка обмена ключами / создания ключевого материала

Вариантов DH, или алгоритма Диффи-Хеллмана-Меркля – множество. Не углубляясь в данной статье в матчасть по самому алгоритму, посмотрим, как нам можно укрепить фронт с этой стороны.

Читайте также:  Исправление ошибки «Служба аудио не запущена в Windows»

Обмен ключами и совместная генерация ключевого материала для конкретной сессии – очень серьёзная тема в безопасности. Наша задача – избежать варианта, когда у нас будет возможен сценарий “аутентификация стойкая, а обмен ключами нет”.

Посмотрим, как сейчас у нас настроен DH в SSH на Cisco IOS:

atraining#sh ip ssh | inc Diffie

Minimum expected Diffie Hellman key size : 1024 bits

Плохо. Надо не ниже 2048 бит. Задаём это командой:

atraining(config)#ip ssh dh min size 2048

2048 бит – это 14я группа по RFC 3526. Можно поставить и 16ю группу, это 4096 бит – так ещё лучше, но надо дополнительно проработать вопрос совместимости со стороны клиентского ПО. Потому что поддержка 1й и 14й DH-групп есть везде, это стандарт по RFC 4253 – а вот остальные MODP-группы DH поддерживаются опционально. Главное, на самом деле, отсечь 1, 2 и 5 группы – наша настройка это и делает.

В варианте sshd нам надо будет добавить в конфигурацию строчку вида:

KexAlgorithms diffie-hellman-group14-sha1

Можно добавить туда и другие алгоритмы, если есть поддержка их со стороны клиента – например, curve25519-sha256. Главное – ограничить выбор, чтобы нельзя было согласовать “слабые” варианты. “Усиленный” вариант будет выглядеть, например, так:

KexAlgorithms [email protected],diffie-hellman-group18-sha512,diffie-hellman-group16-sha512

Здесь и длина ключа RSA серьёзная – 8192-4096 бит, и хэш-алгоритмы тоже используются “с запасом”. Если есть техническая возможность – имеет смысл использовать подобные настройки.

Зачастую предлагается заменить diffie-hellman-group14-sha1 на diffie-hellman-group-exchange-sha256 – мол, “там же SHA-2, это круче, чем SHA-1”. Это так, но diffie-hellman-group-exchange-sha256 – это “любая DH-группа, а целостность – SHA-2”. Т.е. уходит критерий “минимальная битовая длина”, а он важен. SHA-2 тут не особо даст плюсы – потому что предположить существование атаки, которая “на лету” в момент DH-обмена успевает подделать SHA-1 пока трудно.

Весь комплект EC-вариантов от NIST – ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521 – лучше не использовать вообще; помимо известных вопросов к NIST есть и новые предположения – впрочем, это тема для отдельной статьи, потому что тема выбора эллиптических кривых достаточно актуальна.

Алгоритмы выбрали – надо настроить вопрос обновления ключевого материала, он же rekeying.

Будет не очень хорошо, если всегда будет выполняться правило “Одна сессия = один набор битового материала после стартового обмена ключами”. Есть целый класс потенциальных атак, начинающихся с условия “надо набрать не менее N байт данных, зашифрованных этим методом/ключом”. Поэтому лучше, если сессия или продолжительная, или в ней передаётся много данных, периодически менять ключи.

За это в sshd будет отвечать настройка RekeyLimit. Она действует только для SSHv2, и по умолчанию имеет значение “отключено”:

RekeyLimit default none

Мы выставим её в разумное значение “менять ключи, когда передадим очередной гигабайт данных” – это будет выглядеть так:

RekeyLimit 1G

Очень интересным моментом является то, что изначально в стандарте SSH не было жёстко прописано, кто из пары клиент-сервер должен запрашивать rekeying. То есть по идее, могут оба. И настройка долгое время была “клиентской”, то есть в клиентском ПО можно было выставить “через сколько минут/мегабайт запросить”, а у сервера это как-то не предполагалось. В результате в части руководств прямо указывается, что сервер не может делать rekeying. Может.

В случае Cisco IOS (кстати, только в некоторых IOS) настройка параметров rekey делается командой:

atraining(config)#ip ssh rekey

с параметром time или volume. Заметьте, или-или.

В конфигурации могут быть параметры KeyRegenerationInterval и ServerKeyBits – они используются только для SSH 1.x, смело удаляйте; SSHv2 их не использует.

ОК, с этим разобрались – теперь от подтверждения подлинности хоста перейдём к генерации криптографических данных для каждой сессии.