SSH (Secure Shell) — это сетевой протокол прикладного уровня для удаленного управления компьютером через незащищенную сеть: он шифрует весь трафик между клиентом и сервером, включая логин и пароль. В статье разберем, чем протокол SSH отличается от программы OpenSSH и от SSH-ключа, как проходит подключение, какие команды нужны в первую очередь и как закрыть сервер от подбора пароля.
Содержание
- SSH, OpenSSH и SSH-ключ: три вещи под одним названием
- Как проходит подключение: от TCP-соединения до сессии
- Аутентификация: пароль или ключ
- Преимущества и недостатки SSH
- Подключение: Linux, macOS, Windows
- Аутентификация по ключу: генерация и подключение
- Частые команды SSH и производных утилит
- Защита SSH-сервера: чем закрыть перебор
- Выводы
- Где применяется / связь с практикой
- FAQ
SSH, OpenSSH и SSH-ключ: три вещи под одним названием
Три термина часто путают, хотя они относятся к разным уровням одной технологии.
- SSH — сам протокол: описание правил, по которым клиент и сервер согласуют шифрование, проверяют друг друга и обмениваются данными. Протокол не привязан к конкретной программе.
- OpenSSH — свободная реализация протокола: набор программ
ssh,sshd,scp,sftp,ssh-keygen. Стоит по умолчанию на большинстве дистрибутивов Linux, в macOS и в Windows начиная с версии 10. Есть и другие реализации, например клиент PuTTY для Windows. - SSH-ключ — пара файлов (приватный и публичный), один из способов аутентификации внутри протокола. Ключ не протокол и не программа — это учетные данные, которыми пользуется клиент.
Действующая версия протокола — SSH-2, она вытеснила уязвимую SSH-1 и стандартизована IETF в RFC 4251-4254. Современные клиенты и серверы по умолчанию работают только по SSH-2.
Как проходит подключение: от TCP-соединения до сессии
Установление SSH-сессии проходит в четыре шага, и каждый следующий зависит от успеха предыдущего.
- TCP-соединение. Клиент открывает TCP-соединение с сервером на порту 22 (или на том, что задан явно).
- Согласование алгоритмов. Клиент и сервер обмениваются списками поддерживаемых алгоритмов шифрования и договариваются об общем наборе.
- Проверка сервера. Сервер присылает хост-ключ. При первом подключении клиент спрашивает подтверждение отпечатка и сохраняет его в
~/.ssh/known_hosts; при другом отпечатке на повторном подключении SSH откажется соединяться — защита от подмены сервера. - Аутентификация клиента. Сервер проверяет, что подключается тот, за кого себя выдает клиент: по паролю или по паре ключей.
После успешной аутентификации открывается зашифрованный канал, через который идут команды, вывод терминала и передаваемые файлы.
Аутентификация: пароль или ключ
У SSH два основных способа подтвердить личность клиента, и они не равноценны по устойчивости к перебору.
| Признак | Пароль | Публичный ключ |
|---|---|---|
| Что хранится на сервере | Хеш пароля | Публичный ключ в authorized_keys |
| Что нужно клиенту | Знать пароль | Приватный ключ (под passphrase) |
| Устойчивость к перебору по сети | Низкая, пароль подбирают боты | Приватный ключ по сети не передается и не подбирается |
| Риск при утечке базы сервера | Пароль скомпрометирован сразу | Публичный ключ безопасно раскрывать, приватный на сервер не попадает |
| Рекомендация для продакшена | Отключать | Основной способ |
Ключевое различие: пароль пересылается на сервер для сверки, пусть и по шифрованному каналу. При аутентификации по ключу сервер лишь проверяет, что клиент владеет приватным ключом, не получая его — клиент подписывает им проверочные данные.
Преимущества и недостатки SSH
| Плюсы | Минусы |
|---|---|
| Шифрует весь трафик, включая пароль | Ключ без passphrase небезопасен на скомпрометированном ноутбуке |
Передает файлы (scp, sftp) в том же канале |
Порт 22 постоянно сканируют боты — нужна доп. защита |
| Проверяет целостность данных | Root на сервере может прочитать чужую сессию на этом хосте |
| Пробрасывает порты и туннелирует другие протоколы | Пароль + разрешенный root-логин снимают почти все преимущества |
| Клиент есть почти в любой ОС «из коробки» | Не защищает от слабого пароля или утечки ключа — ответственность администратора |
Подключение: Linux, macOS, Windows
На Linux и macOS команда ssh встроена в систему, отдельно ставить ничего не нужно:
ssh exampleuser@203.0.113.10Здесь exampleuser — имя пользователя на сервере, 203.0.113.10 — его IP-адрес (документационный диапазон RFC 5737, для реального сервера подставляется собственный адрес). При первом подключении терминал попросит подтвердить отпечаток хост-ключа, затем — ввести пароль или passphrase от ключа.
В Windows 10 и новее команда ssh доступна прямо из PowerShell — это тот же OpenSSH-клиент, что и на Linux. Отдельный клиент вроде PuTTY нужен только для графического интерфейса с сохраненными профилями подключений.
Аутентификация по ключу: генерация и подключение
Ниже — минимальный рабочий пример: создать пару ключей, скопировать публичный ключ на сервер и подключиться без пароля.
ssh-keygen -t ed25519 -C "user@example.com"Команда создаст пару файлов: ~/.ssh/id_ed25519 (приватный, никому не передавать) и ~/.ssh/id_ed25519.pub (публичный). При генерации она попросит задать passphrase — пропускать этот шаг не стоит: без него кража файла с ноутбука равносильна краже пароля.
ssh-copy-id -i ~/.ssh/id_ed25519.pub exampleuser@203.0.113.10Утилита один раз запросит пароль пользователя на сервере и добавит содержимое id_ed25519.pub в файл ~/.ssh/authorized_keys этого пользователя. После этого:
ssh -i ~/.ssh/id_ed25519 exampleuser@203.0.113.10Подключение проходит без пароля: клиент запросит passphrase самого ключа (или возьмет его из ssh-agent, если сессия уже разблокирована), и сразу откроется командная строка сервера.
Частые команды SSH и производных утилит
| Команда | Что делает |
|---|---|
ssh user@host |
Подключение к удаленному серверу |
ssh -p 2222 user@host |
Подключение на нестандартный порт |
scp file.txt user@host:/tmp/ |
Копирование файла на сервер по SSH-каналу |
sftp user@host |
Интерактивная сессия передачи файлов |
ssh-keygen -t ed25519 |
Генерация пары ключей |
ssh-copy-id -i key.pub user@host |
Публикация публичного ключа на сервере |
ssh-agent / ssh-add |
Хранение расшифрованного ключа в памяти на время сессии |
ssh user@host "команда" |
Выполнение одной команды на сервере без интерактивной сессии |
Команды ls, cd, cat, grep в таблице не показаны — это обычные команды shell на сервере, а не часть протокола SSH.
Защита SSH-сервера: чем закрыть перебор
Самый частый из недостатков в таблице выше — открытость сервера для подбора учетных данных ботами по сети — устраняется настройками, а не самим протоколом. Остальные минусы настройками сервера не закрываются: от утечки расшифрованного ключа с ноутбука защищает только passphrase на самом ключе, а от чтения чужой сессии root-ом на хосте — разграничение доступа к серверу, это отдельная задача. Ниже — порядок с откатом только для той части, что решается конфигом: перед перезапуском службы держите открытой текущую SSH-сессию и по возможности вторую (или доступ через консоль хостинга), чтобы не остаться без доступа при ошибке в конфиге.
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bakДалее в /etc/ssh/sshd_config меняются три параметра:
PasswordAuthentication no
PermitRootLogin no
Port 2222
PasswordAuthentication no— главная мера: отключает вход по паролю, оставляя только аутентификацию по ключу. Без этого шага смена порта и остальные меры почти бесполезны — боты просто сканируют весь диапазон портов.PermitRootLogin no— запрещает прямой вход под root по SSH; администратор заходит под обычным пользователем и повышает права черезsudo, когда это нужно.Port 2222— смена порта с 22 на нестандартный снижает шум от автоматических сканеров в логах, но это не защита, а маскировка: адресный скан по всем портам ее обходит. Менять порт стоит только вместе с двумя пунктами выше, не вместо них.
Перед перезапуском службы проверяется синтаксис, затем применяется конфигурация:
sudo sshd -t
sudo systemctl restart sshdЕсли sshd -t вернул ошибку, конфиг не применяется — служба остается на старых настройках. Если после restart новая сессия не открывается, конфиг возвращается из резервной копии через уже открытую сессию: sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config && sudo systemctl restart sshd.
Дополнительный слой — fail2ban, который сам блокирует IP-адрес после нескольких неудачных попыток входа:
sudo apt install fail2ban
sudo systemctl enable --now fail2banОн анализирует логи sshd и добавляет правило файрвола для адреса, который слишком часто ошибается с аутентификацией. Это защита от онлайн-перебора, отдельная от отключения пароля, которое защищает от кражи учетных данных иным путем — через утечку базы или фишинг.
Выводы
- SSH — протокол шифрованного удаленного доступа; OpenSSH — его конкретная реализация; SSH-ключ — один из способов аутентификации внутри протокола, это три разных уровня одной технологии.
- Подключение проходит четыре шага: TCP-соединение, согласование алгоритмов, проверка хост-ключа сервера, аутентификация клиента.
- Аутентификация по ключу устойчивее к перебору по сети, чем по паролю, потому что приватный ключ не передается на сервер.
- Порт 22 сам по себе не проблема; проблема — разрешенный вход по паролю и под root. Смена порта маскирует сервер, но не заменяет
PasswordAuthentication no,PermitRootLogin noи fail2ban. - Перед изменением
sshd_configнужна резервная копия и открытая вторая сессия — иначе ошибка в конфиге отрежет доступ к серверу.
Где применяется / связь с практикой
Освойте тему на практике
Настройка SSH-доступа и защита сервера от перебора — базовая задача сетевого администратора и любого, кто держит хотя бы один сервер под управлением. Разобраться в этом системно, вместе с маршрутизацией, VPN и мониторингом сети, поможет курс Network Engineer в Otus.
Освойте тему на практике
Проверить формат занятий и посмотреть, как построена программа, можно на бесплатных открытых уроках Otus.
FAQ
Чем SSH отличается от SSL/TLS?
Оба протокола шифруют трафик, но решают разные задачи: SSH создан для удаленного управления сервером и туннелирования, а SSL/TLS — для защиты соединения между браузером и веб-сервером (HTTPS) и не дает интерактивной командной строки.
Что делать, если забыл passphrase от приватного ключа?
Расшифровать существующий приватный ключ без passphrase невозможно — это и есть смысл защиты. Остается сгенерировать новую пару ключей и заново добавить публичный ключ на сервер через любой оставшийся рабочий способ входа (второй ключ, пароль, консоль хостинга).
Почему SSH-подключение зависает, хотя порт открыт?
Обычно это не проблема самого протокола, а сеть: неверный IP или порт, файрвол, который принимает TCP-пакет, но не пропускает данные дальше, или разрыв на маршруте. Быстрая проверка — ssh -v для подробного лога и nc -zv host port для проверки доступности порта отдельно от SSH.
