Андрей Смирнов
Время чтения: ~21 мин.
Просмотров: 14

Установка и настройка SSH-сервера в Ubuntu

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

Служба ssh позволяет получить доступ к терминалу удаленного компьютера и выполнить там все необходимые вам команды. При своей простоте она достаточно безопасна, чтобы использоваться для решения серьезных коммерческих задач, так и задач обычных пользователей. В этой статье мы рассмотрим как выполняется установка ssh Ubuntu 16.04, а также поговорим о начальной настройке ssh сервера.

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

За поддержку протокола SSH в Linux отвечает набор программного обеспечения OpenSSH. Это открытая реализация этого протокола, которая предоставляет все необходимые возможности. В состав пакета OpenSSH входят утилиты для установки соединения, передачи файлов, а также сам ssh сервер.

Установить ssh на Ubuntu будет очень просто, программа считается стандартной и используется почти везде. Хотя по умолчанию в дистрибутиве ее нет, но зато она есть в официальных репозиториях.

Поэтому для установки откройте терминал с помощью сочетания клавиш Ctrl+Alt+T и выполните команду:

ssh.png

Будет загружено несколько пакетов, а когда установка ssh сервера Ubuntu завершится, программа будет готова к работе. Если вы хотите чтобы служба запускалась автоматически нужно добавить его в автозагрузку. Поэтому чтобы включить ssh Ubuntu 16.04 выполните:

ssh1.png

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

Что касается клиента ssh, то он уже установлен в системе по умолчанию. Сейчас вы можете попробовать подключиться к локальному ssh серверу просто набрав:

ssh3.png

В одной из предыдущих статей мы рассматривали что означает адрес 0.0.0.0, сейчас вы можете убедиться что в пределах этой машины он значит локальный адрес:

ssh2.png

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

$ sshимя_пользователя@ip_адрес

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

Перед тем как вносить изменения в этот конфигурационный файл рекомендуется сделать его резервную копию, для этого можете использовать такую команду:

Дальше вы можете перейти к настройке конфигурационного файла:

Первым делом желательно сменить порт, на котором работает ssh, возможный злоумышленник не знал включен ли у вас этот сервис. Найдите в конфигурационном файле строчку Port и замените ее значение на любое число, например, Port 2222:

ssh4.png

По умолчанию вход от имени суперпользователя включен, рекомендуется отключить такую возможность. Для этого найдите строчку PermitRootLogin и замените ее значение на no:

ssh5.png

Чтобы разрешить аутентификацию по ключу, а не по паролю найдите строку PubkeyAuthentication и убедитесь, что ее значение yes.

ssh6.png

После того как все настройки будут завершены, сохраните изменения нажав :w и перезапустите службу ssd:

Более подробно про настройку и использование различных тонкостей ssh рассказано в статье как использовать ssh.

Если вы изменили порт, то при подключении в клиенте тоже нужно указать новый порт, так как по умолчанию будет использоваться 22, например:

К тому же, если на компьютере установлен и настроен брандмауэр, то в нем тоже нужно разрешить доступ к новому порту ssh, для этого выполните:

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

Настройка ssh Ubuntu 16.04 полностью завершена.

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

На завершение видео, где подробно рассказано о том, что такое ssh:

Настройка GNU/Linux Debian

Настройка SSH сервера

Настройки sshd находятся в файле /etc/ssh/sshd_config. Открываем этот файл для редактирования и изменяем его содержимое для наших нужд, не забывая при этом о безопасности.

Первый параметр – Port. По умолчанию используется 22 порт. Изменим его на нестандартный порт 2203 – это избавит наш сервер от сетевых роботов, которые автоматически сканируют интернет в поиске открытых портов и пытаются через них подключиться. Это не избавит от сканирования человеком, но для защиты от человека существует фаервол, хитрые способы открытия порта, «горшочки с мёдом» и т. д.

Port 2203

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

$ ssh –l andrey –p 2203 192.168.123.254

или так

$ ssh andrey@sunup.aitishnik.local –p 2203

Следующие две закомментированные строки оставляем без изменения.

