SSH для новичков: безопасное подключение к Linux-серверу

SSH — это базовый и самый удобный способ удалённо заходить на Linux-сервер, но именно из-за своей доступности он часто становится целью перебора паролей и других атак. Если настроить SSH один раз правильно, сервер будет и удобным в работе, и заметно более безопасным.

Что такое SSH и зачем он нужен

SSH (Secure Shell) — это сетевой протокол, который создаёт защищённое соединение между вашим компьютером и удалённым Linux-сервером. В отличие от устаревших telnet или rlogin, весь трафик шифруется: логины, пароли, команды и передаваемые файлы невозможно перехватить в открытом виде. По умолчанию SSH работает поверх TCP на порту 22.

На практике SSH нужен для трёх типичных задач:

• подключиться к VPS или выделенному серверу;
• администрировать домашний или рабочий Linux-узел;
• передавать файлы и выполнять команды без физического доступа к машине.

Именно через SSH вы будете настраивать веб-серверы, базы данных, смотреть логи и запускать скрипты. Это инструмент, с которого начинается работа любого системного администратора.

Как устроено подключение по SSH

В SSH участвуют две стороны:

• клиент — ваш ноутбук, ПК или другой сервер;
• сервер — Linux-машина, к которой вы подключаетесь.

Подключение обычно выглядит так:

ssh username@server_ip

Если сервер слушает нестандартный порт:

ssh -p 2222 username@server_ip

При первом подключении клиент запоминает уникальный отпечаток (fingerprint) серверного ключа. Это защита от атак «человек посередине»: если сервер внезапно «стал другим», клиент предупредит вас о подмене. Внутри сессии все данные шифруются с использованием симметричного шифрования, а для аутентификации могут применяться пароли или ключи.

Самый безопасный способ входа: ключи, а не пароль

Для новичка главный шаг к нормальной защите SSH — перейти с пароля на SSH-ключи. Пароль можно подобрать или перехватить, а ключевая пара длиной 2048 бит и выше делает перебор практически невозможным. Ключевая пара состоит из:

• приватного ключа — хранится только у вас;
• публичного ключа — добавляется на сервер.

Сервер проверяет не пароль, а наличие соответствующего приватного ключа у клиента. Это намного безопаснее, чем вход по обычному паролю, особенно если сервер доступен из интернета.

Как выглядит схема

1. На своём компьютере создаёте пару ключей.
2. Публичный ключ загружаете на сервер.
3. Подключаетесь по ключу.
4. После проверки убеждаетесь, что вход по ключу работает.
5. Только потом отключаете парольный вход.

Пример создания ключа

ssh-keygen -t ed25519 -C "[email protected]"

Этот вариант считается хорошим стандартом для новых систем. Ed25519 обеспечивает высокую криптостойкость при небольшой длине ключа. Если нужен пароль на сам ключ, его стоит задать: это защитит ключ, если файл попадёт в чужие руки. Пароль запрашивается при каждом использовании ключа, но его можно кэшировать с помощью ssh-agent.

Как добавить ключ на сервер

ssh-copy-id username@server_ip

Если ssh-copy-id недоступен, публичный ключ можно вручную добавить в файл:

cat ~/.ssh/id_ed25519.pub | ssh username@server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

После копирования обязательно проверьте права: каталог ~/.ssh должен иметь режим 700, а authorized_keys — 600. Слишком открытые права — частая причина, по которой SSH отказывается принимать ключ.

Базовая настройка SSH на сервере

Главный конфигурационный файл обычно находится здесь:

/etc/ssh/sshd_config

Именно в нём задаются правила входа. Перед изменениями всегда делайте копию:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Что стоит проверить в первую очередь

Что обязательно отключить и почему

1. Вход под root

Прямой вход под root — плохая практика. Если кто-то подберёт доступ, он сразу получит максимальные права. Лучше использовать обычного пользователя и повышать права через sudo. Для этого в sshd_config ставят:

PermitRootLogin no

Иногда на переходном этапе используют:

PermitRootLogin prohibit-password

Это означает, что root не сможет входить по паролю, но ключевой доступ ещё разрешён. Для новичков безопаснее всё же полностью отключить root-вход, если нет особой причины оставлять его.

2. Парольный вход

После того как ключи проверены и вход по ним работает, парольный вход лучше отключить:

PasswordAuthentication no

Это резко снижает риск перебора паролей. Даже сложный пароль остаётся уязвимым для автоматических атак, в то время как ключ практически невозможно подобрать.

3. Лишние аккаунты

Чем меньше пользователей могут входить по SSH, тем лучше. Если сервером пользуются двое-трое человек, не стоит держать там десяток старых учёток «на всякий случай». Можно ограничить доступ так:

AllowUsers user1 user2

Все остальные системные или забытые учётные записи не смогут подключиться, даже если у них есть ключи.

Нужно ли менять порт SSH

Да, но с оговоркой: смена порта не делает сервер защищённым сама по себе. Это не защита, а скорее уменьшение шума от автоматических сканеров, которые массово проверяют стандартный порт 22. Если вы решите сменить порт, делайте это аккуратно:

• сначала откройте новый порт в firewall;
• затем добавьте его в конфиг SSH;
• перезапустите службу;
• проверьте вход во второй сессии;
• только потом закрывайте старый порт.

Пример

Port 2222

Типичная ошибка

