настройка SSH и авторизация по ключам

или чем полезен SSH — его применение

Постановка задачи: SSH (Secure Shell) — это программа, позволяющая входить на другие удаленные компьютеры в сети, выполнять на них команды-программы или переносить данные с одной машины на другую. SSH строго обеспечивает секретность и достоверность передаваемых данных по незащищенным компьютерным каналам и представляет собой альтернативную замену таким известным и привычным средствам как: «rlogin», «rsh», «rcp» и «rdist». Наша цель — настроить ssh, обезопасить подключение к серверу и использовать ключи для авторизации…

1. Установка SSH и конфигурация

Итак, всё, что нам нужно для установки полного комплекта удалённого управления компьютером (SSH-клиент и SSH-сервер) давным-давно лежит в репозитории. Лёгким движением ставим пакет:

server:/# apt-get install ssh

и ждём несколько мгновений, когда оно настроится. После этого мы получим возможность SSH доступа в систему и управления ей. Так как технология эта кросс-платформенная, то можно управлять по SSH Linux или FreeBSD можно и из Windows. Для этого есть putty, SSH Windows клиент. Теперь надо поправить настройки, которые лежат в каталоге /etc/ssh - конфиг для клиента называется ssh-config, конфиг для сервера, соответственно, sshd-config.

Меняем порт на произвольный (например на 1222) и запрещаем прямой логин от имени root-а в файле конфигурации /etc/ssh/ssh-config

# Здесь задается номер порта, на котором работает ssh-сервер. Меняем!
Port 1222
# Оставляем только SSH по протоколу 2.
Protocol 2
# Запрещаем подсоединяться к ssh-серверу используя логин суперпользователя.
PermitRootLogin no
# Запрещать подсоединяться пользователям, у которых пустые пароли.
PermitEmptyPasswords no
# Ограничиваем доступ только вышеуказанными пользователями
AllowUsers demon dethroner

Рестарт сервиса:

server:/# service ssh restart
Замечание: Смена порта повысит нашу безопасность от роботов шарящих в интернете по стандартным портам 22, блокировка работы напрямую от root-а поставит дополнительный заслон (злоумышленнику придется взломать 2 пароля, — вначале пользователя, потом только root-а)

2. Авторизация через SSH-ключи (SSH Key Pair Authentication)

Пароли могут украсть, «подсмотреть» или Вы его можете просто забыть. Существует более удобный и безопасный способ авторизации: авторизация ключами. В этом разделе мы сгенерируем открытый и закрытую ключ (пару ключей) и покажем, как организовать доспут к серверу посредством ключей. Кстати, неоценимым преимуществом будет отсутствие необходимости вводить пароль в принципе и защита от перебора паролей в частности. Одно мгновение, и вот Вы уже авторизованы на сервере. Давайте разберемся в этой магии подробнее…

Генерацию ключей Вы можете выполнить как из под linux, так и используя программу PuTTYGen.

Правилом хорошего тона также является исключение входа по SSH для пользователя root. Я использую следующий подход — создаю пользователя, настраиваю доступ по ssh ключам на сервер и даю права в sudo, чтобы пользователь мог повысить свои привилегии до рутовых… Так и поступим.

root@server:/# adduser developer

Adding user `developer' …
Adding new group `developer' (1001) …
Adding new user `developer' (1001) with group `developer' …
Creating home directory `/home/developer' …
Copying files from `/etc/skel' …
Enter new UNIX password: ********
Retype new UNIX password: ********
passwd: password updated successfully
Changing the user information for developer
Enter the new value, or press ENTER for the default
        Full Name []:
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] y

Переключимся на этого пользователя, создадим папку ~/.ssh, создадим для него пару авторизационных ключей и добавим открытый ключ в authorized_keys

root@server:/# su - developer

developer@server:~$ mkdir  ~/.ssh
developer@server:~$ chown developer:developer ~/.ssh
developer@server:~$ chmod 700 ~/.ssh
developer@server:~$ cd ~/.ssh

developer@server:~/.ssh$ ssh-keygen -t rsa -f id_rsa_developer

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_developer.
Your public key has been saved in id_rsa_developer.pub.
The key fingerprint is:
d2:3b:61:90:23:21:d6:65:0f:6c:e1:55:0b:af:35:e1 developer@server
The key's randomart image is:
+--[ RSA 2048]----+
|         .+      |
|       . ooo. o  |
|      o o. .=  o |
|     . o +. . E  |
|      . S. . o . |
|       . +. .    |
|        o o      |
|         +       |
|                 |
+-----------------+

developer@server:~/.ssh$ cat ~/.ssh/id_rsa_developer.pub >> ~/.ssh/authorized_keys
developer@server:~/.ssh$ chmod 600 ~/.ssh/authorized_keys