#ListenAddress ::

#ListenAddress 0.0.0.0

Эти строки отвечают за настройку разграничений по сетевым интерфейсам, сетевому адресу или имени компьютера. По умолчанию сервер «слушает» (принимает подключения) на всех сетевых интерфейсах. Нас это устраивает, поэтому мы оставляем значение по умолчанию. Если бы нам нужно было оставить подключение только через внешний интерфейс, то раскомментировав строку мы бы написали:

ListenAddress 192.168.123.0

В этой же строке можно явно указать порт, предварительно закомментировав (поставив символ # в начале строки) первую строку – Port 2203:

ListenAddress 192.168.123.0:2203

Следующий параметр отвечает за версию протокола SSH. Значение по умолчанию 2. Его и оставляем. Не добавляем единичку ни при каких обстоятельствах. Первая версия протокола SSH не безопасна!

Protocol 2

Строки HostKey необходимы для второй версии протокола SSH и отвечают за названия файлов ключей и их расположение. Первая строка отвечает за пару ключей RSA, вторая соответственно за пару ключей DSA. К названиям открытых (публичных) ключей добавляется .pub. Эти ключи используются при аутентификации с ключом хоста. Можно поменять слово host в названии ключей на имя нашего сервера, но мы сделаем это в части, посвященной генерации ключей. Сейчас же отключим ключи DSA, так как будем пользоваться только RSA:

HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_sunup_dsa_key

Строка Privilege Separation указывает, должен ли демон ssh (sshd) разделять привилегии. Если да — то сначала будет создан непривилегированный дочерний процесс для входящего сетевого трафика. После успешной авторизации будет создан другой процесс с привилегиями вошедшего пользователя. Основная цель разделения привилегий — предотвращение превышения прав доступа. Оставляем yes.

UsePrivilegeSeparation yes

Следующие строки отвечают за временный ключ и его длину при работе с первой версией протокола SSH. Мы не используем SSH-1, поэтому пока закомментируем эти строки.

# KeyRegenerationInterval 3600

# ServerKeyBits 768

Далее следует группа параметров, отвечающая за журналирование. События, связанные с доступом по SSH записываются в журнал /var/log/auth

Первый параметр определяет, список каких событий администратор хочет видеть в журнале. Доступны следующие значения: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. Нас интересует авторизация, поэтому оставляем AUTH.

SyslogFacility AUTH

Второй параметр определяет уровень детализации событий. Доступны следующие события: SILENT , QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3. Оставляем уровень детализации по умолчанию, если возникнут ошибки, то всегда можно увеличить детализацию журнала.

LogLevel INFO

Следующая группа параметров относится к аутентификации. Первый параметр означает, что соединение будет разорвано через указанное количество секунд, если пользователь не войдёт в систему. Уменьшим это время в два раза.

LoginGraceTime 60

Второй параметр разрешает или запрещает вход по SSH под суперпользователем. Запрещаем вход суперпользователю.

PermitRootLogin no

Третий параметр включает проверку демоном ssh прав и владение домашним каталогом пользователя, который пытается получить удалённый доступ к компьютеру. Оставляем yes.

StrictModes yes

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

AllowUsers andrey

В нашем примере разрешение есть только у пользователя andrey. Значениями этого параметра могут выступать имена пользователей, отделённые друг от друга пробелами. Нельзя использовать в качестве значений UID (User ID). Можно использовать запись пользователя в виде user@host, например andrey@echidna. Это означает, что доступ разрешён пользователю andrey с компьютера echidna. Причём пользователь и компьютер проверяются отдельно, это позволяет разграничить доступ определенных пользователей с определенных компьютеров. Существует обратный параметр – DenyUsers, который запрещает доступ пользователям, перечисленным в значении этого параметра. Кроме параметров связанных с доступом отдельных пользователей существуют соответствующие параметры для групп: AllowGroups и DenyGroups.

Оставляем включенной аутентификацию RSA, в параметре RSAAuthentication:

RSAAuthentication yes

Оставляем включенной аутентификацию по открытому ключу, в дальнейшем мы настроим аутентификацию таким способом.

PubkeyAuthentication yes

Параметр AuthorizedKeysFile определяет файл, в котором содержатся публичные ключи, используемые для аутентификации пользователей по открытому ключу. В записи могут присутствовать переменные, например %h означает домашний каталог пользователя, а %u – имя пользователя. В дальнейшем мы планируем использование аутентификации по открытому ключу — раскомментируем эту строку.

AuthorizedKeysFile .ssh/authorized_keys

Следующие два параметра отвечают за включение совместимости с программой rhosts. Нам такая совместимость только повредит, поэтому оставляем значения по умолчанию.

IgnoreRhosts yes

RhostsRSAAuthentication no

Аутентификация hostbased нам тоже не нужна и она уже отключена, поэтому оставляем существующее значение

HostbasedAuthentication no

Следующая строка нужна для совместимости с rhost – оставляем закомментированной.

#IgnoreUserKnownHosts yes

Параметр PermitEmptyPasswords разрешает или запрещает вход с пустым паролем. Естественно, запрещаем вход с пустым паролем – оставляем no.

PermitEmptyPasswords no

Параметр ChallengeResponseAuthentication включает PAM интерфейс. Если задано значение yes, то для всех типов аутентификации помимо обработки модуля сессии и аккаунта PAM, будет использоваться аутентификация на основе запроса-ответа (ChallengeResponseAuthentication и PasswordAuthentication) Т.к. аутентификация запросов-ответов в PAM обычно выполняет ту же роль, что и парольная аутентификация, следует отключить, либо PasswordAuthentication, либо ChallengeResponseAuthentication.

ChallengeResponseAuthentication no

Следующий параметр отвечает за аутентификацию по паролю. Сейчас используется аутентификация по ключу хоста — просто раскомментируем строку.

PasswordAuthentication yes

Группу из четырёх параметров, отвечающих за аутентификацию Kerberos, оставляем без изменений – не раскомментированными.

#KerberosAuthentication no

#KerberosGetAFSToken no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

Следующие два закомментированных параметра отвечают за то, разрешена ли аутентификация пользователя на основе GSSAPI или нет. Для наших целей аутентификация GSSAPI не нужна – оставляем без изменений.

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes

Параметры, начинающиеся с X11, отвечают за проброс иксов через ssh туннель. Ниш сервер не имеет иксов, поэтому закомментируем эти опции

# X11Forwarding yes

# X11DisplayOffset 10

Опция PrintMotd выводит при подключении к sshd так называемое сообщение дня, что на самом деле является содержимым файла /etc/motd. Опция PrintLastLog очень полезна, так как она включает отображение информации о том, когда вы последний раз и с какого компьютера заходили на сервер.

PrintMotd no

PrintLastLog yes

Установим параметру TCPKeepAlive значение no. Этот параметр важен для поддержания соединения со стороны сервера, но мы реализуем те же функции, но более безопасней.

TCPKeepAlive no

Для этого добавим два следующих параметра:

ClientAliveCountMax 3

ClientAliveInterval 20

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

Параметр UseLogin оставляем закомментированным. Его значение по умолчанию и так no.

#UseLogin no

Раскомментируем параметр MaxStartups и выставим ему следующее значение:

MaxStartups 3:30:9

По умолчанию значение данного параметра 10. Это количество неавторизованных подключений к серверу ssh. Длительность такого подключения определяется параметром LoginGraceTime, описанным выше. Перенесём параметр MaxStartups под LoginGraceTime и запишем в виде start:rate:full, где start – это уже имеющееся количество неавторизованных подключений, rate – процент вероятности отклонения попытки подключения, full – максимальное количество неавторизованных соединений. В нашем примере, если уже имеется 3 неавторизованных подключения, то следующее подключение будет отклонено с вероятностью 30%, а если количество неавторизованных подключений достигнет 9, то все последующие попытки подключения будут отвергнуты.

Опция Banner определяет место положения файла-баннера, который будет выведен на экран, при попытке подключиться к серверу sshd. Предлагается файл /etc/issue.net, но можно использовать свой баннер, поместив его, например в /etc/ssh. В Debian по умолчанию выводится содержимое файла /etc/motd.tail. Оставляем как есть.

#Banner /etc/issue.net

Лучше добавим ещё один полезный параметр, который отсутствует в файле sshd_config – DebianBanner. Этот параметр добавляет в строку ответа sshd информацию об операционной системе, при обращению к серверу по протоколу TELNET или при сканировании nmap. Эта строка может выглядеть так: SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze1. Скроем информацию о нашей операционной системе.

DebianBanner no

Теперь строка ответа будет выглядеть так: SSH-2.0-OpenSSH_5.5p1

Параметр AcceptEnv указывает, какие переменные окружения, переданные клиентом, будут приняты.

AcceptEnv LANG LC_*

Следующий параметр включает внешнюю подсистему (например, FTP). В качестве параметров понимает, имя подсистемы и команду, которая будет выполнена при запросе подсистемы. Команда sftp-server, реализует протокол передачи файлов через SSH — SFTP.

Subsystem sftp /usr/lib/openssh/sftp-server

Параметр UsePAM оставляем без изменений. Если директива UsePAM включена, то запустить sshd можно будет только от имени root.

UsePAM yes

Сохраняем изменения и перезапускаем sshd. Подключаемся, проверяем, если всё в порядке, то настройка сервера ssh с аутентификацией оп ключу хоста закончена. Для разрешения проблем и вывода отладочной информации можно подключаться с ключами: -v, -vv, -vvv.

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

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

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

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

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

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

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

Host sunup

HostName sunup.aitishnik.local

Port 2203

User andrey

Host windbag

HostName windbag.nnov.ru

Port 2280

User joker

Host 212.177.65.1

HostName 212.177.65.1

Port 2222

User forester

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

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

Об авторе:

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

Ещё статьи о Debian

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

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

    • Опции vsftpd.conf

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

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

      b_48_48_359_salute.pngВсе, кто совершал вход в систему 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)

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

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

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

    • Установка Debian

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

