SSH доступ с помощью RSA ключей

Есть два способа генерации ключей. На стороне сервера или на стороне клиента. То есть вы генерируете ключи на сервере и оправляете клиенту приватный ключ или вы делаете все наоборот и отправляете серверу публичный ключ.

Ошибки при отсутствии SSH ключа

При отсутсвии публичного ключа для доступа к GIT репозиторию возникнет ошибка:

git@github.com: Permission denied (publickey). fatal: Could not read from remote repository.

А если это связано со скриптом, который запускается при инициализации GIT репозитория и в котором указаны дальнейшие инструкции, то могут посыпаться и другие ошибки:

ERROR: Can’t find a suitable configuration file in this directory or any parent. Are you in the right directory?

На русском: Не удается найти подходящий файл конфигурации в этом каталоге или любом родителе. Вы в правильном каталоге?

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

Для исправления ошибки Permission denied (publickey) необходимо занести публичный ssh ключ, который сгенерирован для компьютера, с которого осуществляется доступ на сайт

Запуск SSH-клиента

Если у вас один из вари­ан­тов линук­са, BSD, UNIX или Мак — поздрав­ля­ем, SSH-клиент у вас уже есть. Для его запус­ка доста­точ­но набрать в команд­ной стро­ке что-то подобное:

ssh [email protected]

Здесь login — это имя поль­зо­ва­те­ля, под кото­рым вы хоти­те зай­ти на сер­вер, а — IP-адрес это­го сер­ве­ра. Чаще все­го исполь­зу­ет­ся 22 порт, но ино­гда эта настрой­ка может меняться.

Запуск SSH-клиента

Порт — это что-то вро­де номе­ра марш­рут­ки, кото­рая идёт по горо­ду. Все при­вык­ли, что если нуж­но «дое­хать» до SSH, то садят­ся на марш­рут­ку номер 22. Но ино­гда началь­ник город­ско­го транс­пор­та (адми­ни­стра­тор) может поме­нять номер, тогда вме­сто 22-й марш­рут­ки нуж­но будет садить­ся, напри­мер, на 320-ю.

Читайте также:  Как открыть скачанную программу на Маке (Mac OS)

У Вин­до­ус нет встро­ен­но­го SSH-клиента, поэто­му нуж­но ска­чать его отдель­но. Чаще все­го выби­ра­ют PyTTY — SSH-клиент с гра­фи­че­ской обо­лоч­кой, в кото­рой мож­но настра­и­вать пара­мет­ры соединения:

Мини­маль­но нуж­но ука­зать адрес сер­ве­ра, 22 порт уже напи­сан по умолчанию.

Добавление ключа SSH в учетную запись GitHub

Мы сгенерировали у себя на компьютере закрытый ключ SSH и добавили его в ssh-агент. Теперь нам необходимо добавить SSH ключ в учетную запись GitHub.

Сейчас нам необходимо скопировать SSH ключ в буфер обмена.

Способов есть несколько, но я же вам предлагаю следующее решения для Windows 10: введите команду ниже.

cat ~/.ssh/id_

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

Теперь зайдите на вашу страницу GitHub Settings.

Перейдите во вкладку SSH and GPG keysи нажмите на кнопку New SSH key для добавления SSH ключа в вашу учетную запись GitHub.

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

В поле Key добавьте свой ssh-ключ, который вы скопировали в буфер обмена на предыдущем шаге.

Нажмите Add SSH key.

Для подтверждения вам потребуется ввести свой пароль от учетной записи GitHub.

На этом настройка SSH для вашего устройства завершена, теперь вы можете работать с git без ввода пароля от своей учетной записи.

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

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

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

Читайте также:  Как настроить IP-маршрутизацию в Windows 2008 Server

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

Посмотрим, как сейчас у нас настроен 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 их не использует.

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