Сеть в Linux и SSH

Вы генерируете пару ключей. Публичный ключ попадает в authorized_keys на сервере, приватный остаётся на вашей машине. При подключении сервер отправляет вызов (challenge), который может подписать только владелец приватного ключа, и проверяет подпись публичным ключом. Приватный ключ никогда не передаётся по сети. Пароли можно подобрать, использовать повторно или выманить фишингом, а каждый публичный SSH-порт постоянно получает brute-force-попытки. У ключа гораздо больше энтропии, чем у любого пароля, а под парольной фразой он ещё и бесполезен тому, кто украдёт файл. Кроме того, можно отозвать ключ одного устройства, не затрагивая остальные.

Иду слой за слоем. Сначала DNS: dig +short example.com должен вернуть IP сервера. Затем доступность: curl -I снаружи и проверка, что файрволы провайдера и ufw пропускают 80 и 443. На сервере ss -tlnp показывает, слушает ли nginx эти порты, а systemctl status nginx и nginx -t — работает ли он с валидным конфигом. Дальше я обхожу nginx и делаю curl напрямую к приложению на его локальном порту. Если это не работает, журнал или лог приложения скажут почему. Если работает, проблема в конфиге прокси или в TLS, что наглядно показывает curl -v.

ss выводит сокеты: -t для TCP, -l для слушающих, -n для числовых портов вместо имён и -p для процесса-владельца. Он отвечает на вопрос «что открыто на этой машине и кто это открыл». Адрес важен: 127.0.0.1 означает, что подключаться могут только локальные процессы, 0.0.0.0 (или [::]) — все интерфейсы, включая публичный. База данных или Redis, слушающие 0.0.0.0 на хосте, смотрящем в интернет, в одной ошибке файрвола от того, чтобы оказаться открытыми, а открытые базы находят и атакуют сканеры за считаные часы. Поэтому я привязываю внутренние сервисы к localhost или к интерфейсу частной сети.

Через SSH-туннель. ssh -N -L 5433:127.0.0.1:5432 your_user@server открывает порт 5433 на моём ноутбуке, и всё, что к нему подключается, идёт внутри зашифрованной SSH-сессии и выходит на сервере как локальное подключение к PostgreSQL. Мой клиент БД смотрит на localhost:5433. База продолжает слушать только localhost, так что в файрволе ничего не открывается. Если база работает на отдельном приватном хосте, я прокладываю туннель через сервер приложения или бастион с ProxyJump. Для команды разовые туннели можно заменить VPN вроде WireGuard или управляемым инструментом доступа.

По умолчанию нет, и это многих удивляет. Когда вы публикуете порт через -p 8080:80, Docker вставляет собственные правила iptables, которые перенаправляют трафик в контейнер раньше, чем проверяются правила ufw, поэтому порт доступен из интернета, даже если ufw его запрещает. Самое простое решение — публиковать порт только на localhost, например -p 127.0.0.1:8080:80, и ставить перед ним nginx. Docker также поддерживает фильтрацию в цепочке DOCKER-USER, а облачный файрвол провайдера перед сервером блокирует трафик в любом случае. Я всегда проверяю снаружи сканированием портов или через curl.

Оба копируют файлы по SSH. scp — это простое копирование, как cp между машинами: он всегда передаёт файл целиком и почти не имеет опций. rsync сравнивает источник и назначение и отправляет только изменения, поэтому повторные синхронизации больших каталогов идут быстро. Он умеет докачивать прерванные передачи, сохранять права, владельцев и временные метки с -a, сжимать с -z, исключать по шаблонам и точно зеркалировать каталог с --delete. Поэтому он правильный инструмент для деплоя статических сборок и для бэкапов. Когда участвует --delete, я всегда сначала запускаю его с --dry-run и слежу за завершающим слэшем в пути источника.

Копирование личных публичных ключей на каждый сервер работает для двух человек и пяти серверов; дальше онбординг и особенно offboarding становятся источником ошибок. Лучшая модель — централизованная идентичность с короткоживущими учётными данными. SSH-сертификаты, подписанные внутренним CA и выдаваемые на несколько часов после single sign-on, означают, что серверы доверяют одному ключу CA и при уходе человека ничего не нужно чистить. Инструменты вроде Teleport, облачные менеджеры сессий или SSH engine в HashiCorp Vault автоматизируют выдачу и добавляют запись сессий. Поместите серверы в частную сеть, доступную через bastion или VPN-mesh вроде WireGuard или Tailscale, чтобы SSH вообще не был открыт публично. Цена — эксплуатация самого CA или инструмента и необходимость аварийного пути доступа на случай, если он недоступен.

При agent forwarding (-A) удалённый сервер получает сокет к вашему локальному ssh-agent. Приватный ключ никогда не покидает ваш ноутбук, но любой, у кого есть root на этом сервере или доступ к вашему пользователю там, может через этот сокет аутентифицироваться от вашего имени на любом другом хосте, пока вы подключены. На общем или скомпрометированном jump-хосте это реальный риск lateral movement. Для доступа к внутренним серверам более безопасная замена — ProxyJump (-J): соединение с целевым сервером туннелируется через bastion, но аутентификация идёт end to end с вашего ноутбука, так что bastion никогда не касается ваших ключей. Для pull из Git на сервере используйте read-only deploy key для конкретного репозитория, а не пробрасывайте личный агент.

Оба, потому что они ломаются по-разному. Облачный файрвол провайдера фильтрует трафик до того, как он дойдёт до машины, переживает неправильно настроенный или сброшенный набор правил хоста и не обходится правилами iptables от Docker. Файрвол на хосте работает независимо от провайдера, позволяет выразить более тонкие правила, например ограничения по интерфейсу или источнику, и продолжает защищать хост, если облачные правила по ошибке изменят. Ни один из них не заменяет привязку внутренних сервисов к localhost или приватному интерфейсу, которая полностью убирает экспозицию, а не фильтрует её. Сверху добавляются rate limit и fail2ban для эндпоинтов входа, а также CDN или прокси перед веб-трафиком для поглощения DDoS, при этом origin принимает веб-трафик только с диапазонов прокси. Цена — поддерживать согласованность двух наборов правил, в идеале в виде кода.