Установка и настройка SSH — Ubuntu

ssh-ubuntu.jpg

«Вы начинающий админ и хотите, например, поднять свой веб сервер. Идете в интернет, находите подходящую Вам статью и вперед! Давайте обратим внимание на один Важный момент, практически во всех этих статьях дается минимум команд для запуска необходимых служб и сервисов. Хорошо — заработало! А все ли Вы сделали для того, чтобы работать не перестало? Используете SSH через интернет? Почему никто в своих статьях не освещает проблем, которые могут получить новоиспеченные админы с таким подходом к настройке сервера, ведь именно для новичков и написаны статьи. Для того, чтобы Вы вовремя обратили внимание на вопрос безопасности, я обязательно буду делать пометки и ссылки в своих статьях на данный материал. Предупрежден – вооружен! «

Итак, SSH (secure shell) – безопасный сервер терминалов, предоставляет удаленный доступ к системе. Безопасный, т.к. весь трафик между клиентом и сервером шифруется. А так ли он безопасен с настройками по умолчанию? Если Вы имеете сервер с возможностью подключения по SSH через интернет, обязательно найдутся желающие подобрать пароль для входа. Думаю, не стоит объяснять, что возможный злоумышленник сможет получить практически неограниченный доступ к системе.

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

Установка SSH сервера в Ubuntu.

