←Все статьи🇷🇺 Русский
•8 мин

SSH-ключи на Ubuntu — генерация, настройка, безопасность

Как настроить SSH-ключи на Ubuntu: ssh-keygen ed25519, ~/.ssh/config, права файлов, agent forwarding, fail2ban. Практический гайд.

sshssh-keygened25519ubuntusecurityfail2banserver

SSH-ключи — это пара криптографических файлов (приватный + публичный), заменяющая парольную аутентификацию при подключении к серверу. Ключ ed25519 длиной 256 бит взломать перебором невозможно — в отличие от пароля qwerty123, который подбирается за секунды. Если вы настраиваете VPS с нуля, SSH-ключи — один из первых шагов после базовой подготовки сервера.

Генерация SSH-ключей (ssh-keygen)

ssh-keygen — утилита для создания SSH-ключей, встроенная в OpenSSH на Ubuntu. Для новых серверов используйте алгоритм Ed25519:

ssh-keygen -t ed25519 -C "deployer@myproject"

Флаг -C добавляет комментарий — удобно, когда ключей несколько. По умолчанию ключи сохраняются в ~/.ssh/:

~/.ssh/id_ed25519       — приватный ключ (никому, никогда)
~/.ssh/id_ed25519.pub   — публичный ключ (копируется на серверы)

Passphrase при генерации — дополнительный уровень защиты. Если кто-то получит файл приватного ключа, без passphrase он бесполезен. Для серверных ключей, используемых в CI/CD, passphrase обычно не ставят — иначе пайплайн не сможет подключиться автоматически.

Ed25519 vs RSA — что выбрать

ПараметрEd25519RSA-4096
Длина ключа256 бит4096 бит
БезопасностьРавнозначнаяРавнозначная
Скорость подписиВ 20–30 раз быстрееМедленнее
Размер подписи64 байта512 байт
ПоддержкаOpenSSH 6.5+ (2014)Везде

Ed25519 предпочтительнее: короче, быстрее, не подвержен атакам на слабые параметры (в отличие от DSA и ECDSA с NIST-кривыми). RSA-4096 нужен только если сервер старше 2014 года или используется устаревшее ПО, не поддерживающее Ed25519.

Помню, в одном из проектов столкнулся с тем, что legacy-сервер на CentOS 6 не принимал ed25519 — пришлось генерировать отдельный RSA-ключ только для него:

ssh-keygen -t rsa -b 4096 -C "legacy-server" -f ~/.ssh/id_rsa_legacy

Копирование ключа на сервер

ssh-copy-id — стандартный способ добавить публичный ключ на удалённый сервер:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deployer@YOUR_SERVER_IP

Команда добавляет содержимое .pub-файла в ~/.ssh/authorized_keys на сервере. Если ssh-copy-id недоступен (Windows без WSL), то вручную:

# С локальной машины
cat ~/.ssh/id_ed25519.pub | ssh deployer@YOUR_SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

После копирования проверить вход по ключу в новом терминале, не закрывая текущую сессию:

ssh deployer@YOUR_SERVER_IP

Если вход прошёл без запроса пароля (или с запросом passphrase от ключа) — ключ работает.

Права на файлы — частая причина «ключ не работает»

OpenSSH отказывается использовать ключи, если права на файлы слишком широкие. Это защита от чтения ключей другими пользователями системы. Правильные значения:

# На локальной машине
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 644 ~/.ssh/config

# На сервере
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Если после ssh-copy-id подключение всё равно просит пароль — в 80% случаев проблема именно в правах. Проверить на сервере:

ls -la ~/.ssh/

Владелец всех файлов в ~/.ssh/ должен совпадать с пользователем, под которым логинитесь. Если файлы принадлежат root, а заходите как deployer — SSH откажет молча.

Отключение парольной аутентификации

После того как ключ работает и проверен, парольный вход нужно отключить — иначе ключи не защищают от брутфорса:

sudo vim /etc/ssh/sshd_config

Три директивы:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

sudo sshd -t           # проверить конфиг на ошибки
sudo systemctl restart sshd

sshd -t — аналог nginx -t, проверяет синтаксис конфига до перезапуска. Кстати, мало кто обращает внимание на эту команду, а она спасает от блокировки собственного доступа к серверу.

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

~/.ssh/config — управление подключениями

SSH-конфиг на локальной машине позволяет заменить длинные команды на короткие алиасы. Вместо:

ssh -i ~/.ssh/id_ed25519 -p 2222 deployer@185.120.33.47

Достаточно:

ssh myproject

Файл ~/.ssh/config:

Host myproject
    HostName 185.120.33.47
    User deployer
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Host staging
    HostName 185.120.33.48
    User deployer
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Host legacy
    HostName 10.0.0.5
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    # Старый сервер — не поддерживает ed25519

Конфиг работает не только для ssh — его подхватывают scp, rsync, git, ssh-copy-id и другие инструменты, использующие OpenSSH.

