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

SSH - UBUNTU

" Вы начинающий админ и хотите, например, поднять свой веб сервер. Идете в интернет, находите подходящую Вам статью и вперед! Давайте обратим внимание на один Важный момент, практически во всех этих статьях дается минимум команд для запуска необходимых служб и сервисов. Хорошо - заработало! А все ли Вы сделали для того, чтобы работать не перестало? Используете 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 сервера;

Session - Saved Session Название сессии (соединения);

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

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

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

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

Вводим пароль и нажимаем 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
7 комментариев
  • Я не совсем понимаю как правильно реализовать следующие действия...

    Ключ id_rsa передается клиенту:
    /home/UserName/.ssh/id_rsa

    После чего удаляется с сервера:
    sudo rm /home/UserName/.ssh/id_rsa

    Можно более подробно пояснить как передать приватный ключ клиенту?

  • Любым удобным для Вас способом! Забираете с сервера через флеш накопитель, по сети или через WinSCP например. Если опасаетесь, можно создать зашифрованный архив с  ключем. Далее передаете клиенту.

  • Спасибо, было понятно и доступно для настройки

  • Только начал разбираться с LINUX. Что делает команда sudo chown UserName:UserName authorized_keys ?

  • Добрый день.

    Команда chown устанавливает владельцем файла authorized_keys пользователя UserName:UserName.

    Где UserName:UserName имя пользователя (и его группа) для которого Вы настраиваете доступ.

  • Добрый день!

    Возник такой вопрос, При установке системы был создан пользователь (gocha) с root правами, когда я начинаю генерировать ключи sudo ssh-keygen -t rsa -b 4096 то они попадают не в директорию /home/UserName/.ssh а в директорию /root/.ssh;
    Если ту же команду выполняю без повышения привилегии то он предлагает каталог пользователь но не может создать ключи и каталог

  • Добрый день, прошу прощения за долгое молчание (отпуск).

    Команду необходимо выполнять из под пользователя для которого настраиваете доступ. В Вашем случае gocha, выполнять надо с повышением прав, т.е. sudo. Также необходимо изменить путь к каталогу пользователя, UserName нужно заменить на Вашего пользователя, т.е. gocha: /home/gocha/.ssh

Добавить комментарий