Установка SSH сервера в Ubuntu выполняется следующей командой:

 sudo apt-get install ssh openssh-server

После установки SSH сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:

 sudo service ssh stop | start | restart

Основной файл конфигурации SSH — сервера — файл /etc/ssh/sshd_config, доступный для чтения или редактирования только супер пользователю (root). Для применения изменений необходимо перезапустить ssh-сервер .

Настройки безопасности SSH сервера.

Протокол по умолчанию.

Опять же в современных дистрибутивах по умолчанию реализуется протокол SSH2. Если в Вашем случае указано нечто вроде:

 Protocol 2,1

Необходимо оставить только 2:

 Protocol 2

Использование небезопасного протокола SSH1 не рекомендуется.

Авторизация супер пользователя root.

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

По умолчанию в последних релизах Ubuntu, доступ пользователя root  через SSH ограничен.

 PermitRootLogin without-password

Позволяет авторизоваться пользователю root по ключам, при этом авторизацию по паролю запрещает.

Я рекомендую Вам изменить параметр на no:

 PermitRootLogin no

С такими настройками пользователь root  не сможет авторизоваться по SSH.

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

Еще немного о root  в Ubuntu, созданный по умолчанию пользователь (при установке системы) может решать все административные задачи через sudo. Активировать пользователя root для доступа к системе мне кажется не обоснованным решением.