Wildcard-правила

Общие параметры для всех серверов:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    AddKeysToAgent yes

ServerAliveInterval 60 отправляет keepalive-пакет каждые 60 секунд — спасает от обрыва SSH-сессии при неактивности. На практике это выглядит проще, чем кажется: добавил три строки один раз — забыл про «Connection reset by peer».

SSH-agent — не вводить passphrase каждый раз

SSH-agent хранит расшифрованные ключи в памяти на время сессии. Без него каждое подключение запрашивает passphrase:

# Запустить agent (обычно запускается автоматически)
eval "$(ssh-agent -s)"

# Добавить ключ
ssh-add ~/.ssh/id_ed25519

На Ubuntu с графическим окружением ssh-agent обычно работает через GNOME Keyring и запускается автоматически. На чистом сервере — добавить в ~/.bashrc:

if [ -z "$SSH_AUTH_SOCK" ]; then
    eval "$(ssh-agent -s)" > /dev/null
    ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi

Agent Forwarding — ключи через промежуточный сервер

Если с рабочего сервера нужно подключиться к другому (например, pull из приватного Git-репозитория) — agent forwarding пробрасывает ключи с локальной машины:

ssh -A deployer@server1
# На server1 теперь доступны ключи с вашей машины
git clone git@github.com:yourorg/private-repo.git

В ~/.ssh/config:

Host server1
    HostName 185.120.33.47
    User deployer
    ForwardAgent yes

Agent forwarding безопасен, пока вы доверяете серверу. Если сервер скомпрометирован — злоумышленник может использовать проброшенный ключ для подключения к другим серверам, пока ваша сессия активна. Не включайте forwarding для серверов, которым не доверяете полностью.

fail2ban — защита от брутфорса

fail2ban анализирует логи и блокирует IP-адреса после серии неудачных попыток входа. Даже с отключённой парольной аутентификацией fail2ban полезен: он снижает нагрузку от ботов и уменьшает шум в логах.

sudo apt install -y fail2ban

Создать локальный конфиг (не редактировать jail.conf — он перезаписывается при обновлении):

sudo vim /etc/fail2ban/jail.local

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
port    = ssh
filter  = sshd
logpath = /var/log/auth.log

Настройки: 5 неудачных попыток за 10 минут → бан на 1 час. Для production-серверов стоит иметь в виду один нюанс: можно увеличить bantime до 86400 (24 часа) и снизить maxretry до 3.

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Проверить статус
sudo fail2ban-client status sshd

Вывод покажет количество текущих банов и список заблокированных IP. На свежем VPS через пару часов уже будут первые записи — боты сканируют SSH-порты постоянно.

Смена стандартного порта SSH

Смена порта 22 на нестандартный не является защитой от целенаправленной атаки (nmap просканирует все порты за минуты), но отсекает 95% автоматических ботов, которые стучатся только на 22:

sudo vim /etc/ssh/sshd_config

Port 2222

sudo sshd -t
sudo systemctl restart sshd

До перезапуска — открыть новый порт в firewall:

sudo ufw allow 2222/tcp comment 'SSH custom'
sudo ufw delete allow 22/tcp

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

Обновить ~/.ssh/config на локальной машине:

Host myproject
    HostName 185.120.33.47
    Port 2222
    ...

FAQ

Какой алгоритм SSH-ключа выбрать в 2026 году?

Ed25519 — для всех новых серверов. Ключ в 20–30 раз быстрее RSA с эквивалентной криптостойкостью, занимает 68 символов вместо 700+. RSA-4096 — только для legacy-систем, не поддерживающих Ed25519 (OpenSSH < 6.5).

Можно ли использовать один SSH-ключ для всех серверов?

Технически — да. Практически — не рекомендуется. Если ключ утечёт, компрометируются все серверы. Минимальная гигиена: отдельный ключ для production, отдельный для staging, отдельный для Git. В ~/.ssh/config задаётся, какой ключ для какого хоста.

Забыл passphrase от ключа — как восстановить?

Никак. Passphrase не хранится и не восстанавливается. Единственный вариант — сгенерировать новый ключ (ssh-keygen -t ed25519) и заменить публичный ключ на всех серверах, где использовался старый. Именно поэтому пароль от ключа стоит хранить в менеджере паролей.

fail2ban нужен, если пароли отключены?

Да. Отключённые пароли защищают от взлома, но не от нагрузки. Бот, пытающийся подключиться 10 000 раз в минуту, нагружает sshd и засоряет /var/log/auth.log. fail2ban блокирует IP после первых попыток, снижая шум до нуля.

Как пробросить порт через SSH для доступа к pgAdmin?

Для безопасного доступа к сервисам, которые не должны быть открыты в интернет (pgAdmin, Grafana, RabbitMQ), используйте SSH-туннелирование. Подробный гайд с примерами — в статье про SSH Port Forwarding.

Полезные ссылки