SSH-ключи Ubuntu: настраиваем вход без пароля и закрываем сервер

Заходить на сервер по SSH без пароля и при этом безопаснее, чем с паролем — главная польза от ключей. Разбираем ssh-keygen ed25519, ssh-copy-id, отключение парольного входа в sshd_config, смену SSH-порта, настройку ~/.ssh/config на клиенте и генерацию ключей из Windows. Всё на Ubuntu 24.04 LTS.

Зачем SSH-ключи вместо пароля

Ключевая пара — это два файла: приватный ключ живёт у вас (никогда не покидает компьютер) и публичный ключ, который вы кладёте на сервер. При подключении сервер шлёт случайный челлендж, ваш клиент подписывает его приватным ключом, сервер проверяет подпись по публичному. Пароль никуда не передаётся — даже если канал перехватят, утечь нечему.

Что вы получаете:

• Безопасность. Ключ ed25519 — это 256-битный секрет, его не подобрать брутфорсом. Пароль из 12 символов — нет, он подбирается за дни на современном железе.
• Удобство. Один раз настроили — дальше ssh user@host без ввода пароля.
• Защита от логов. Парольная попытка попадает в auth.log, и любой fail2ban будет блокировать кого попало; с ключами просто нет атаки на пароль.
• Ротация. Можно завести ключ на каждое устройство (ноутбук, рабочая станция, CI) и удалять их независимо. Скомпрометировали ноут — стёрли его публичный ключ из authorized_keys сервера.

Сразу важно: passphrase на приватный ключ — это не пароль на сервер. Это второй фактор «что-то знаю + что-то имею»: даже если ноут украли, без passphrase ключ бесполезен. Passphrase спрашивается только на разблокировку ключа в ssh-agent (один раз за сессию), не на каждое подключение.

Генерируем ключ

Стандарт 2026 года — ed25519. Он короче, быстрее и не имеет известных слабостей в отличие от RSA-1024/2048.

ssh-keygen -t ed25519 -C "youremail@example.com"

Что произойдёт:

1. Спросит путь — оставьте дефолт ~/.ssh/id_ed25519.
2. Спросит passphrase — введите длинную фразу. Это второй фактор; пустая passphrase допустима только для CI-машин и одноразовых скриптов.
3. Создаст два файла: ~/.ssh/id_ed25519 (приватный, права 600) и ~/.ssh/id_ed25519.pub (публичный, можно показывать).

Флаг -C — это комментарий, добавляется в конец публичного ключа. Удобно идентифицировать ключ в authorized_keys: чей это, на каком устройстве. Часто пишут user@hostname-2026-05.

Если вы вынуждены работать с системой, которая ed25519 не понимает (очень старый сервер OpenSSH < 6.5), используйте RSA с длиной ≥ 4096:

ssh-keygen -t rsa -b 4096 -C "youremail@example.com"

Но 4096-битный RSA медленнее ed25519 на порядок и без необходимости его уже не делают.

Раскладываем ключ на сервер

Самый простой путь — ssh-copy-id, он есть в openssh-client по умолчанию:

ssh-copy-id user@server.example.com

Команда:

1. Спросит пароль user-а на сервере (это последний раз, когда он вам понадобится).
2. Создаст на сервере ~/.ssh/ с правами 700, если её нет.
3. Допишет ваш публичный ключ в ~/.ssh/authorized_keys (права 600).
4. Не дублирует, если такой ключ там уже есть.

Если ssh-copy-id нет (например, заходите с Windows старой версии) — раскладываем вручную:

cat ~/.ssh/id_ed25519.pub | ssh user@server.example.com \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && \
   chmod 600 ~/.ssh/authorized_keys"

Права важны: SSH-демон откажется работать, если ~/.ssh доступен другим (777) или authorized_keys шире 600. Сообщение в логе будет «Authentication refused: bad ownership or modes for directory».

После этого ssh user@server.example.com подпустит без пароля. Если просит passphrase — это нормально, это разблокировка приватного ключа на клиенте. Дальше — ssh-agent.

Перестаём вводить passphrase каждый раз

ssh-agent держит расшифрованный ключ в памяти, чтобы не вводить passphrase при каждом подключении. На современном Ubuntu и macOS он запускается автоматически, нужно только добавить ключ:

ssh-add ~/.ssh/id_ed25519
ssh-add -l           # список ключей в агенте
ssh-add -D           # выгрузить все ключи

Если хотите, чтобы ключи добавлялись автоматически при логине, в ~/.bashrc (или .zshrc) можно добавить:

[ -z "$SSH_AUTH_SOCK" ] && eval "$(ssh-agent -s)" > /dev/null
ssh-add -l > /dev/null 2>&1 || ssh-add ~/.ssh/id_ed25519