Предоставление доступа только указанным пользователям или группам.

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

 AllowUsers user1 user2

Также Вы можете указать необходимую группу, например administrators:

 AllowGroups administrators

Запретите доступ с «пустыми» паролями.

Вы должны явно запретить удаленный доступ с использованием пустых паролей:

 PermitEmptyPasswords no

Изменение стандартного порта.

SSH по умолчанию работает на 22 порту. Соответственно основная масса атак будет направлена именно на этот порт, далее используя подбор имени пользователя и пароля, будут происходить попытки получить доступ к серверу. Мы уже исключили самое известное имя пользователя из базы возможного злоумышленника (root) и разрешили доступ только определенным пользователям, теперь сократим количество возможных атак (боты, ищущие уязвимости на стандартных портах), изменив порт, используемый по умолчанию (новый порт должен быть свободен!).

 Port 22

Изменим, к примеру, на:

 Port 2220

Стоит понимать, что изменение порта никак не поможет Вам при целенаправленной атаке brute-force (подбор пароля). Злоумышленник может, например, пройтись сканером портов по IP адресу, на котором распложен Ваш сервер, в результате он получит список всех открытых портов.

Также помните, что теперь для подключения к серверу помимо IP адреса Вам нужно указать и номер порта.

Авторизация на основе SSH2 RSA – ключей.

Действительно рабочим вариантом защиты от перебора является использование для аутентификации SSH2 RSA-ключей.  При таком способе пользователь генерирует пару ключей, из которой один ключ является секретным, а другой публичным. Публичный ключ находится  на сервере и служит для проверки идентичности пользователя. Плюс ко всему связку ключ – публичный ключ можно обезопасить парольной фразой, повысив криптостойкость  авторизации. Логика проста, не используете для авторизации пароль – подбирать нечего!

Заходим в систему под тем пользователем, которому будем настраивать доступ по SSH к серверу.

Сгенерируем RSA ключ длинной 4096, Вам будет предложено указать место хранения, оставим по умолчанию (/home/UserName/.ssh/id_rsa), также будет предложено задать пароль на создаваемый ключ. Если пароль не указывать, то во время аутентификации на сервере по сертификату вводить его не придется, это менее надежно. Рекомендую Вам указать пароль:

 ssh-keygen -t rsa -b 4096

В указанной директории будет создана пара ключей:

id_rsa.pub — публичный

id_rsa – приватный

Проверим, созданы ли файлы:

 cd ~/.ssh ls -al

Установим права на папку и файлы:

 sudo chmod 0700 ~/.ssh/ sudo chmod 0600 ~/.ssh/id*

Приватный ключ необходимо передать клиенту защищенным образом и удалить с сервера во избежание компрометации ключей.

Ключ id_rsa передается клиенту:

 /home/UserName/.ssh/id_rsa

После чего удаляется с сервера:

 sudo rm /home/UserName/.ssh/id_rsa

Создадим файл authorized_keys (находимся в системе под тем же пользователем “UserName”, для которого создавался сертификат) и скопируем в него содержимое файла id_rsa.pubопределим владельца и выставим права на директорию и файл.

 cd ~/.ssh sudo touch authorized_keys sudo chown UserName:UserName authorized_keys sudo cat id_rsa.pub >> authorized_keys sudo chmod 0700 ~/.ssh/ sudo chmod 0600 ~/.ssh/authorized_keys

