Установка и настройка SSH — Ubuntu. ПАМЯТКА.
Итак, SSH (secure shell) – безопасный сервер терминалов, предоставляет удаленный доступ к системе. Безопасный, т.к. весь трафик между клиентом и сервером шифруется.
А так ли он безопасен с настройками по умолчанию? Если Вы имеете сервер с возможностью подключения по SSH через интернет, обязательно найдутся желающие подобрать пароль для входа. Думаю, не стоит объяснять, что возможный злоумышленник сможет получить практически неограниченный доступ к системе.
Во всех современных дистрибутивах Ubuntu разработчики пытаются повысить уровень безопасности при стандартных параметрах, но этого не всегда бывает достаточно, а иногда мы сами выбираем неправильную концепцию и совершаем ошибки.
1. Установка SSH сервера в Ubuntu.
Установка SSH сервера в Ubuntu выполняется следующей командой:
$ sudo apt-get install ssh openssh-server
После установки SSH сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:
Основной файл конфигурации SSH — сервера — файл /etc/ssh/sshd_config , доступный для чтения или редактирования только супер пользователю ( root ). Для применения изменений необходимо перезапустить ssh-сервер.
2. Настройки безопасности SSH сервера.
Протокол по умолчанию.
Опять же в современных дистрибутивах по умолчанию реализуется протокол SSH2 . Если в Вашем случае указано нечто вроде:
Необходимо оставить только 2:
Использование небезопасного протокола SSH1 не рекомендуется.
3. Авторизация супер пользователя root.
Правильнее будет авторизоваться под пользовательской учетной записью и повышать свои привилегии с помощью команды sudo su, либо использовать sudo.
По умолчанию в последних релизах Ubuntu, доступ пользователя root через SSH ограничен.
Позволяет авторизоваться пользователю root по ключам, при этом авторизацию по паролю запрещает.
Я рекомендую Вам изменить параметр на no :
С такими настройками пользователь root не сможет авторизоваться по SSH.
Также данный параметр будет удобен, если с сервером работает несколько администраторов под учетной записью супер пользователя. Администраторы будут заходить под своей учетной записью и только после этого получать привилегии root, это намного облегчит аудит сервера и действий, которые выполняют администраторы.
Еще немного о root в Ubuntu, созданный по умолчанию пользователь (при установке системы) может решать все административные задачи через sudo. Активировать пользователя root для доступа к системе мне кажется не обоснованным решением.
4. Предоставление доступа только указанным пользователям или группам.
Представим, что на Вашем сервере есть определенное количество пользователей, но предоставлять доступ по SSH необходимо только некоторым. Так давайте ограничим круг пользователей имеющих доступ:
Также Вы можете указать необходимую группу, например administrators :
Черный список пользователей. Указывает, какие пользователи не должны получать доступ к системе через SSH.
5. Запретите доступ с «пустыми» паролями.
Вы должны явно запретить удаленный доступ с использованием пустых паролей:
6. Изменение стандартного порта.
SSH по умолчанию работает на 22 порту. Соответственно основная масса атак будет направлена именно на этот порт, далее используя подбор имени пользователя и пароля, будут происходить попытки получить доступ к серверу.
Мы уже исключили самое известное имя пользователя из базы возможного злоумышленника (root) и разрешили доступ только определенным пользователям, теперь сократим количество возможных атак (боты, ищущие уязвимости на стандартных портах), изменив порт, используемый по умолчанию (новый порт должен быть свободен!).
Стоит понимать, что изменение порта никак не поможет Вам при целенаправленной атаке brute-force (подбор пароля) . Злоумышленник может, например, пройтись сканером портов по IP адресу, на котором распложен Ваш сервер, в результате он получит список всех открытых портов.
Также помните, что теперь для подключения к серверу помимо IP адреса Вам нужно указать и номер порта.
7. Авторизация на основе SSH2 RSA – ключей.
Действительно рабочим вариантом защиты от перебора является использование для аутентификации SSH2 RSA-ключей . При таком способе пользователь генерирует пару ключей, из которой один ключ является секретным, а другой публичным. Публичный ключ находится на сервере и служит для проверки идентичности пользователя. Плюс ко всему связку ключ – публичный ключ можно обезопасить парольной фразой, повысив криптостойкость авторизации. Логика проста, не используете для авторизации пароль – подбирать нечего!
Заходим в систему под тем пользователем, которому будем настраивать доступ по SSH к серверу.
Сгенерируем RSA ключ длинной 4096 , Вам будет предложено указать место хранения, оставим по умолчанию ( /home/UserName/.ssh/id_rsa ), также будет предложено задать пароль на создаваемый ключ. Если пароль не указывать, то во время аутентификации на сервере по сертификату вводить его не придется, это менее надежно. Рекомендую Вам указать пароль :
В указанной директории ( /home/UserName/.ssh/id_rsa ) будет создана пара ключей:
id_rsa.pub — публичный
id_rsa – приватный
Проверим, созданы ли файлы:
Установим права на папку и файлы:
Приватный ключ необходимо передать клиенту защищенным образом и удалить с сервера во избежание компрометации ключей.
Ключ id_rsa передается клиенту:
После чего удаляется с сервера:
$ sudo rm /home/UserName/.ssh/id_rsa
Создадим файл authorized_keys (находимся в системе под тем же пользователем “ UserName ”, для которого создавался сертификат) и скопируем в него содержимое файла id_rsa.pub , определим владельца и выставим права на директорию и файл.
$ sudo touch authorized_keys
$ sudo chown UserName:UserName authorized_keys
$ sudo cat id_rsa.pub >> authorized_keys
$ 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
Необходимо раскоментировать строки и выставить параметры следующим образом:
# разрешаем авторизацию при помощи ключей
# Путь, где будут находиться ключи, с которыми можно соединяться для каждого пользователя свой файл в его директории.
После того, как Вы сформировали сертификаты для всех пользователей (кому необходим доступ по SSH), рекомендую Вам отключить аутентификацию по паролю, отредактировав все тот же файл /etc/ssh/sshd_config
Внимание перед отключением аутентификации по паролю убедитесь в возможности доступа по ключу.
В случае если сертификат пользователя был скомпрометирован, выполняем отзыв сертификата и запрещаем доступ пользователю.
Для того, чтобы закрыть доступ пользователю UserName к Хосту по сертификату, перейдем в папку где хранится его сертификат:
Удалим файл его публичного сертификат authorized_key с сервера OpenSSH, если же вы неосмотрительно не удаляли файлы id_rsa.pub и id_rsa , удалите их. Просматриваем содержимое каталога коммандой «ls».
Удаляем необходимые файлы:
$ sudo rm authorized_key id_rsa.pub id_rsa
Также хорошим тоном будет ограничение времени на ввод данных для авторизации, ну и таймаут при отсутствии активности.
8. Изменение времени ожидания авторизации.
При авторизации по SSH у Вас есть 2 минуты, чтобы ввести логин и пароль. Если вы этого не сделаете, то соединение с сервером будет разорвано.
В примере ниже это время ограничено до 30 секунд:
9. Таймаут при отсутствии активности соединения.
Автоматическое отключение соединения после определенного времени, в течение которого зафиксировано бездействие в консоли.
ClientAliveCountMax – Параметр указывает на полное количество сообщений, отсылаемых ssh-сервером для распознавания активности ssh-клиента. По умолчанию это 3.
ClientAliveInterval – Параметр указывает на время ожидания в секундах. По истечению ssh-сервер отошлет сообщение-запрос клиенту. По умолчанию значение этого параметра – 0. Сервер не отсылает сообщение для проверки.
Отключение ssh-клиента автоматически после 5 минут (300 секунд):
10. Запретите использование файлов .rhosts.
Не разрешайте использовать файлы ~/.rhosts и ~/.shosts, имеющиеся у пользователя. Измените в файле sshd_config следующую настройку:
Сервер SSH может эмулировать поведение устаревшей команды rsh, так что запретите небезопасный доступ через RSH.
11. Запретите кросс-хостинговую аутентификацию (Host-Based Authentication).
Для того, чтобы запретить кросс-хостинговую аутентификацию, впишите в файл sshd_config следующую опцию:
ДОПОЛНИТЕЛЬНО.
Аутентификация без пароля. Вариант 2.
Использование ssh пароля для входа на сервер не только неудобно но и небезопасно, потому что этот пароль в любой момент может быть подобран. Самый надежный и часто используемый способ аутентификации — с помощью пары ключей RSA. Секретный ключ хранится на компьютере, а публичный используется на сервере для удостоверения пользователя.
Настроить такое поведение очень легко.
Генерируем ключ.
Сначала создайте ключ командой:
$ ssh-keygen -t rsa -b 4096
$ ssh-keygen -t dsa -b 4096
Особенной разницы между этими технологиями для простого обывателя нет, обе достаточно надежны, поэтому в выборе можно особенно не заморачиваться.
$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/serg/.ssh/id_rsa): «Enter»
Нам предлагают указать место для хранения нашего ключа. По умолчанию этобудет папка .ssh в вашей домашней директории. Для того, чтобы согласиться с настройками по умолчанию, просто нажимаем «Enter».
Enter passphrase (empty for no passphrase): («Enter». ) 7WrmZB8G
Введите пароль (пустой без пароль):
Enter same passphrase again: («Enter». ) 7WrmZB8G
Eсли хотите подключаться без пароля — поле Passphare оставьте пустым. Просто жмем «Enter».
Затем отправляем ключ на сервер:
$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host
SSH сервер естественно должен быть настроен на аутентификацию по ключам, приведу кусок, касающийся аутентификации, своего файла конфигурации, SSH сервера. Все что закомментировано в файле конфигурации SSH, отсюда убрал, для простоты восприятия:
$ sudo mcedit /etc/ssh/sshd_config
# разрешаем авторизацию при помощи ключей
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
UseLogin no
Внимание перед отключением аутентификации по паролю убедитесь в возможности доступа по ключу.
Вот и все. Теперь при попытке подключится к этому серверу будет запрашиваться пароль 7WrmZB8G после чего произойдет подключение.
Использование программы ssh-agent.
Как было сказано выше, в целях безопасности, приватный ключ, всегда должен быть защищен секретной фразой ( паролем ), но это вызывает некоторые неудобства, вам придется вводить секретную фразу, каждый раз когда вы подключаетесь к удаленному серверу по ключу, было-бы гораздо проще ввести пароль на ключ один раз и пользоваться им сколько потребуется. На этот случай в пакете OpenSSH , существуют специальные программы ssh-agent и ssh-add , в общем-то вторая является дополнением первой.
Как это работает. Поле запуска программы ssh-agent , в нее добавляются расшифрованные ключи, то есть при добавлении она запросит секретную фразу ключа, для его дешифровки, и далее ssh-agent , будет выдавать уже расшифрованные ключи по запросу, например программе SSH.
Запускать ssh-agent , можно двумя способами, со специальной опцией, говорящей, какой тип оболочки используется, или с помощью команды eval . Принципиальной разницы как его запускать, нет, просто в случае с опцией, вы должны точно знать, какую оболочку вы используете.
Теперь нужно поместить в ssh-agent расшифрованные ключи, делается это с помощью программы ssh-add .
Enter passphrase for /root/.ssh/id_rsa: Запрос пароля на расшифровку 7WrmZB8G
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)
Теперь пробуем подключиться к удаленному SSH серверу:
Как видите пароль у нас больше никто не спрашивает, программа SSH, получает уже расшифрованный ключ от ssh-agent и мы успешно подключаемся к удаленному SSH серверу.