В итоге, мы получим два ключа в папке ~/.ssh: id_rsa_developer и id_rsa_developer.pub. Открытый ключ (id_rsa_developer.pub) мы поместили в authorized_keys, чем разрешили пользователю developer входить по SSH на сервер, используя закрытый ключ (id_rsa_developer). Никому не передавайте этот ключ и храните его в надёжном месте — это и есть самая важная часть авторизации по SSH!

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

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Примечание: чтобы не просто отключить возможность входа пользователя root по ключам ssh, а инфрмировать что этот вариант на сервере отключён, добавьте в файл /root/.ssh/authorized_keys следующие команды непосредственно перед ключём ssh-rsa (всё в одной строке):

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"admin\" rather than the user \"root\".';echo;sleep 10" 
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAyhjryaPyNEjbflLwxjOilKx3xGX1fVhaSWQDCLxqQOSOAIjryaPyNEjbflLwxjOilKx3xGX1fVhaSWQDCLxqQOSOMxPApB6Idjy6jnbJJNwUv7obYnegs8rrLzV7Hgcy2imdhCEWtG2ULitra3fYerqb6n82e1RtN71G4/G0BCa4xNjryaPyNEjbflLwxjOilKx3xGX1fVhaSWQDCLxqQOSOvOZE7aSv0K8tJsT+n4ZuHDdh9LdJpiZW2aoq/z+jWQI4U+dDq76PR3EQqctMJUmyA82b865jryaPyNEjbflLwxjOilKx3xGX1fVhaSWQDCLxqQOSOs/uQ== root.pub

Они будут выполнены при попытке подключения к серверу пользователем root.

3. Защита ssh порта с помощью iptables

Cтавим защиту на порт SSH. Кстати, будьте аккуратны с iptables, в случае неверных телодвижений Вы можете запросто потерять доступ к серверу совсем, особенно если он «виртуальный»! Основная идея следующая — если кто-то пытается трижды за минуту авторизоваться на нашем SSH порту, блокируем его и вносим запись в лог-файл (syslog по умолчанию)

root@server:/# iptables -N FAILLOG
root@server:/# iptables -A FAILLOG -j LOG --log-prefix "iptables blocked: " --log-level 7
root@server:/# iptables -A FAILLOG -j DROP

root@server:/# iptables -A INPUT -p tcp -m tcp --dport 1222 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --name DEFAULT --rsource -j FAILLOG
root@server:/# iptables -A INPUT -p tcp --dport 1222 -m state --state NEW,ESTABLISHED -j ACCEPT
root@server:/# iptables -A OUTPUT -p tcp --sport 1222 -m state --state ESTABLISHED -j ACCEPT

Примечание: фактически, две последние команды излишние, так как наш файервол и так «открыт всем ветрам». Другое дело, если у вас «православный» iptables, который непременно закачивается политиками:

iptables -A INPUT -j DROP
iptables -A OUTPUT -j REJECT
iptables -A FORWARD -j DROP

В этом случае как-никогда актуально открыть порт, иначе доступ к серверу по SSH Вы потеряете, быть может навсегда).

Чтобы запомнить/восстановить правила iptables для дистрибутивов CentOS, Fedora и RHEL используйте:

root@server:/# iptables-save > /etc/iptables.up.rules
root@server:/# iptables-restore < /etc/iptables.up.rules
root@server:/# iptables -L

С другой стороны, возможно Вам пригодится «простой» вариант iptables для сервера, или более сложный вариант для «шлюза». Советую ознакомиться.

Комментарии 4

  1. Дмитрий — Mar 24, 2016 at 06:26 PM

    Кажется я понял. Он хранится в таблице FAILLOG до того момента пока мы не очистим таблицу iptables.

  2. Дмитрий — Mar 24, 2016 at 06:22 PM

    Добрый день. Подскажите пожалуйста по поводу настройки айпитаблиц и ssh.
    Например таблица поймала брутфорсера по порту ssh, поместила запись в syslog с приставкой "iptables blocked: " это мы найдем в /var/log/syslog. А где искать сам интернет адрес заблокированный, если мы хотим его от туда удалить или добавить новые?

  3. Дмитрий Владимирович — May 07, 2014 at 01:19 PM

    Дошли руки обновить статью... Теперь у нас SSH работает как и положено по "best practice" )
    Есть что возразить/добавить - внимательно слушаю.

  4. Anonymous — Oct 20, 2010 at 12:00 PM

    Порт я бы рекомендовал выбирать повыше... и добавить в файервол дополнительную защиту по данному порту

  • 1

Комментарии отключены, сожалеем