Защита SSH: практические советы для Linux

SSH — это, пожалуй, самая нужная штука для тех, кто хоть как-то имеет дело с серверами. Без него как без рук: подключаешься к удалённой машине, гоняешь команды, редактируешь файлы, перетаскиваешь данные, и даже графические приложения можно запускать — всё, не вставая с дивана. Но, как и с любым мощным инструментом, стоит чуть-чуть расслабиться — и привет, взлом, утечка, бессонная ночь и куча нервов.

Я сам когда-то думал: «Да ладно, что с этим SSH может случиться? Он же безопасный!» А потом посмотрел логи и понял, что в мою машину ломятся какие-то боты с адресов вроде 203.0.113.45 по сто раз в минуту. И вот тогда я начал копать, как же всё это обезопасить. Ниже — не сухая инструкция, а скорее заметки с поля боя. Без академической серьёзности, но с реальными советами.

1. Поменяйте порт. Серьёзно, просто поменяйте

По умолчанию SSH слушает 22-й порт. Это как ставить замок на дверь и писать рядом табличку: «ключ лежит под ковриком». Боты именно на этот порт и лезут. Меняем на любой другой, хоть на 2200, хоть на 2025 — лишь бы не стандартный.

Открываем конфиг:

sudo nano /etc/ssh/sshd_config

Находим строку #Port 22, убираем решётку и меняем цифру. После этого не забудьте открыть новый порт в файрволе. Всё, уже меньше шансов, что вас будут долбить каждые 10 секунд.

2. Никогда не логиньтесь под root

Да, удобно. Да, чувствуешь себя всемогущим. Но если злоумышленник угадает пароль root, то привет — весь сервер в его руках. Лучше создать обычного пользователя, дать ему права sudo и спать спокойно.

В конфиге ищем:

PermitRootLogin yes

Меняем на:

PermitRootLogin no

Теперь в систему можно зайти только через «обычного» юзера. Безопаснее, хоть и чуть дольше.

3. Пароли — зло. Переходите на ключи

Пароль можно подобрать. Ключ — почти никогда. SSH-ключи — это как цифровой отпечаток пальца: уникальный и почти неповторимый.

Создаём пару ключей на своём компьютере:

ssh-keygen -t ed25519

А потом копируем публичный ключ на сервер:

ssh-copy-id user@server

Теперь логин без пароля, быстро и безопасно. Я сам это сделал и с тех пор забыл, как выглядит поле «Enter password».

4. Дайте доступ только своим

Если на сервере несколько пользователей, не стоит пускать всех подряд в SSH. Можно явно прописать, кто имеет право входа:

AllowUsers alice bob

Или даже ограничить по группам:

AllowGroups admins devops

Лишние люди — лишние риски. Всё просто.

5. Баннер при входе — не игрушка

Кто-то пишет туда «Добро пожаловать!», а кто-то — «Неавторизованный доступ карается законом». На мой взгляд, вторая опция лучше отпугивает. Создаёте файл /etc/issue.net, вписываете туда свой текст и добавляете строку:

Banner /etc/issue.net

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

6. Следите за тем, кто ломится

Периодически заглядывайте в логи. Даже если кажется, что всё спокойно, поверьте — там кипит жизнь. Проверяем:

sudo grep "Failed password" /var/log/auth.log

Я однажды увидел, что ко мне пытались войти под именем «admin» больше 500 раз за день. После этого поставил Fail2ban и больше не видел таких фейерверков.

7. Ограничьте IP-шники

Если вы заходите на сервер только из дома или офиса — так и скажите SSH-у, что других не пускать. В конфиге можно добавить:

AllowUsers user@192.168.1.100

Либо сделать это через файрвол. Тогда все посторонние будут посланы вежливо, но твёрдо.

8. Авторазрыв неактивных сессий

Оставил SSH-сессию открытой и ушёл на кофе — классика. А потом кто-то подходит и видит, что консоль доступна. Чтобы такого не было, ставим таймаут:

ClientAliveInterval 300 ClientAliveCountMax 0

Через 5 минут бездействия соединение отвалится. Просто и надёжно.

9. Двухфакторка для параноиков (и не только)

Да, вводить код с телефона немного раздражает. Но если сервер важный — лучше перестраховаться. Google Authenticator решает эту задачу за пять минут. Установили, связали, включили в PAM — и теперь без кода не войти. Даже если кто-то украдёт ваш пароль, толку ноль.

10. Fail2ban — ваш сторожевой пёс

Этот инструмент отслеживает неудачные попытки входа и банит агрессивные IP. Настроить легко: установили, включили jail для SSH, задали лимит попыток (например, три). Всё. Теперь бот, который ломится с энтузиазмом, быстро получает бан на несколько часов.

11. Чуть про шифры и безопасность

SSH умеет работать с кучей алгоритмов, но не все из них надёжны. Лучше явно прописать в конфиге, что вы используете только сильные шифры:

Ciphers aes256-ctr,aes192-ctr,aes128-ctr

И протокол только второй версии:

Protocol 2

Первый уже давно пора отправить на пенсию.

12. Проверяйте, кто сейчас на сервере

Простая команда:

who

или

w

— и вы видите всех, кто подключен. Если вдруг замечаете странного пользователя — можно аккуратно «выселить» его:

sudo pkill -u username

На практике я пару раз ловил забытые сессии коллег и спасал сервер от неприятностей.

13. Туннели и X11 — магия SSH

SSH умеет не только команды гонять, но и трафик через себя пропускать. Можно сделать, чтобы локальный порт шёл прямо на удалённый сервер. Пример:

ssh -L 8080:localhost:80 user@server

Теперь заходите на localhost:8080 — и видите сайт, который работает где-то в датацентре.

А если добавить флаг -X, можно даже запускать графические приложения. Когда первый раз открыл удалённый Gedit через SSH, честно — чуть не расплакался от восторга.

14. Включите сжатие — будет быстрее

Если соединение медленное, SSH может сам сжимать данные. Просто добавьте -C при подключении, и всё заработает шустрее. Особенно помогает при передаче логов или больших файлов.

15. А ещё можно сделать себе «алиасы»

Если у вас десяток серверов, вводить каждый раз IP и порт — то ещё удовольствие. Создайте файл ~/.ssh/config и добавьте туда что-то вроде:

Host myserver HostName 192.168.1.50 User alice Port 2200

Теперь просто пишете ssh myserver — и готово. Как избранное в браузере, только для серверов.

Вместо заключения

SSH — как швейцарский нож для системщика. Можно делать почти всё, но главное — не забывать, что и ножом можно порезаться. Меняйте порты, не используйте root, ставьте ключи и Fail2ban — и ваш сервер будет жить долго и счастливо.

И да, не думайте, что всё это перестраховка. Как показывает практика (и мой горький опыт), «да ладно, потом сделаю» обычно заканчивается бессонной ночью и срочным восстановлением системы из бэкапа. Лучше сделать всё сегодня, пока спокойно.