Введение
SSH-ключи позволяют авторизоваться на виртуальном сервере более безопасным, чем используя пароль, путем – при помощи SSH. В то время как сервер можно взломать, если использовать метод подбора пароля (брутфорс), расшифровать SSH-ключи только этим способом практически невозможно. SSH представляет из себя пару ключей, один из которых открытый (публичный), а другой закрытый (или приватный, и он есть только у вас). Сначала вы помещаете файл с публичным ключом на свой SSH-сервер, а затем подключаетесь к серверу, используя приватный ключ. Корректная работа возможна только при наличии обоих ключей – и именно благодаря этому ваше сообщение будет безопасным, и при этом вам не нужно использовать пароль. Вы можете усилить безопасность такого способа авторизации, активировав для закрытого ключа запрос кодовой фразы.
Создаем ключи SSH
Ключи надо создавать на своем компьюетере, отправляя на сервер только публичный ключ.
Создаем ключ в Windows (на клиенте Putty) …
Готовим ключ в Putty. Для этого на клиенте Windows запускаем puttygen.exe.
Жмем Generate, водим мышкой до полной победы.
После генерации ключа по желанию добавляем пароль ключа (Key passphrase). Надо отметить, что с паролем на ключ у вас не выйдет сделать автологин — пароль все равно надо будет вводить! Зато не будет и головной боли, что кто-то упер ключ. Двухфакторная аутентификация (нужен и ключ и пароль от него).
Сохраняем открытый ключ (например, myServer_rsa.pub) и приватный (например, myServer_rsa.ppk). И тот и другой файлы храним, но приватный храним как зеницу ока! К тому же, приватный ключ (точнее, путь к нему) надо прописать в putty.
Копируем текст из поля вида»ssh-rsa AAA…….» в блокнот (для архива) либо сразу в файл ~/.ssh/authorized_keys (про файл см. ниже) на сервер Linux
Обратите внимание, текст должен быть вставлен в одну строку!
… или создаем ключ в Linux
$ ssh-keygen
Создаст два ключа (если запускать без параметров и соглашаться с default):
1) приватный .ssh/id_rsa
2) публичный .ssh/id_rsa.pub
Содержимое файла .ssh/id_rsa.pub копируется на удаленный сервер (к которому мы будем подключаться)
Полезные колючи ssh-keygen:
Последняя опция создаст приватный ключ и публичный
Это необходимо, если вы собираетесь администрировать несколько серверов:
$ ssh-keygen -t rsa -b 4096 -f /home/admin/.ssh/id_rsa_1
$ ssh-keygen -t rsa -b 4096 -f /home/admin/.ssh/id_rsa_2
И создадим файл /home/admin/.ssh/config
Host host1
HostName host1_address
User user1
Port 22
IdentityFile /home/nitesh/.ssh/id_rsa_1
Host host2
HostName host2_address
User user2
Port 22
IdentityFile /home/nitesh/.ssh/id_rsa_2
После чего команда
$ ssh host2
будет использовать соответствующий приватный ключ.
Содержимое публичного ключа необходимо отправить на сервер, который будем в дальнейшем администрировать.
Настройка rkhunter (основанная на заведомо исправный значениях)
Получив некоторое представление о том, как rkhunter просматривает систему, можно указать файлы и приложения, которые нужно игнорировать или обрабатывать иначе во избежание ложных срабатываний.
Откройте конфигурационный файл rkhunter с привилегиями root:
Настройка уведомлений
Если почтовый сервер установлен локально, можно получать почту, войдя в систему как root:
Имейте в виду, почтовые программы настраиваются сразу при установке, потому их инсталляции нужно уделять особое внимание. Данная строка определяет программу и параметры отправки почты:
Данная строка определяет программу и параметры отправки почты:
Белый список известных файлов
Теперь нужно устранить предупреждения, сообщающие о том, что некоторые бинарные пакеты системы были заменены скриптами. Некоторые дистрибутивы (в том числе и Ubuntu) используют скриптовые версии файлов вместо их двоичных аналогов.
Приведенные ниже четыре файла были выведены в результате проверки rkhunter; их нужно внести в белый список с помощью параметра SCRIPTWHITELIST, чтобы rkhunter знал, что эти файлы безвредны:
Это позволит предотвратить ложные срабатывания при всех последующих проверках
Обратите внимание: эти белые списки необходимы только для определенных тестов; потому нужно отметить, что эти файлы не должны быть двоичными. Другие же изменения могут вызвать предупреждения (что является правильной работой программы)
Определенные файлы каталога /dev вызывают предупреждения rkhunter. Эти файлы содержат детали реализации, которые фактически не указывают на какие-либо нарушения. Они необходимы и поддерживаются дистрибутивом.
Итак, существует три предупреждения, которые нужно устранить. Первое предупреждение связано с обнаружением “подозрительного файла” в каталоге. Разместите в конфигурациях следующую строку, чтобы снять подозрения с данного файла:
Следующее предупреждение связано с тем, что в каталоге /dev обнаружен скрытый каталог. В этом каталоге находится предыдущий файл.
Последнее предупреждение вызвано скрытыми файлами. Это основные конфигурационные файлы, которые хранятся в этом каталоге, чтобы программы могли получать к ним доступ независимо от схемы разбиения и состояния монтирования.
Добавьте эти строки, чтобы внести эти файлы в белый список
Разрешение Root SSH-подключения
Следующий шаг – просто проверка утверждения. При запуске rkhunter проверяет этот параметр в конфигурационном файле и сравнивает его со значением в файле конфигурации SSHD.
Данная опция указывает, может ли root-пользователь устанавливать SSH-подключение. Многие методы обеспечения безопасности рекомендуют отключить root-логин. Если root-логин отключен, нужно установить значение “no”.
При необходимости подключаться по SSH нужно изменить значение на “yes”, чтобы rkhunter подтверждал такое соединение:
Сохраните изменения и закройте файл.
Сгенерировать пару ключей
Первый шаг — это генерация пары ключей. Обычно это делается на клиентской машине.
Например, на вашем ноутбуке.
Основная команда ssh-keygen создаст 2048-битную пару RSA ключей. Для
большей надёжности можно добавить флаг -b 4096
Выполните
ssh-keygen -b 4096
Чтобы сгенерировать ключ в /home/$(whoami)/.ssh
или
sudo ssh-keygen -b 4096
Чтобы сгенерировать ключ в /home/root/.ssh
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Нужно придумать имя ключа.
Я назову ключ
andrei-key101
а сохранять буду в текущую директорию.
Enter file in which to save the key (/root/.ssh/id_rsa): andrei-key101
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Нужно два раза ввести пароль. Если он вам нужен. Обычно нет.
Your identification has been saved in andrei-key101
Your public key has been saved in andrei-key101.pub
The key fingerprint is:
SHA256:abcd/abcdefghijklmnopqrstuvwxyz1234567890ab root@urn-su
The key’s randomart image is:
+——-+
|=o oo++ |
|= oo o. = o |
|+ |
|Oo=o . . |
|B+.o S . |
|+o.o |
|+.0. . |
|o+= . E |
|+=oo. . . |
+———+
Ключи готовы. Я сохранил их в текущую директорию поэтому увижу их сделав ls
ls
andrei-key101 andrei-key101.pub
Важно помнить, что если вы генерируете ключ для другого пользователя нужно
позаботиться о правильных правах доступа к этому ключу.
Создание и настройка файла конфигурации SSH
Чтобы ускорить процесс входа и оптимизировать поведение клиента SSH, можно создать и настроить файл конфигурации SSH .
В следующем примере показана простая конфигурация, которую можно использовать для быстрого входа на определенную виртуальную машину в качестве пользователя с помощью закрытого ключа SSH по умолчанию.
Создайте файл.
Изменение файла для добавления новой конфигурации SSH
Добавьте параметры конфигурации для виртуальной машины узла. В этом примере имя виртуальной машины — myvm, а имя учетной записи — azureuser.
Можно добавить конфигурации для дополнительных узлов, чтобы каждый из них мог использовать собственную пару ключей. Дополнительные параметры конфигурации приведены в описании файла конфигурации SSH.
Теперь, когда у вас есть пара ключей SSH и настроенный файл конфигурации SSH, вы можете быстро и безопасно входить на виртуальную машину Linux. При выполнении следующей команды служба SSH находит и загружает все параметры из блока в файле конфигурации SSH.
При первом входе на сервер с использованием ключа SSH команда запрашивает парольную фразу для этого файла ключа.
Проверьте, что вы подключились к нужному серверу
Будьте внимательны при вводе команд с клавиатуры. В некоторых случаях корпоративная сеть может привести к проблемам разрешения записи DNS.
Для того, чтобы убедиться в том, что вы подключаетесь к нужному домену, введите следующую команду, добавив в строке номер порта :
|
ssh -vT ‘-p 25000’ OpenSSH_7.1p2, OpenSSL 1.0.2g 1 Mar 2016 |
Шаг 6 — Разрешение других соединений
К этому моменту вы должны были разрешить все другие соединения, необходимые вашему серверу. Состав разрешаемых соединений должен соответствовать вашим конкретным потребностям. К счастью, вы уже знаете, как писать правила, разрешающие соединения по имени службы или номеру порта, поскольку мы уже делали это для SSH на порту . Также вы можете использовать это для следующих соединений:
- соединения HTTP на порту 80, которые используются веб-серверами без шифрования, с помощью команды или
- соединения HTTPS на порту 443, которые используются веб-серверами с шифрованием, с помощью команды или
Помимо указания порта или службы есть другие способы разрешить другие соединения.
Определенные диапазоны портов
С помощью UFW вы можете указывать диапазоны портов. Некоторые приложения используют для соединений не один порт, а несколько.
Например, чтобы разрешить соединения X11, которые используют порты -, нужно использовать следующие команды:
Когда вы указываете диапазоны портов с помощью UFW, вы должны указать протокол ( или ), к которому должны применяться эти правила. Мы не упоминали этого ранее, поскольку если протокол не указать, оба протокола будут разрешены, что подходит для большинства случаев.
Конкретные IP-адреса
При работе с UFW вы также можете указывать конкретные IP-адреса. Например, если вы хотите разрешить соединения с определенного IP-адреса, например с рабочего или домашнего адреса , вам нужно использовать опцию , а затем указать IP-адрес:
Также вы можете указать определенный порт, к которому IP-адресу разрешено подключаться. Для этого нужно добавить опцию , а затем указать номер порта. Например, если вы хотите разрешить IP-адресу подключаться к порту (SSH), нужно использовать следующую команду:
Подсети
Если вы хотите разрешить подсеть IP-адресов, вы можете указать маску сети с помощью нотации CIDR. Например, если вы хотите разрешить все IP-адреса в диапазоне от до , вы можете использовать следующую команду:
Также вы можете указывать порт назначения, к которому разрешено подключаться подсети . В качестве примера мы используем порт (SSH):
Подключения к определенному сетевому интерфейсу
Если вы хотите создать правило брандмауэра, применимое только к определенному сетевому интерфейсу, вы можете использовать для этого опцию «allow in on», а затем указать имя сетевого интерфейса.
Прежде чем продолжить, вам может понадобиться просмотреть сетевые интерфейсы. Для этого нужно использовать следующую команду:
В выделенной части результатов показаны имена сетевых интерфейсов. Обычно они носят имена вида или .
Если на вашем сервере имеется публичный сетевой интерфейс под названием вы можете разрешить трафик HTTP (порт ) для этого интерфейса с помощью следующей команды:
Это позволит вашему серверу принимать запросы HTTP из публичной части интернета.
Если вы хотите использовать сервер базы данных MySQL (порт ) для прослушивания соединений на интерфейсе частной сети (например, ), вы можете использовать следующую команду:
Это позволит другим серверам в вашей частной сети подключаться к вашей базе данных MySQL.
Запустить SSH в фоновом режиме
Существует несколько способов запустить ssh соединение в фоновом режиме — то есть освободим текущий терминал.
-L, screen, tmux, nohup
Мне запустить ssh фоном из скрипта помог nohup, поэтому начнём с него
nohup ssh user@host «cd scripts;python3 my_script.py $ARG1 $ARG2; exit» &
Для чего это было нужно: Python скрипт сначала
открывал одно ssh соединение из
subprocess
там выполнялась команда для запуска
мониторинга потребления памяти
и больше от этого соединения ничего было не нужно, зато необходимо было
выполнять новые соединения с нагрузкой из другого скрипта.
Чтобы уйдя из первого подключения не оборвать мониторинг потребления памяти
перед ssh нужно было добавить nohup, а в самом конце поставить &
Сведения о парах ключей
Парой ключей называются файлы открытого и закрытого ключей, которые используются в некоторых протоколах аутентификации.
При аутентификации SSH на основе открытого ключа используются асимметричные алгоритмы шифрования для создания двух файлов ключей, один из которых считается закрытым, а второй открытым. Файлы закрытых ключей выполняют функцию паролей, а значит, должны быть постоянно защищены. Если кто-то получит ваш закрытый ключ, он сможет войти от вашего имени на любой сервер с поддержкой SSH, к которому у вас есть доступ. Открытый ключ размещается на сервере SSH. Его можно свободно распространять, не компрометируя закрытый ключ.
Если на сервере SSH используется аутентификация с помощью ключей, сервер и клиент SSH сравнивают открытый ключ, связанный с предоставленным именем пользователя, с закрытым ключом. Если открытый ключ на стороне сервера не проходит проверку по закрытому ключу, сохраненному на стороне клиента, аутентификация не будет выполнена.
Многофакторную проверку подлинности можно реализовать с помощью пар ключей, введя парольную фразу при создании пары ключей (см. раздел о ниже). При аутентификации пользователю предлагается ввести эту парольную фразу. Она применяется вместе с закрытым ключом для аутентификации пользователя.
Шаг 1 — Создание пары ключей
Первый шаг — создание пары ключей на клиентской системе (обычно на вашем компьютере):
По умолчанию последние версии будут создавать 3072-битную пару ключей RSA, которая достаточно безопасна для большинства сценариев использования (вы можете также добавить к этой команде флаг для получения 4096-битного ключа).
После ввода команды вы должны увидеть следующее:
Нажмите ENTER, чтобы сохранить пару ключей в подкаталог домашнего каталога или укажите альтернативный путь.
Если вы ранее создали пару ключей SSH, вы можете увидеть следующую строку:
Если вы решите перезаписать ключ на диске, вы больше не сможете выполнять аутентификацию с помощью предыдущего ключа. Будьте осторожны при выборе варианта yes, потому что этот процесс уничтожает ключи, и его нельзя отменить.
Затем вы должны увидеть следующую строку:
Здесь вы можете ввести защищенный пароль, что настоятельно рекомендуется сделать. Пароль добавляет дополнительный уровень безопасности для защиты от входа в систему несанкционированных пользователей.
Вывод затем должен выглядеть примерно следующим образом:
Теперь у вас есть открытый и закрытый ключи, которые вы можете использовать для аутентификации. Наследующем шаге вам нужно разместить открытый ключ на сервере, чтобы вы могли использовать аутентификацию на базе ключей SSH для входа в систему.
Создание пары ключей SSH
SSH (Secure SHell) — это протокол, который позволяет безопасно авторизоваться в различные сервисы, подключаться к удаленным терминалам, передавать по шифрованным каналам информацию. Очень распрастранен при работе с репозиториями. Использует пару ключей — публичный и приватный.
Открывайте GitBash или терминал, вводите:
Если у вас будет ошибка: — создайте папку, выполнив команду:
После заходите в папку.
Для генерации ключа используется программа , она обычно установлена, в Windows встроена в GitBash.
Github рекомендует использовать ключ типа ed25519, так как этот алгоритм на данный момент самый безопасный, с коротким открытым ключом (68 символов, против 544 у RSA) и что важно — быстро работает. За тип ключа отвечает параметр
Длина ключа рекомендуется 4096 бит, при создании это параметр .
При генерации ключей , ключи по-умолчанию будут сохранены в папке текущего пользователя.
В итоге для запуска генерации ключа, выполните:
Вам будут заданы несколько вопросов:
-
Куда сохранить файл () — нажмите Enter и по умолчанию ключ будет назван и сохранится в .ssh папке профиля текущего пользователя. (в Windows папки пользователя в C:/Users, в macOs/Linux папка пользователя в /home)
-
-
Введите кодовую фразу () — опционально, кодовая фраза это элемент безопасности. Если ваш приватный ключ попадет в чужие руки, им не смогут воспользоваться пока не подберут кодовую фразу. Это даст вам больше времени для замены ключей и отказа от скомпрометированного ключа. Предлагаю в данный момент отказаться от ключевой фразы и просто нажать Enter.
-
Подтвердить кодовую фразу или ее отсутсвие, тоже нажав Enter.
В результате вам покажут рисунок вашего ключа:
Проверьте, на месте ли ключи, выведите список файлов в папке :
Вывод должен быть таким:
первый файл это приватный ключ, а второй с .pub это публичный.
Убедитесь, что у вас есть ключ, который используется
Команда ssh-add должна вывести длинную строку из цифр и букв. Если ничего не будет выведено на экран, вы должны сгенерировать новый SSH-ключ и связать его с GitLab.
| Замечание. В большинстве систем приватные ключи по умолчанию (, и ) автоматически добавляются к агенту аутентификации SSH. Вы не должны запускать , иначе вы перезапишите имя файла при генерации ключа. |
Получение детализации
|
ssh -vT ‘-p 25000’ … |
В этом примере у нас нет ключей для использования SSH. Значение «-1» в конце строки «identity file» означает, что SSH не может найти файла для использования. Ниже, строка «Trying private key» также показывает, что файл не найден. Если бы файл был найден, значение в этих строках было бы «1», и «Offering public key» соответственно.
|
ssh -vT ‘-p 25000’ … |
Общие сведения о SSH и ключах
SSH — это протокол зашифрованного подключения, обеспечивающий безопасный вход в систему через незащищенные соединения. SSH — это протокол подключения по умолчанию для виртуальных машин Linux, размещенных в Azure. Хотя протокол SSH и обеспечивает зашифрованное подключение, использование паролей для соединений SSH все же сохраняет уязвимость виртуальной машины к атакам методом подбора. Мы рекомендуем подключаться к виртуальной машине по SSH с помощью пары «открытый ключ — закрытый ключ», также известных как ключи SSH.
-
Открытый ключ размещается на виртуальной машине с ОС Linux.
-
Закрытый ключ остается в локальной системе. Его нужно защищать и нельзя никому предоставлять.
При использовании клиента SSH для подключения к виртуальной машине Linux (с открытым ключом) удаленная виртуальная машина проверяет, имеется ли у клиента правильный закрытый ключ. Если у клиента есть закрытый ключ, он получает доступ к виртуальной машине.
В зависимости от политик безопасности организации вы можете использовать отдельную пару из открытого и закрытого ключей для доступа к нескольким виртуальным машинам и службам Azure. Не нужно выделять отдельную пару ключей для каждой виртуальной машины или службы, к которой необходим доступ.
Открытый ключ можно предоставить любому пользователю, но только вы (или ваша локальная инфраструктура безопасности) должны иметь доступ к вашему закрытому ключу.
Копирование открытого ключа на сервер
Добавить открытый ключ на сервер можно несколькими способами.
Примечание: На каждый сервер можно добавить неограниченное количество SSH-ключей.
Добавить открытый ключ на сервер можно несколькими способами. Рассмотрим несколько из них, начиная с простейшего. Выберите самый удобный для вас метод и используйте его, чтобы добавить открытый ключ на сервер.
Копирование ключа с помощью ssh-copy-id
Если на локальном компьютере установлена утилита ssh-copy-id, с её помощью вы можете быстро добавить открытый ключ на удалённый сервер. Обычно (но не всегда) утилита ssh-copy-id включена в пакет OpenSSH.
Чтобы узнать, есть ли эта утилита на локальном компьютере, просто попробуйте запустить её. Если она не установлена, на экране появится ошибка:
Вы можете установить её или воспользоваться другим методом копирования ключа.
В команде ssh-copy-id нужно указать IP-адрес или доменное имя, а также имя пользователя, для которого нужно добавить эти SSH-ключи.
Команда может вернуть:
Это значит, что локальный компьютер не узнаёт удалённый сервер, потому что ранее SSH-ключи никогда не использовались при аутентификации. Чтобы продолжить, введите yes и нажмите RETURN.
Утилита сканирует локальную учетную запись пользователя в поисках открытого ключа, id_rsa.pub. Когда она найдёт нужный файл, она запросит пользователя удалённого сервера.
Введите пароль и нажмите RETURN. Утилита подключится к аккаунту пользователя на удалённом хосте и установит открытый ключ; это происходит путём копирования содержимого файла id_rsa.pub в файл .ssh/authorized_keys в домашнем каталоге удалённого пользователя.
Если копирование прошло успешно, на экране появится:
Теперь открытый ключ добавлен в файл authorized_keys удалённого пользователя, и сервер сможет принять закрытый ключ для аутентификации.
Примечание: Скопировав ключ на удалённый сервер, можете переходить к разделу «Аутентификация с помощью SSH-ключей».
Копирование ключа через SSH
Если на вашем сервере нет утилиты ssh-copy-id, но есть парольный SSH-доступ к серверу, вы можете установить открытый ключ с помощью SSH-клиента.
Для этого нужно вывести открытый ключ на локальном компьютере и передать его по SSH на удалённый сервер. На удалённом сервере нужно создать каталог ~/.ssh (если такого каталога нет), а затем добавить открытый ключ в файл authorized_keys в этом каталоге. Используйте перенаправление потока >>, чтобы вставить ключ в файл authorized_keys (если ранее вы добавляли SSH-ключи на удалённый сервер, такой файл уже существует; при этом ключи не будут переписаны новыми ключами).
Если вы не изменили название файла открытого ключа по умолчанию (id_rsa.pub), используйте эту команду:
Команда может вернуть такое сообщение:
Это значит, что локальный компьютер не узнаёт удалённый сервер, потому что ранее SSH-ключи никогда не использовались при аутентификации. Чтобы продолжить, введите yes и нажмите RETURN.
Команда запросит пароль удалённого пользователя:
Введите пароль и нажмите RETURN. Если команда выполнена успешно, она не вернёт никакого вывода. Ключ id_rsa.pub будет добавлен в файл authorized_keys.
Примечание: Скопировав ключ на удалённый сервер, можете переходить к разделу «Аутентификация с помощью SSH-ключей».
Копирование ключа вручную
Также вы можете добавить открытый ключ на удалённый сервер вручную. Для этого нужно авторизоваться на удалённом сервере как пользователь, для которого предназначен этот ключ.
Процесс не меняется: вам нужно взять открытый ключ на локальной машине и добавить его в .ssh/authorized_keys в домашнем каталоге удалённого пользователя.
Войдите на удалённый сервер:
При этом может появиться сообщение:
Это значит, что локальный компьютер не узнаёт удалённый сервер, потому что ранее SSH-ключи никогда не использовались при аутентификации. Чтобы продолжить, введите yes и нажмите RETURN.
После этого будет запрошен пароль удалённого пользователя:
Создайте каталог .ssh в домашнем каталоге удалённого пользователя, если такого каталога пока что нет:
Вернитесь на локальную машину и запросите открытый SSH-ключ:
Скопируйте вывод в буфер, затем откройте файл authorized_keys в текстовом редакторе:
Вставьте в него открытый ключ, а затем сохраните и закройте файл (Esc, a, a).
Открытый ключ SSH теперь добавлен на удалённый сервер.
Установление SSH-подключения к виртуальной машине с помощью клиента SSH
С помощью открытого ключа, развернутого на виртуальной машине Azure, и закрытого ключа в локальной системе установите SSH-подключение к виртуальной машине, используя ее IP-адрес или DNS-имя. Замените azureuser и myvm.westus.cloudapp.azure.com в приведенной команде, указав имя пользователя администратора и полное доменное имя (или IP-адрес).
Если при создании пары ключей вы указали парольную фразу, введите ее при появлении запроса во время входа в систему. (Сервер добавляется в папку . Если не изменять открытый ключ на виртуальной машине Azure или не удалять имя сервера из файла , запрос на подключение повторно не отображается.)
Если виртуальная машина использует политику доступа JIT, запросите доступ, прежде чем подключиться к виртуальной машине. Дополнительные сведения о политике JIT см. в статье Управление доступом к виртуальным машинам с помощью JIT-доступа.
решить
- 1. Запустите команду ssh-keygen, чтобы сгенерировать файл ssh-ключа ** (рекомендуется вернуться в каталог ~) **
- 2. При генерации ssh-ключа вам будет предложено ввести ключ и кодовую фразу для файла.Я предлагаю вам нажимать Enter и все время передавать его.
Тогда будет Создайте эти три файла.
3. Добавьте значения, связанные с ssh, на главную страницу настроек github.
Скопируйте содержимое файла ключей SSH id_rsa.pub, созданного командой на рисунке выше, в ключ SSH, затем установите заголовок id_rsa и, наконец, нажмите Добавить ключ SSH, чтобы сохранить значение ключа SSH.
Если отображается содержимое, показанное на рисунке выше, настройка SSH завершена.
5. Повторно выполните команду развертывания и убедитесь, что код push в порядке!
ssh-copy-id
Я предпочитаю использовать с флагом -i и задавать путь до нужного ключа
sudo ssh-copy-id -i ~/.ssh/andrei-key.pub andrei@192.168.0.2
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: «/home/andrei/.ssh/andrei-key.pub»
The authenticity of host ‘192.168.0.2 (192.168.0.2)’ can’t be established.
ECDSA key fingerprint is SHA256:abcdefgh1234567890abcdefgh1234567890abc+def.
Are you sure you want to continue connecting (yes/no/)?
Введите yes
Are you sure you want to continue connecting (yes/no/)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys
andrei@192.168.0.2’s password:
Введите пароль
Number of key(s) added: 1
Now try logging into the machine, with: «ssh ‘andrei@192.168.0.2′»
and check to make sure that only the key(s) you wanted were added.
Теперь на хосте 192.168.0.2 в файле
/home/andrei/.ssh/authorized_keys
появилась новая запись вида
ssh-rsa AAAAB3NzaC1y … lseP/jXcq … Uydr/2CwQ &hellip ++TpY19pHqD/AnhL … Az62T/Ipyx … 8U2T andrei@host.andrei.com
Знак … заменяет длинные последовательности случайных символов для экономии места.
Проверить ключ можно командой
ssh -i ~/.ssh/mykey user@host
В нашем случае
ssh -i ~/.ssh/andrei-key andrei@192.168.0.2
Если вы не задавали пароль для ключа, то попадёте на удалённый хост без лишних движений
Last login: Sun Jan 10 16:48:27 2021 from 192.168.0.1
Добавление публичного ключа в профиль на GitHub
Кратко про ключи. С помощью публичного ключа, каждый может зашифровать информацию, расшифровать может только владелец приватного ключа, поэтому приватный ключ нельзя передавать, отправлять или хранить в открытом виде. Желательно пару ключей дополнительно скопировать на отдельный носитель, на случай потери ключа на компьютере.
В GitHub для работы с репозиториями скопируйте публичный ключ, одним из способов:
в GitBash выполните команду:
это скопирует публичный ключ в буфер обмена.
если данная команда не работает, откройте файл id_ed25519.pub в любом текстовом редакторе, и скопируйте все содержимое файла, публичный ключ выглядит так:
Переходите на страницу управления ключами:
-
Нажимайте не кнопку
-
В поле вставьте скопированный ключ:
-
В поле можете вставить название ключа, пригодится если у вас будет в профиле более одного ключа. Поможет их различать.
-
Нажимайте кнопку .
Теперь можно использовать SSH доступ к вашим репозиторияем!