Проверим, что текст скопировался:

 sudo cat /home/UserName/.ssh/authorized_keys

Если текст успешно скопирован, можно удалить публичный ключ:

 sudo rm /home/UserName/.ssh/id_rsa.pub

Включаем авторизацию по ключам:

 sudo nano /etc/ssh/sshd_config

Необходимо раскоментировать строки и выставить параметры следующим образом:

 # разрешаем авторизацию при помощи ключей PubkeyAuthentication yes  # Путь, где будут находиться ключи, с которыми можно соединяться для каждого пользователя свой файл в его директории. AuthorizedKeysFile %h/.ssh/authorized_keys

Перезапустим SSH сервер:

 sudo service ssh restart

После того, как Вы сформировали сертификаты для всех пользователей (кому необходим доступ по SSH), рекомендую Вам отключить аутентификацию по паролю, отредактировав все тот же файл /etc/ssh/sshd_config

Внимание перед отключением аутентификации по паролю убедитесь в возможности доступа по ключу

 PasswordAuthentication no
Подключение к SSH серверу через PuTTY, используя сертификат.

Для начала необходимо выполнить конвертацию приватного ключа (ключ пользователя UserName), который ранее мы забрали с сервера.

Для этого нам потребуется программа PuTTYgen.

Загружаем файл приватного ключа «Conversions — Import Key«.

Если Вы установили, пароль вводим его.

Выбираем «Save private key» и сохраняем полученный ppk файл. Хранить его стоит в месте, где он не сможет быть скомпрометирован.

Открываем программу PuTTY  и настраиваем соединение:

Session — Host Name (or IP Address)  IP адрес хоста, на котором настраивался SSH Сервер;

Session — Port Порт, указанный в настройках SSH сервера;

SessionSavedSession Название сессии (соединения);

Connection — Data — Autologin username Имя пользователя;

Connection — SSH — Auth — Private key file for authentication Путь к ppk файлу;

Session — Save Сохраняем сессию;

Session — Saved Session (выбираем нашу сессию) — LoadOpen — Сессия должна запуститься;

Вводим пароль и нажимаем Enter, после этого попадаем в систему.

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

Для того, чтобы закрыть доступ пользователю UserName к Хосту по сертификату, перейдем в папку где хранится его сертификат:

 cd ~/.ssh

Удалим файл его публичного сертификат authorized_key с сервера OpenSSH, если же вы неосмотрительно не удаляли файлы id_rsa.pub и id_rsa, удалите их. Просматриваем содержимое каталога коммандой «ls».

Удаляем необходимые файлы:

 sudo rm authorized_key id_rsa.pub id_rsa

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

Изменение времени ожидания авторизации.

При авторизации по SSH у Вас есть 2 минуты, чтобы ввести логин и пароль. Если вы этого не сделаете, то соединение с сервером будет разорвано.

В примере ниже это время ограничено до 30 секунд:

 LoginGraceTime 30

Таймаут при отсутствии активности соединения.

Автоматическое отключение соединения после определенного времени, в течение которого зафиксировано бездействие в консоли.

ClientAliveCountMax – Параметр указывает на полное количество сообщений, отсылаемых ssh-сервером для распознавания активности ssh-клиента. По умолчанию это 3.

ClientAliveInterval – Параметр указывает на время ожидания в секундах. По истечению ssh-сервер отошлет сообщение-запрос клиенту. По умолчанию значение этого параметра – 0. Сервер не отсылает сообщение для проверки.

Отключение ssh-клиента автоматически после 5 минут (300 секунд):

 ClientAliveInterval 300 ClientAliveCountMax 0

Раздел:Unix сервераTop

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

  • https://losst.ru/ustanovka-ssh-ubuntu-16-04
  • https://www.aitishnik.ru/linux/ssh-debian/nastroyka-openssh.html
  • https://a-rm.ru/materials/unix-servera/ustanovka-i-nastroyka-ssh-ubuntu

Рейтинг автора
5
Подборку подготовил
Максим Уваров
Наш эксперт
Написано статей
171
Ссылка на основную публикацию
Похожие публикации