Новичок меняет порт в конфиге, но забывает открыть его в firewall. В итоге сервер остаётся без удалённого доступа. Чтобы не попасть в такую ситуацию, всегда оставляйте уже открытое SSH-соединение до полной проверки нового входа.

Как проверить конфигурацию перед перезапуском

Перед перезапуском SSH проверьте синтаксис конфигурации:

sudo sshd -t

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

После этого можно перезапустить службу:

sudo systemctl restart ssh

На некоторых дистрибутивах служба может называться sshd:

sudo systemctl restart sshd

Минимальный безопасный набор настроек

Ниже — практичный стартовый вариант для небольшого Linux-сервера.

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers youruser

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

Защита от перебора: зачем нужен fail2ban

Если SSH доступен из интернета, кто-то рано или поздно начнёт подбирать пароль или проверять слабые настройки. Для этого часто используют fail2ban — инструмент, который смотрит логи и временно блокирует адреса с подозрительной активностью.

Принцип работы простой:

• сервис пишет ошибки входа в журнал;
• fail2ban видит повторяющиеся неудачные попытки;
• IP-адрес нарушителя временно блокируется через firewall (iptables или nftables);
• через заданное время блокировка снимается.

Когда fail2ban особенно полезен

• сервер открыт в интернет;
• SSH доступен на стандартном порту;
• есть риск брутфорса по паролям;
• на сервере пока ещё не всё идеально настроено.

Базовые параметры, которые важно понимать

Для домашнего или небольшого рабочего сервера часто используют умеренные значения: несколько попыток, окно 10 минут и бан на 10–60 минут. Не ставьте бан навсегда — вы рискуете заблокировать сами себя при ошибке.

Пошаговый порядок настройки SSH для новичка

Шаг 1. Создайте ключ на своём компьютере

ssh-keygen -t ed25519 -C "[email protected]"

Шаг 2. Скопируйте ключ на сервер

ssh-copy-id username@server_ip

Шаг 3. Проверьте вход по ключу

ssh username@server_ip

Шаг 4. Отредактируйте конфиг SSH

Проверьте и, если нужно, измените:

sudo nano /etc/ssh/sshd_config

Шаг 5. Проверьте синтаксис

sudo sshd -t

Шаг 6. Перезапустите SSH

sudo systemctl restart ssh

Шаг 7. Откройте новую сессию и протестируйте вход

Не закрывайте старую сессию, пока не убедитесь, что новый вход работает.

Шаг 8. Настройте firewall и fail2ban

Добавьте защиту от перебора и проверьте, что ssh-доступ открыт только там, где нужно.

Частые ошибки новичков

• Отключили парольный вход до того, как проверили ключи.
• Сменили порт, но не открыли его в firewall.
• Оставили root-вход включённым «пока временно».
• Забыли, что SSH-сервис может называться по-разному на разных системах.
• Потеряли доступ из-за ошибки в sshd_config и не оставили резервную сессию.
• Считают, что один только нестандартный порт решает вопрос безопасности.
• Установили слишком открытые права на файлы ключей (например, 644 вместо 600) — SSH молча отказывает в аутентификации.

Практический чек-лист безопасности SSH

• [ ] Вход по ключу работает.
• [ ] Парольный вход отключён.
• [ ] Root-вход отключён или строго ограничен.
• [ ] Открыт только нужный порт.
• [ ] Лишние пользователи удалены или отключены.
• [ ] Установлен и настроен fail2ban.
• [ ] Есть резервный способ доступа на случай ошибки.
• [ ] Конфиг проверен командой sshd -t.
• [ ] Права на ~/.ssh и authorized_keys корректны (700 и 600).

Если доступ уже есть, но всё настроено плохо

Иногда сервер приходится «спасать» уже после запуска. В этом случае порядок такой:

1. Открыть вторую активную SSH-сессию.
2. Настроить ключи.
3. Проверить вход по ключу.
4. Исправить sshd_config.
5. Проверить синтаксис.
6. Перезапустить SSH.
7. Убедиться, что повторный вход работает.
8. Только после этого закрыть пароли и root-доступ.

Вывод

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

FAQ

Можно ли оставить SSH с паролем, если сервер домашний?

Можно, но это слабее, чем вход по ключу. Если сервер доступен из интернета, лучше не полагаться на пароль. Даже в домашней сети пароль может быть скомпрометирован вредоносным ПО.

Обязательно ли менять порт SSH?

Нет. Это не обязательная мера. Смена порта уменьшает шум от автоматических сканеров, но не заменяет нормальную аутентификацию и firewall. Основная защита — ключи и отключение паролей.

Что важнее: fail2ban или ключи?

Сначала — ключи и отключение паролей. Потом уже fail2ban как дополнительный слой защиты. Если парольная аутентификация отключена, fail2ban всё равно полезен для блокировки сканирований и попыток подбора ключей (хотя последнее маловероятно).

Почему после изменений SSH перестал пускать?

Чаще всего причина в ошибке конфигурации, закрытом порте или неправильных правах на ключи. Всегда проверяйте конфиг командой sshd -t и не закрывайте рабочую сессию до теста.

Что делать, если потерял приватный ключ?

Нужно создать новую пару ключей и добавить публичную часть на сервер. Старый ключ лучше удалить из authorized_keys. Если доступ к серверу ещё есть по другому ключу или через консоль, сделайте это сразу. В противном случае придётся использовать аварийный доступ (например, через панель управления VPS).