Определение
SSH использует криптографию с открытым ключом для аутентификации удаленного компьютера и позволяет ему при необходимости аутентифицировать пользователя.
Есть несколько способов использовать SSH; один из них — использовать автоматически сгенерированные пары открытого и закрытого ключей, чтобы просто зашифровать сетевое соединение, а затем использовать аутентификацию по паролю для входа в систему. Другой — использовать сгенерированную вручную пару открытого и закрытого ключей для выполнения аутентификации, позволяя пользователям или программам входить в систему без необходимости указывать пароль. В этом сценарии любой может создать соответствующую пару разных ключей (открытый и закрытый). Открытый ключ размещается на всех компьютерах, которые должны разрешить доступ владельцу соответствующего закрытого ключа (владелец хранит закрытый ключ в секрете). Хотя аутентификация основана на закрытом ключе, сам ключ никогда не передается по сети во время аутентификации. SSH только проверяет, владеет ли то же лицо, предлагающее открытый ключ, соответствующим закрытым ключом
Во всех версиях SSH важно проверять неизвестные открытые ключи , т. Е
, прежде чем принимать их как действительные. Принятие открытого ключа злоумышленника без проверки авторизует неавторизованного злоумышленника как действительного пользователя.
Сгенерировать пару ключей
Первый шаг — это генерация пары ключей. Обычно это делается на клиентской машине.
Например, на вашем ноутбуке.
Основная команда 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
Важно помнить, что если вы генерируете ключ для другого пользователя нужно
позаботиться о правильных правах доступа к этому ключу.
Конвертация сертификатов
Рассмотрим простой пример: вы достали из
базы данных
сертификат
MIIC4jCCAc … A7A6Rpt8V9Q==
, но он не отформатирован и не проходит валидацию
Сертификат, конечно, длиннее, я поставил троеточие для экономии места и вашего времени.
Выполните
echo ‘MIIC4jC … 7A6Rpt8V9Q==’ | base64 -d | openssl x509 -inform der
Либо, если вам нужно работать с файлами — сохраните исходный сертифика в фай
raw_cert
echo MIIC4jC … 7A6Rpt8V9Q== > raw_cert
cat raw_cert | base64 -d | openssl x509 -inform der > cert
cat cert
——BEGIN CERTIFICATE——
MIIC4jC … 7A6Rpt8V9Q==
——END CERTIFICATE——
Такого же результата можно было добиться аккуратно добавив ——BEGIN CERTIFICATE—— в начало
и ——END CERTIFICATE—— в конец файла, но не всегда всё так просто.
Настройки безопасности клиента OpenSSH
Доступно множество клиентов SSH, поэтому рассказать о каждом из них в одной статье невозможно. Остановимся подробнее на инструменте клиента OpenSSH.
Конфигурация клиента
Клиент OpenSSH можно настроить тремя способами. Они обрабатываются по порядку и проверяются для каждого доступного параметра конфигурации. Выбирается первый подходящий.
- Настройки задаются через командную строку;
- Через файл конфигурации в домашней директории ();
- Через файл конфигурации для всех пользователей ().
Допустим, есть настройка А. Она задана для всей системы (3 способ) со значением «True». Пользователь michael установил для нее значение «False» (2 способ). В этом случае второе значение в приоритете, т.к. оно рассматривается перед настройками всей системы.
Просмотр активных настроек
Помните, как мы просматривали настройки для сервера ()? У клиента есть похожий инструмент.
ssh -G abc
Здесь abc является произвольным именем хоста. Или, возможно, не совсем произвольным. Можно использовать что угодно, включая реальное имя хоста. Клиент может использовать блоки Host и Match для настройки конфигурации группы систем или отдельной системы. Если хоста abc не существует, будут рассматриваться настройки по умолчанию.
Настройки SSH для отдельной системы
Допустим, есть система secureserver. Вместо того, чтобы работать на порте 22, она принимает соединения по SSH на порте 2222. Вместо применения в командной строке можно добавить блок Host в файл конфигурации. Для этого необходимо в каталоге .ssh домашней директории создать файл config ().
Затем создадим блок и определим нужные настройки.
Host secureserver
Hostname hostname.example.org
User mynickname
Port 2222
MACs hmac-sha2-512
KexAlgorithms curve25519-sha256@libssh.org
Отступы необязательны, но рекомендуются, чтобы отличать, какие настройки к какому хосту относятся.
Какие же настройки следует определять в файле конфигурации клиента?
Рекомендуем использовать те, которые облегчат вам ежедневную работу. Если вы отдаете предпочтение безопасности, задайте надежные настройки по умолчанию. Если какой-то хост использует другой SSH-порт, создайте блок Host и переопределите его настройки нужным образом. Что касается KexAlgorithms, используйте более новые доступные алгоритмы. Это сильно зависит от версии OpenSSH на серверах. Если на сервере используется новая версия OpenSSH, то хорошо подойдет curve25519. Это высокоскоростной алгоритм на основе эллиптических кривых, который на данный момент считается безопасным.
Распространенные ошибки конфигурации
Корневой логин
По умолчанию большая часть реализации SSH-сервера разрешает вход в систему с правами root, рекомендуется отключить его, потому что в случае утечки учетных данных этой учетной записи злоумышленники получат административные привилегии напрямую, и это также позволит злоумышленникам проводить bruteforce атаки на эту учетную запись.
Как отключить вход root для openSSH:
- Отредактируйте конфигурацию SSH-сервера
- Изменитена
- Учтите изменения конфигурации:
- Перезагрузите SSH-сервер
Выполнение команды SFTP
Другая распространенная неправильная конфигурация SSH часто встречается в конфигурации SFTP. В большинстве случаев при создании сервера SFTP администратор хочет, чтобы пользователи имели доступ по протоколу SFTP для совместного использования файлов, но не получали удаленную оболочку на машине. Поэтому они думают, что создания пользователя, присвоения ему оболочки-заполнителя (например, или и помещения его в заключение достаточно, чтобы избежать доступа к оболочке или злоупотреблений во всей файловой системе. Но они ошибаются: пользователь может попросить выполнить команду сразу после аутентификации до того, как будет выполнена команда или оболочка по умолчанию. Таким образом, чтобы обойти оболочку заполнителя, которая будет запрещать доступ к оболочке, нужно только попросить выполнить команду (например, раньше, просто выполнив:
Вот пример безопасной конфигурации SFTP () для пользователя noraj:
Эта конфигурация разрешит только SFTP: отключение доступа к оболочке путем принудительного запуска команды и отключения доступа TTY, а также отключение всех видов переадресации или туннелирования портов.
Методы аутентификации
В среде с высоким уровнем безопасности обычной практикой является включение только аутентификации на основе ключа или двухфакторной аутентификации, а не аутентификации на основе простого факторного пароля. Но часто более строгие методы аутентификации включаются без отключения более слабых. Частым случаем является включение открытого ключа в конфигурации openSSH и установка его в качестве метода по умолчанию, но не отключение пароля. Таким образом, используя подробный режим клиента SSH, злоумышленник может увидеть, что включен более слабый метод:
Например, если установлен предел ошибок аутентификации, и у вас никогда не будет возможности достичь метода пароля, вы можете использовать параметр PreferredAuthentication, чтобы принудительно использовать этот метод.
Проверить конфигурацию SSH-сервера необходимо, чтобы убедиться, что только ожидаемые методы разрешены. Использование подробного режима на клиенте может помочь увидеть эффективность конфигурации.
Закручиваем гайки
Все приведённые ниже настройки производятся в файле sshd_config если не указано обратное. Сразу же сделаем бекап этого файла
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bkp
Открыть его на редактирование можно следующей командой:
sudo nano /etc/ssh/sshd_config
В зависимости от операционной системы и версии сервера, в файле конфигурации могут присутствовать или отсутствовать те или иные настройки. В случае отсутствия в нём приведённых ниже настроек, их необходимо добавить. Так же возможно что они отсутствуют в связи с тем что инструкция устарела. Так что если что-то не работает, необходимо актуализировать информацию в соответствии со справкой из официального источника. Настройки приведены на 11.11.2020.
Жестко прописываем IP адрес ssh сервера
Например у вашего хоста IP адрес 192.168.1.100. А опция отвечающая за интерфейс на котором работает SSH сервер прописана как “*”. А потом к примеру вы нечаянно добавляете этому хосту ещё один сетевой интерфейс. И ещё неожиданно этот интерфейс начинает смотреть жопкой прямо в инторнет. Опция “*” – автоматом сделает возможным подключение к SSH серверу через тот новый интерфейс. Чтобы этого не произошло – необходимо ограничить IP адрес на котором работает SSH сервер. Прописать там можно как жестко IP адрес этого сервера. В случае с ag-dc-1 – это 192.168.1.100, так и подсеть: 192.168.1.0/24.
Для ag-dc-1
ListenAddress 192.168.1.100 #ip ag-dc-1
Для ag-dc-2
ListenAddress 192.168.1.101 #ip ag-dc-2
Изменяем порт SSH сервера
22 порт – первое что будут сканировать всякие зловреды. Крайне желательно сменить этот порт на любой другой нестандартный и не занятый другим сервисом.
#Port <желаемый номер нестандартного порта> Port 54322
Как разрешить или запретить пользователям входить через SSH
Всего имеется 4 директивы, которые разрешают или запрещают пользователям и группам подключаться к SSH. Эти директивы в порядке обработки: DenyUsers, AllowUsers, DenyGroups и наконец AllowGroups.
За ключевым словом AllowUsers может следовать список шаблонов имён пользователей, разделённых пробелами, например:
AllowUsers alice bob
Если директива используется, то вход разрешён только пользователям, имена которых соответствуют шаблонам. Принимаются только имена пользователей, цифровые идентификаторы пользователей не распознаются. По умолчанию вход разрешён для всех пользователей. Если шаблон имеет вид ПОЛЬЗОВАТЕЛЬ@ХОСТ, тогда раздельно проверяются ПОЛЬЗОВАТЕЛЬ и ХОСТ и вход разрешается только определённым пользователям с определённых хостов. В качестве ХОСТа могут быть адреса в формате CIDR, то есть в виде адрес/маска.
Далее о шаблонах, которые могут принимать директивы DenyUsers, AllowUsers, DenyGroups и AllowGroups.
Создать SSH туннель
Туннели обычно создают для перенаправления траффика. SSH tunnel это то же самое что и SSH port forwarding.
Допустим вы хотите направить траффик со своего localhost (127.0.0.1) на
удалённый
хост 192.168.0.2.
На
удалённом
хосте у вас есть пользователь с именем andrei и вы знаете его пароль.
Сперва нужно определиться с портами на локальном хосте и на удалённом.
Предположим, вы выбрали 9119 для локального и
9200 для
удаленного
хостов.
То есть вы хотите, чтобы всё, что идёт на localhost:9119 было перенаправлено на
192.168.0.2:9200
Выполните
ssh -L 9119:192.168.0.2:9200 andrei@192.168.0.2
The authenticity of host ‘192.168.0.2 (192.168.0.2)’ can’t be established.
ECDA …
…
andrei@192.168.0.2’s password:
Last login: Sun Jan 31 13:23:00 2021
Проверьте ip выполнив
ip a
Если вам нужен туннель с поддержкой графического интерфейса
X Window System
используйте флаг -X
ssh -X -L 9119:192.168.0.2:9200 andrei@192.168.0.2
1: Установка PAM
Сначала давайте установим PAM от Google, или Pluggable Authentication Module – это инфраструктура для аутентификации пользователей, которая используется в системах Linux. Поскольку приложение OATH-TOTP разработано Google, компании понадобилось создать и модуль PAM для быстрой генерации одноразовых паролей, совместимый с любым TOTP-приложением (в том числе с Google Authenticator или Authy).
Затем установите PAM:
Дальше вы можете использовать вспомогательное приложение, которое устанавливается вместе с модулем PAM, и создать TOTP-ключ для пользователя, который в дальнейшем будет поддерживать двухфакторную аутентификацию. Имейте в виду: каждый такой ключ индивидуален для каждого аккаунта, TOTP-ключи не используются общесистемно; следовательно, чтобы настроить двухфакторную аутентификацию для нескольких пользователей, вы должны запустить вспомогательное приложение на каждом аккаунте и сгенерировать уникальный TOTP-ключ для каждого из них.
Запустите приложение:
Сейчас оно задаст вам несколько вопросов. Сначала укажите, нужно ли синхронизировать токены аутентификации по времени.
Модуль PAM позволяет создавать токены, синхронизированные по времени или на основе математического алгоритма.
Токены на основе математического алгоритма берут определенное число как исходный код, и после каждого использования токена следующий токен увеличивается на единицу. Синхронизированные по времени токены обновляются в заданный период времени. В этом мануале мы остановимся на токенах, синхронизированных по времени, поскольку именно такие обычно используют приложения типа Google Authenticator. Нажмите y.
Примечание: Сохраните секретный ключ, код подтверждения и коды восстановления в надежном месте (например, в менеджере паролей). Это ваш единственный способ восстановить доступ к TOTP-приложению, если вдруг вы его потеряете.
Остальные вопросы приложения посвящены настройке PAM. Давайте рассмотрим их по очереди.
Если вы выберете у, ключи и параметры в файле .google_authenticator будут обновлены. А при ответе no программа завершит работу и ничего не запишет в файл, в результате чего аутентификация не будет работать.
Этот параметр позволяет предотвратить навязывание пакетов, потому что каждый код станет недействителен после использования, и злоумышленник не сможет ввести уже использованный код (если даже ему удастся его перехватить).
При ответе yes эта опция будет создавать до 17 валидных кодов в скользящем окне в течение 4 минут. Если вы ответите no, их количество будет ограничено до 3 валидных кодов в полторы минуты – это более безопасный выбор. Позже вы сможете изменить эту настройку в файле .google_authenticator, который хранится в корне вашего домашнего каталога.
Этот параметр ограничит количество попыток угадать код: удаленному злоумышленнику дается всего несколько попыток ввести правильное значение, после чего ввод блокируется на некоторое время. Если ранее вы не настраивали ограничение скорости ввода непосредственно в SSH, сделайте это сейчас – это отличный способ укрепить защиту системы.
Примечание: После завершения настройки рекомендуем создать резервную копию секретного ключа. Для этого нужно скопировать файл ~/.google-authenticator в надежное место. Теперь вы сможете использовать его в других системах или хранить как резервную копию.
Следующим шагом будет настройка SSH для поддержки TOTP-ключа
Импортируем закрытый ключ в PuTTY
PuTTY – прекрасный и наверное самый лучший SSH клиент для масдая. Который работает без нареканий и обладает всем необходимым функционалом. Бесплатный. Всё в нём хорошо. Но именно на этом поприще они решили отличиться и добавить чуть-чуть геморроя в процесс.
Вместе с PuTTY поставляется утилита PuTTYgen (PuTTY Key Generator).
- Запускаем PuTTYgen
- Нажимаем кнопку Load
- Тип файлов выбираем All Files, выбираем свой текстовичок
- Видим сообщение об успешном импорте ключа. При желании можно указать комментарий ( Key comment)
- Жмём кнопку Save private key, соглашаемся с отсутствием пароля у ключа
SSH авторизация по сертификатам через Putty – Сохранение сертификатов
Сведения о парах ключей
Парой ключей называются файлы открытого и закрытого ключей, которые используются в некоторых протоколах аутентификации.
При аутентификации SSH на основе открытого ключа используются асимметричные алгоритмы шифрования для создания двух файлов ключей, один из которых считается закрытым, а второй открытым. Файлы закрытых ключей выполняют функцию паролей, а значит, должны быть постоянно защищены. Если кто-то получит ваш закрытый ключ, он сможет войти от вашего имени на любой сервер с поддержкой SSH, к которому у вас есть доступ. Открытый ключ размещается на сервере SSH. Его можно свободно распространять, не компрометируя закрытый ключ.
Если на сервере SSH используется аутентификация с помощью ключей, сервер и клиент SSH сравнивают открытый ключ, связанный с предоставленным именем пользователя, с закрытым ключом. Если открытый ключ на стороне сервера не проходит проверку по закрытому ключу, сохраненному на стороне клиента, аутентификация не будет выполнена.
Многофакторную проверку подлинности можно реализовать с помощью пар ключей, введя парольную фразу при создании пары ключей (см. раздел о ниже). При аутентификации пользователю предлагается ввести эту парольную фразу. Она применяется вместе с закрытым ключом для аутентификации пользователя.
Ограничиваем количество попыток авторизации
Если подключающийся владеет всеми необходимыми данными, то при авторизации по сертификатам ему хватит двух попыток авторизации. В противном случае сеанс будет прерван. Если количество попыток авторизации сделать равным единице, авторизация по сертификатам не будет работать.
MaxAuthTries 2 # Две неудачные попытки и разрыв связи
Включаем разделение прав пользователей
В момент подключения к серверу, до момента авторизации пользователя, будет создан отдельный процесс с ограниченными правами. После прохождения пользователем авторизации, будет создан уже новый процесс, с правами соответствующими правам пользователя. Данная настройка повышает безопасность, не давая пользователю повышать свои права
UsePrivilegeSeparation yes
Ограничиваем список доступа по SSH.
Важный момент, для того чтобы исключить доступ к терминалу со стороны нежелательных пользователей.
При этом запись adminguideru – разрешает доступ по ssh для этого юзера с любого источника подключения. Запись же root@192.168.1.101 – разрешает доступ к серверу под учёткой рута только с ip 192.168.1.101 и 192.168.1.101
AllowUsers adminguideru root@192.168.1.100 root@192.168.1.101
Отключим список доверенных хостов
IgnoreRhosts yes
Отключим авторизацию на стороне клиента
HostbasedAuthentication no
Сохраним все настройки (Ctrl+O) и закроем файл (Сtrl+X).
Перезапускаем SSH сервер
sudo systemctl restart ssh sshd
Настройка безопасности SSH – Пробуем подключиться к серверу через Putty
Не разрывая подключение с которого происходила настройка. Запускаем Putty и пытаемся установить подключение с админской машины, под админской учёткой, с помощью сертификата. Если не подключает – значит в настройках косяк. Вносим правки в файл конфигурации в том окне где происходила настройка. Несмотря на то что уже работают новые настройки, старое подключение будет работать пока мы не отключимся
Поэтому важно не разрывать его пока вы не убедитесь что всё заработало. Если всё заработало идём к следующему пункту
Настройка безопасности SSH – Ограничим допущенные к подключению IP адреса
Необходимо отредактировать файл hosts.allow . Открываем его на редактирование
sudo nano /etc/hosts.allow
И добавляем IP адреса всех участников локальной сети, допущенных к подключению (включая IP адрес настраиваемого сервера)
sshd: 127.0.0.1 192.168.1.100 192.168.1.101 192.168.1.254
.254 – админская машина. 100 раз проверьте что у вас стоит IP адрес вашей админской машины. Иначе вы сможете авторизоваться на сервере только через консоль или сменив свой IP на тот что вы указали (если сервер примет с него подключение).
Настройка безопасности SSH – Проверяем авторизацию по паролю
Заходим в конфиг
sudo nano /etc/ssh/sshd_config
Находим пункт PasswordAuthentication раскомментируем и ставим no если там что-то другое.
PasswordAuthentication no
SSH авторизация по сертификатам- Настраиваем подключение
Запускаем Putty, в окне Session указываем адрес сервера к которому будем подключаться с помощью сертификата
Переходим в Connection -> SSH -> Auth и нажав кнопку Browse выбираем свой только что созданный файл с закрытым ключём.
После нажатия кнопки Open система попросит вас ввести логин пользователя под которым мы пытаемся авторизоваться.
Чтобы заходить даже без ввода логина, достаточно указать этот логин в Connection->Data в поле Auto-login username
После этого двойным нажатием на сохранённую в PuTTY сессию вы будете в одно мгновение залетать в консоль. Ввод пароля теперь будет требоваться только для работы с sudo
Вход в SSH без пароля (с использованием файлов ключей)
Вход в SSH по публичному ключу (без пароля) очень удобен и безопасен.
Процесс настройки аутентификации по публичному ключу очень простой:
- Командой создаётся пара «публичный ключ — приватный ключ».
- Публичный ключ копируется на компьютер с сервером SSH, то есть на компьютер, к которому будет осуществляться подключение и на котором будут выполнятся команды.
- Затем подключение выполняется обычным способом, но ввод пароля уже не требуется.
Публичный ключ, который копируется на удалённый сервер, не является секретным. Один и тот же ключ можно использовать на разных серверах. Главное — хранить в секрете приватный ключ.
Сгененировать ключи и скопировать их на удалённый хост можно буквально тремя командами. Для генерации пары ключей используется программа ssh-keygen, она включена в пакет ssh и если SSH у вас уже настроен, то дополнительно устанавливать ничего не нужно.
У программы ssh-keygen много функций и возможностей, начнём с рассмотрения процедуры генерации ключей, которая выполняется элементарно.
Если вы успели залогиниться на удалённой системе, разлогинтесь. После этого наберите:
ssh-keygen -t rsa
У нас спрашивают имя файла, не нужно ничего вводить, будет использовано имя по умолчанию. Также спрашивается пароль. Этот пароль позволяет установить дополнительную защиту — при подключении с помощью ключей не будет спрашиваться пароль пользователя, но будет спрашиваться пароль самого ключа. Устанавливать пароль необязательно.
В результате будет создано два файла:
- ~/.ssh/id_rsa
- ~/.ssh/id_rsa.pub
Первый файл нужно хранить в секрете. Второй файл нужно скопировать на удалённый компьютер, где запущен сервер SSH.
Теперь на удалённой машине нам нужно создать каталог .ssh. В предыдущей части мы уже узнали, на удалённой системе по SSH. Запустите команду вида:
ssh ПОЛЬЗОВАТЕЛЬ@АДРЕСАТ mkdir .ssh
Например:
ssh mial@192.168.1.36 mkdir .ssh
Теперь нам нужно скопировать содержимое файла id_rsa.pub на удалённую машину в файл ~/.ssh/authorized_keys. Сделать это очень просто (не забываем менять данные на свои):
cat .ssh/id_rsa.pub | ssh ПОЛЬЗОВАТЕЛЬ@АДРЕСАТ 'cat >> .ssh/authorized_keys'
Например:
cat .ssh/id_rsa.pub | ssh mial@192.168.1.36 'cat >> .ssh/authorized_keys'
Теперь выполняем подключение с помощью клиента SSH, но пароль у нас больше спрашиваться не будет.
Другие важные опции командной строки сервера SSH
-c host_certificate_file
Указывает путь к файлу сертификата для идентификации sshd во время обмена ключами. Файл сертификата должен соответствовать файлу ключа хоста, указанному с помощью параметра -h или директивы конфигурации HostKey.
-h host_key_file
Указывает файл, из которого читается ключ хоста. Эта опция должна быть указана, если sshd не запускается от имени пользователя root (поскольку обычные файлы ключей хоста как правило не читаются никем, кроме root). По умолчанию это /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key и /etc/ssh/ssh_host_rsa_key. Можно иметь несколько файлов ключей хоста для разных алгоритмов ключей хоста.
-E файл_журнала
Добавить журналы отладки в файл_журнала вместо системного журнала.
-e
Записывать журналы отладки в стандартный вывод ошибок вместо системного журнала.
-o опция
Может использоваться для задания параметров в формате, используемом в файле конфигурации (sshd_config). Это полезно для указания параметров, для которых нет отдельного флага командной строки. Самые важные директивы конфигурационного файла рассмотрены выше.
-p порт
Указывает порт, на котором сервер прослушивает соединения (по умолчанию 22). Допускается использование нескольких портов. Порты, указанные в файле конфигурации с параметром «Port», игнорируются, если указан порт командной строки. Порты, указанные с помощью параметра ListenAddress, переопределяют порты командной строки.
-q
Тихий режим. Ничего не отправляется в системный журнал. Без этой опции обычно запуск, аутентификация и завершение каждого соединения регистрируются.
Как сделать ваши соединения Secure Shell еще более безопасными
Secure Shell является наиболее широко используемым средством входа на удаленный сервер Linux (или компьютер). Используя этот инструмент, вы получаете доступ к командной строке на удаленном компьютере через безопасный туннель. Из коробки вам будет предложено ввести пароль удаленного пользователя. Хотя это все еще более безопасно, чем использование более старых методов (таких как telnet), его можно сделать еще более безопасным с помощью SSH Key Authentication.
Что такое аутентификация по ключу?
Понимание аутентификации ключей на самом деле довольно просто. Представьте, что у вас есть замок, и единственный способ открыть его – использовать определенный ключ, который, как вам известно, принадлежит вам. Как замок узнает, что ключ принадлежит вам? Потому что ключ содержит уникальную для вас подпись. Внутри замка есть соответствующая подпись, которую ключ использует для сравнения. Если подписи совпадают, они откроются. Если ключ подходит, но подписи не совпадают, замок не открывается.
Это основа для аутентификации по ключу SSH. В реальной жизни это работает так, что вы создаете пару ключей (которая содержит закрытый и открытый ключи) и копируете открытый ключ на сервер, на который хотите войти. Если вы попытаетесь войти с аутентификацией по ключу, а у сервера нет открытого ключа, соответствующего вашему личному ключу, он не разрешит вам доступ.
Давайте заставим это работать.
Генерация пары ключей SSH
Первое, что нужно сделать, это создать пару ключей SSH. Для этого выполните следующие действия:
-
Откройте окно терминала на рабочем столе.
Выполните команду:
SSH-кейген
Присвойте ключу имя и местоположение (используйте настройки по умолчанию, используя Enter/Return на клавиатуре).
-
Введите и подтвердите ключевую фразу для ключа (убедитесь, что она является надежной и уникальной)
Теперь у вас есть пара ключей SSH. Эти два файла будут найдены в ~/.ssh и будут называться:
- id_rsa – закрытый ключ
- id_rsa.pub – открытый ключ.
Скопируйте ваш открытый ключ на удаленный компьютер
Затем вы должны скопировать файл открытого ключа на удаленный компьютер, на который хотите войти. Это можно сделать с помощью команды:
ssh-copy-id USER @ REMOTE_IP
Где USER – это имя пользователя на удаленном компьютере, а REMOTE_IP – это IP-адрес удаленного компьютера.
Если вы впервые зашли в безопасное место на удаленном компьютере, вам будет предложено ввести да , чтобы продолжить подключение, в противном случае вам будет предложено ввести пароль пользователя на удаленном компьютере. машина. После успешного ввода удаленного пароля ключ будет скопирован, и вы будете готовы проверить соединение.
Тестирование соединения
Проверьте соединение, введя команду:
ssh USER @ REMOTE_IP
Где USER – это имя пользователя на удаленном компьютере, а REMOTE_IP – это IP-адрес удаленного компьютера. Вместо запроса пароля пользователя вам будет предложено ввести ключевую фразу пары ключей SSH. После того, как вы ввели правильную ключевую фразу, вам будет разрешен доступ к удаленному компьютеру. Поздравляем, SSH Key Authentication запущена и работает.
Отключение аутентификации по паролю
Вы можете сделать этот шаг дальше, отключив аутентификацию по паролю. С этой конфигурацией единственный способ получить доступ к удаленному компьютеру – с компьютера, содержащего закрытый ключ из соответствующей пары. Другими словами, нет пары ключей, нет доступа.
Чтобы отключить аутентификацию по паролю, войдите на удаленный компьютер и введите команду:
sudo nano/etc/ssh/sshd_config
В этом файле найдите строку:
#PasswordAuthentication yes
Измените эту строку на:
PasswordAuthentication no
Сохраните и закройте файл. Перезапустите SSH с помощью команды:
sudo systemctl перезапустите sshd
Теперь, если вы попытаетесь войти на эту удаленную машину с любого рабочего стола (или сервера), который не содержит закрытый ключ, доступ будет запрещен.
Поздравляем, вы успешно сделали вход в удаленную систему Linux более безопасным с помощью SSH.
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
