SSH-ключи используют криптографию с открытым ключом. У вас есть два файла: приватный ключ (хранится у вас) и публичный ключ (размещается на сервере). Никакой пароль не передаётся по сети.

Генерация ключей (Linux / Mac)

# Современный алгоритм Ed25519 (рекомендуется)
ssh-keygen -t ed25519 -C "your@email.com"

# Или RSA-4096 для совместимости
ssh-keygen -t rsa -b 4096 -C "your@email.com"

# Ключи сохранятся в ~/.ssh/
# ~/.ssh/id_ed25519      ← приватный (НИКОМУ не передавать)
# ~/.ssh/id_ed25519.pub  ← публичный (можно размещать везде)

Добавление ключа на сервер

# Автоматически (самый простой способ)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ip

# Или вручную:
cat ~/.ssh/id_ed25519.pub | ssh user@server-ip   "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Генерация ключей в Windows (PuTTYgen)

Скачайте PuTTYgen с официального сайта PuTTY
Выберите EdDSA или RSA (4096 бит)
Нажмите Generate и двигайте мышью
Сохраните приватный ключ (Save private key)
Скопируйте публичный ключ из текстового поля вверху
Добавьте его в ~/.ssh/authorized_keys на сервере

Отключение входа по паролю

⚠️ Выполняйте только убедившись, что вход по ключу работает! Иначе потеряете доступ к серверу.

sudo nano /etc/ssh/sshd_config

# Изменить или добавить:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

sudo systemctl restart sshd

✅ После настройки SSH-ключей атаки перебором паролей становятся бессмысленными — сервер просто не примет пароль.

Разбор типичных ошибок SSH

Большинство проблем с ключами укладываются в пять ошибок. Смотрите на точный текст — он подсказывает, в какую сторону копать.

Permission denied (publickey) — сервер принял соединение, но ни один из предложенных ключей не подошёл. Причины: не тот файл ключа, ключ не добавлен в authorized_keys нужного пользователя, либо в ssh-agent просто не тот ключ.
Too many authentication failures — клиент перебрал больше ключей, чем разрешает MaxAuthTries на сервере, ещё до того как дошёл до нужного. Укажите ключ явно: ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@server-ip.
WARNING: UNPROTECTED PRIVATE KEY FILE! — права на файл приватного ключа шире 600, и ssh отказывается его читать. Исправляется командой chmod 600 ~/.ssh/id_ed25519.
Agent admitted failure to sign using the key — ключ числится в ssh-agent, но сам файл на диске удалён, переименован или недоступен для чтения.
REMOTE HOST IDENTIFICATION HAS CHANGED — отпечаток сервера в ~/.ssh/known_hosts не совпадает с текущим. Если сервер не переустанавливали и IP не передавали другому клиенту — это повод остановиться и проверить, а не сразу удалять строку из файла.

Ed25519, RSA и ECDSA: какой алгоритм выбрать

Тип ключа задаётся флагом -t при генерации. Разница не только в названии.

Алгоритм	Длина ключа	Скорость операций	Совместимость
Ed25519	256 бит (фиксированная)	Высокая	OpenSSH 6.5+ (начиная с 2014 года)
RSA-4096	4096 бит	Средняя при подписи	Работает везде, включая старые системы и панели
RSA-2048	2048 бит	Высокая	Минимально допустимая длина, использовать только при ограничениях сервера
ECDSA	256-521 бит	Высокая	Поддерживается широко, но криптографы рекомендуют избегать из-за особенностей NIST-кривых

Для новых серверов и своих рабочих машин используйте Ed25519 — короче, быстрее, устойчивее к ошибкам генерации случайности. RSA-4096 оставляйте для legacy-оборудования, которое не понимает Ed25519.

Когда SSH-ключи не подходят

Ключи — не универсальное решение на все случаи.

Общий сервисный аккаунт без файловой системы для ~/.ssh, доступ к которому идёт только через веб-панель — там держатся на пароле или токене панели, а не на SSH-ключе.
Разовый доступ подрядчику на 10-15 минут — проще выдать временный пароль и сразу сменить его после работы, чем заводить ключ и потом гарантированно вычищать его из authorized_keys.
Устройство без защищённого хранения приватного ключа, например общий терминал в коворкинге — ключ, оставленный там, компрометирует все серверы, куда он был добавлен.
Парк из десятков серверов без bastion-хоста или центрального управления ключами — при увольнении сотрудника придётся вручную чистить authorized_keys на каждой машине, и один сервер забудут почти наверняка.

Проверка, что вход по паролю действительно отключён

Файл sshd_config может содержать директиву, которую переопределяет другой файл в Include, поэтому проверяйте не текст файла, а то, что реально применил демон.

# Показывает действующую конфигурацию sshd, а не содержимое файла
sudo sshd -T | grep -i passwordauthentication

# Явно запросить парольную аутентификацию — сервер обязан отказать
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password user@server-ip

# Убедиться, что последний вход прошёл именно по ключу
sudo grep "Accepted" /var/log/auth.log | tail -5

Если первая команда вывела passwordauthentication no, вторая команда завершилась ошибкой доступа, а в журнале видна строка Accepted publickey — вход по паролю отключён на самом деле, а не только в файле конфигурации.