SSH и безопасность: урок по Linux к собеседованию

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

Ключи: как это работает

ssh-keygen -t ed25519 -C "deploy@ci"
ssh-copy-id user@server        # дописывает публичный ключ в ~/.ssh/authorized_keys

Пара ключей: приватный остаётся у тебя (~/.ssh/id_ed25519), публичный кладут на сервер в ~/.ssh/authorized_keys. При входе сервер проверяет, что клиент владеет приватным ключом: клиент подписывает данные сессии, сервер проверяет подпись публичным ключом. Сам приватный ключ по сети не передаётся.

Алгоритм сегодня по умолчанию Ed25519: короткие ключи, быстрые подписи. RSA допустим с длиной от 3072 бит. DSA устарел и отключён в современных OpenSSH.

Приватный ключ защищают паролем (passphrase), а чтобы не вводить его каждый раз, есть ssh-agent: ssh-add ~/.ssh/id_ed25519.

Права, без которых ключ не работает

sshd отказывается принимать ключ, если файлы доступны другим:

~/.ssh: 700;
~/.ssh/authorized_keys: 600 (или 644, но не на запись группе или всем);
приватный ключ у клиента: 600, иначе ssh ругается UNPROTECTED PRIVATE KEY FILE;
домашний каталог не должен быть доступен на запись группе или всем.

Ошибка в правах это самая частая причина «ключ скопировал, а просит пароль». Диагностика: ssh -vvv на клиенте и лог sshd на сервере (journalctl -u ssh, в Ubuntu юнит называется ssh).

Клиентский конфиг

# ~/.ssh/config
Host prod-api
    HostName 10.0.1.15
    User deploy
    IdentityFile ~/.ssh/deploy_ed25519
    ProxyJump bastion

Host bastion
    HostName bastion.example.com
    User ops

ProxyJump (или ssh -J bastion prod-api) ходит через бастион без копирования ключей на него. Agent forwarding (ssh -A) удобен, но опасен: root на промежуточном сервере может воспользоваться твоим агентом, пока ты подключён. ProxyJump безопаснее.

Туннели

ssh -L 5433:db.internal:5432 bastion   # локальный порт 5433 → db.internal:5432 через bastion
ssh -R 8080:localhost:3000 server      # порт 8080 на server → твой localhost:3000
ssh -D 1080 server                     # SOCKS-прокси
ssh -N -f -L ...                       # без shell, в фоне

-L нужен, чтобы дотянуться до базы во внутренней сети. -R пробрасывает наружу то, что у тебя локально.

Харднинг sshd

/etc/ssh/sshd_config (или файлы в /etc/ssh/sshd_config.d/):

PermitRootLogin no            # или prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowUsers deploy ops
MaxAuthTries 3

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

Перенос SSH на нестандартный порт уменьшает шум в логах, но не защищает: сканеры найдут порт. Настоящая защита это ключи вместо паролей, ограничение по IP и fail2ban.

fail2ban и логи входа

Попытки входа пишутся в /var/log/auth.log (Debian, Ubuntu) или /var/log/secure (RHEL) и в журнал. Строки вида Failed password for invalid user admin from 203.0.113.7. fail2ban читает логи и временно банит IP через фаервол после N неудачных попыток.

last            # кто входил
lastb           # неудачные попытки (root)
who; w          # кто сейчас в системе

sudo

Вместо входа под root пользователи работают под своими учётками и повышают права через sudo. Правила в /etc/sudoers и /etc/sudoers.d/, редактировать только через visudo: он проверит синтаксис, а сломанный sudoers может лишить тебя root.

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart api

Принцип минимальных прав: разрешать конкретные команды, а не ALL. Опасная ловушка: разрешённая программа, из которой можно запустить shell (vim, less, find -exec), даёт полный root.

Первые 30 минут с новым сервером

Обновить пакеты, включить автоматические обновления безопасности (unattended-upgrades).
Создать пользователя, выдать sudo, положить ключ.
Запретить вход root и по паролю, проверить в новой сессии.
Фаервол: открыть только нужные порты (ufw allow 22,80,443/tcp).
fail2ban, синхронизация времени, мониторинг и логи.
Не держать секреты в истории shell и в репозитории.

Частые ошибки

Неверные права на ~/.ssh и authorized_keys.
Приватный ключ в репозитории или общий ключ на всю команду.
PasswordAuthentication no выключили, не проверив вход по ключу.
ssh -A на недоверенные серверы.
NOPASSWD: ALL для сервисного пользователя.

Что спросят на собесе

Как работает аутентификация по ключу и что передаётся по сети.
Что сделаешь в первую очередь с новым сервером.
Чем -L отличается от -R.
Почему agent forwarding опасен и чем заменить.
Вход по ключу не работает: что проверишь.

SSH и безопасность сервера за 7 минут