На macOS можно положить ключ в keychain через ssh-add --apple-use-keychain ~/.ssh/id_ed25519 — passphrase спросят один раз и навсегда.

Настраиваем клиент через ~/.ssh/config

Чтобы не печатать каждый раз ssh -p 22022 -i ~/.ssh/id_work_ed25519 deploy@server.example.com, складываем алиасы в ~/.ssh/config:

Host serv
    HostName    server.example.com
    User        deploy
    Port        22022
    IdentityFile ~/.ssh/id_work_ed25519
    IdentitiesOnly yes

Host *.internal.example.com
    User           ops
    ProxyJump      bastion.example.com
    IdentityFile   ~/.ssh/id_work_ed25519

Теперь ssh serv подключится с правильным ключом и портом. IdentitiesOnly yes — критично, если у вас в агенте много ключей: без него SSH сначала пробует все ключи подряд, и сервер с лимитом MaxAuthTries 3 отбрасывает соединение раньше, чем дойдёт до нужного.

ProxyJump — заход через бастион-хост: сначала SSH в bastion, оттуда — в целевой сервер. Удобно для серверов в приватной сети.

Закрываем парольный вход

Самое важное действие после настройки ключей — отключить парольный вход. Иначе все шаги выше — половинчатая защита.

Открываем /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Меняем (или добавляем) строки:

# /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
UsePAM yes

Что они значат:

• PasswordAuthentication no — отключает вход по паролю. Только ключи.
• PermitRootLogin no — root не заходит по SSH вообще. Заходите user-ом, дальше sudo.
• KbdInteractiveAuthentication no — отключает альтернативный «keyboard-interactive» механизм (через PAM это иногда оживляет пароль обратно).
• UsePAM yes — нужно для корректной работы sudo, login-сессий, journald-логов. Менять не надо.

