Постановка задачи: 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.
Дмитрий — Mar 24, 2016 at 06:22 PM
Добрый день. Подскажите пожалуйста по поводу настройки айпитаблиц и ssh.
Например таблица поймала брутфорсера по порту ssh, поместила запись в syslog с приставкой "iptables blocked: " это мы найдем в /var/log/syslog. А где искать сам интернет адрес заблокированный, если мы хотим его от туда удалить или добавить новые?
Дмитрий Владимирович — May 07, 2014 at 01:19 PM
Дошли руки обновить статью... Теперь у нас SSH работает как и положено по "best practice" )
Есть что возразить/добавить - внимательно слушаю.
Anonymous — Oct 20, 2010 at 12:00 PM
Порт я бы рекомендовал выбирать повыше... и добавить в файервол дополнительную защиту по данному порту