В Ubuntu 24.04 файлы конфигурации SSH разнесены по /etc/ssh/sshd_config.d/*.conf. Часто в основном sshd_config стоит Include /etc/ssh/sshd_config.d/*.conf, а пакет cloud-init может класть туда 60-cloudimg-settings.conf с PasswordAuthentication yes. Проверьте:

sudo grep -ri 'PasswordAuthentication' /etc/ssh/

И после правки обязательно проверьте конфиг и перезапустите демон:

sudo sshd -t                   # проверка синтаксиса
sudo systemctl restart ssh

Перед restart ssh оставьте открытой одну SSH-сессию. Если что-то сломается, у вас будет окно для отката. Из новой сессии проверьте, что заходите по ключу и не заходите по паролю:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@server
# должно сразу отбить "Permission denied (publickey)"

Если всё ок — старую сессию можно закрывать.

Меняем SSH-порт

Смена порта SSH с 22 на нестандартный — спорная практика. Это не безопасность в строгом смысле — атакующий с nmap найдёт ваш порт за пару минут. Но это снижает шум: 99% автоматических ботов сканируют только 22, и в логах остаются только осмысленные попытки.

Открываем sshd_config:

# /etc/ssh/sshd_config
Port 22022

Перед перезапуском SSH обязательно:

1. Откройте новый порт в UFW, иначе после перезапуска заперетесь снаружи:

   sudo ufw allow 22022/tcp comment 'SSH custom port'
   

   Подробно про настройку UFW — гайд по UFW на Ubuntu.

2. Если на хостинге есть внешний firewall (Hetzner Cloud Firewall, AWS Security Group, прочие) — добавьте правило туда тоже.

3. Проверьте что порт реально открылся изнутри — подключение по новому порту до перезагрузки демона:

   sudo ss -tlnp | grep ssh
   sudo systemctl restart ssh
   sudo ss -tlnp | grep ssh        # должен слушать новый порт
   

4. С другого терминала проверьте, что новый порт работает:

   ssh -p 22022 user@server.example.com
   

Только после успешной проверки закрывайте старый порт 22 в UFW: sudo ufw delete allow 22/tcp.

В Ubuntu 24.04 при использовании socket-activation демон может слушать порт не из sshd_config, а из ssh.socket. Проверьте:

sudo systemctl cat ssh.socket

Если видите ListenStream=22, отключите socket-активацию:

sudo systemctl disable --now ssh.socket
sudo systemctl enable --now ssh.service

И тогда Port из sshd_config начнёт работать. Это специфика свежих релизов — на 22.04 такого не было.

Альтернатива смене порта — установить fail2ban на стандартном 22-м, он отлично гасит ботов: fail2ban на Ubuntu. Эти меры дополняют друг друга, выбирайте по вкусу.

Генерируем ключ из Windows

В Windows 10/11 встроен OpenSSH — отдельный установщик не нужен. Открываем PowerShell или Windows Terminal:

ssh-keygen -t ed25519 -C "youremail@example.com"

Ключи лягут в C:\Users\<вы>\.ssh\. Дальше как на Linux:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

ssh-copy-id в Windows нет, поэтому раскладывание — через pipe выше или WSL-овский ssh-copy-id.

ssh-agent на Windows запускается через Services. Открыть services.msc, найти OpenSSH Authentication Agent → Properties → Startup type: Automatic → Start. После этого ssh-add и ~/.ssh/config работают так же, как на Linux.

Если вы используете PuTTY — он работает со своим форматом ключей .ppk. Сгенерируйте через PuTTYgen, public-часть скопируйте в ~/.ssh/authorized_keys сервера. Но проще ставить нативный OpenSSH из Windows и не тащить PuTTY — последний остаётся актуальным разве что для serial-консолей.

Частые вопросы

Как создать SSH-ключ на Ubuntu

Запустите ssh-keygen -t ed25519 -C "ваш-email", оставьте дефолтный путь (~/.ssh/id_ed25519) и придумайте passphrase. Это создаст пару ключей: приватный (хранится у вас) и публичный (.pub, который копируется на сервер). Дальше — ssh-copy-id user@server для раскладки публичного ключа.

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

ed25519. Он короче, быстрее и устойчив к известным атакам. RSA нужен только для совместимости с очень старыми системами (OpenSSH < 6.5) — в этом случае берите длину 4096 бит. ECDSA исторически предлагался как альтернатива RSA, но из-за подозрений к NIST-кривым массово вытеснен ed25519.

Как зайти по SSH без пароля

Создайте ключ через ssh-keygen -t ed25519, разложите публичный ключ на сервер через ssh-copy-id user@server. После этого ssh user@server подпустит без пароля. Если passphrase спрашивается каждый раз — добавьте ключ в ssh-agent через ssh-add ~/.ssh/id_ed25519.

Как отключить вход по паролю на SSH-сервере

В файле /etc/ssh/sshd_config (и в /etc/ssh/sshd_config.d/*.conf) поставьте PasswordAuthentication no и KbdInteractiveAuthentication no. Затем sudo sshd -t для проверки и sudo systemctl restart ssh. Перед перезапуском убедитесь, что заходите по ключу — иначе запретесь снаружи.

Как сменить SSH-порт на Ubuntu

В /etc/ssh/sshd_config поменяйте Port 22 на новый, например Port 22022. Перед systemctl restart ssh откройте новый порт в UFW: sudo ufw allow 22022/tcp. На Ubuntu 24.04 ещё нужно выключить socket-activation: sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service. После проверки нового порта — закройте старый в UFW.

Где хранится SSH-ключ на Ubuntu

В ~/.ssh/. Приватный ключ — id_ed25519 (или id_rsa), публичный — id_ed25519.pub. Права: ~/.ssh должна быть 700, приватный ключ — 600. Серверная сторона хранит публичные ключи клиентов в ~/.ssh/authorized_keys (тоже 600).

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

Технически можно, но плохая практика. Лучше — один ключ на устройство (ноут, рабочая станция, CI). Тогда при компрометации ноутбука вы удаляете только его строку из authorized_keys сервера, остальные продолжают работать. И в логах сервера сразу видно, с какого устройства был заход (через комментарий ключа).

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

Если passphrase была — некоторое окно для смены ключа есть, файл бесполезен без неё. Если без passphrase — считайте сервер скомпрометирован: тот, кто получил доступ к ключу, может зайти. Действия: зайти на сервер альтернативным способом (консоль провайдера, второй ключ), удалить старый публичный ключ из authorized_keys, добавить новый.

Что запомнить

• Берите ed25519, а не RSA. Это стандарт 2026 года: короче, быстрее, безопаснее.
• Passphrase на приватный ключ — это второй фактор «что-то знаю + что-то имею». Не делайте пустой на ноутбуке.
• После раскладки ключей обязательно отключите PasswordAuthentication в sshd_config. Иначе ключи — это удобство без безопасности.
• В sshd_config.d/*.conf пакеты Ubuntu могут перезаписывать ваши настройки. Всегда проверяйте grep -ri 'PasswordAuthentication' /etc/ssh/.
• Перед перезапуском SSH-демона держите запасную сессию открытой и через неё проверяйте новые правила. После — sudo sshd -t для синтаксиса.
• Смена порта — про шум в логах, не про безопасность. Дополняется fail2ban-ом, не заменяет ключи.
• На Ubuntu 24.04 при смене порта нужно выключить ssh.socket и включить ssh.service — иначе порт из sshd_config игнорируется.
• На клиенте используйте ~/.ssh/config с алиасами и IdentitiesOnly yes. Это спасает от лимита MaxAuthTries.