Перейти к содержимому

Авторизация на сервере по ключам SSH

Обновлено: 28.06.2026

Переосмысление подключения к серверу: отказ от FTP и парольной аутентификации в пользу SSH-ключей

авторизация по ключам
Достаточно ненадолго оставить сервер со включенной авторизацией по паролю как он сразу начинает привлекать нездоровое внимание ботов-взломщиков и хакеров. На сервере фиксируются автоматические попытки входа. Новый сервер еще ничего не хранит, но его уже проверяют: вдруг пароль простой, вдруг root открыт, вдруг администратор оставил вход как есть.
попытки подбора пароля
На скриншоте наглядная иллюстрация положения дел с одним из недавно созданных серверов.
Достаточно создать новый сервер, и уже через минуту, а иногда и раньше, начинаются попытки подбора. Поэтому RISH сознательно ведет пользователя к другой схеме: сервер должен принимать вход по SSH-ключам, а не ждать попыток подбора пароля из интернета.
Почему парольный вход лучше отключить на сервере
Пароль надо вводить, хранить, передавать в момент входа и защищать от утечек. Его можно подсмотреть, подобрать, случайно отправить не туда или сохранить в небезопасном месте. SSH-ключи решают эту задачу иначе: сервер проверяет не знание пароля, а наличие у вас нужного приватного ключа.
Главное правило простое: приватный ключ остается у вас на компьютере и никому не передается. Публичный ключ можно положить на сервер. Если публичный ключ есть на сервере, а приватный ключ есть у вас, SSH сможет впустить вас без пароля.

Что куда положить

У авторизации по ключам есть две стороны: ваш компьютер и сервер. Приватный ключ остается на вашем компьютере. На сервер копируется только публичный ключ.
Схема расположения SSH-ключей на компьютере и сервере

На вашем компьютере

  • ~/.ssh/rish_ed25519 - приватный ключ. Его нельзя отправлять в чат, вставлять на сайт или передавать другому человеку.
  • ~/.ssh/rish_ed25519.pub - публичный ключ. Его можно копировать на сервер.
  • ~/.ssh/config - локальный файл с удобными короткими именами серверов.

На сервере

  • /root/.ssh/authorized_keys - список публичных ключей, которым разрешен вход под root.
  • /home/<user>/.ssh/authorized_keys - список публичных ключей для входа под обычным пользователем.
Практически это выглядит так: публичный ключ кладем на сервер в authorized_keys, приватный ключ оставляем у себя на компьютере, а в локальном ~/.ssh/config записываем, каким ключом и к какому серверу подключаться.

Как создать ключ

На macOS, Linux и современных Windows ключ можно создать командой:
ssh-keygen -t ed25519 -C "ivan-macbook" -f ~/.ssh/rish_ed25519
На windows перед этим создайте на своем компьютере папку с именем .ssh в папке вашего пользователя (да, именно так, с точкой в самом начале). Иначе команда вам выдаст: Saving key "~/.ssh/rish_ed25519" failed: No such file or directory
Параметр -C добавляет комментарий в конец публичного ключа. Вместо ivan-macbook лучше указать понятный для себя идентификатор: имя человека, устройство или назначение ключа, например ivan-macbook, admin-office или client-site-access. Потом по этому комментарию проще понять, чей ключ лежит в authorized_keys, удалить старый ключ или отозвать доступ человеку, которому он больше не нужен.
После выполнения появятся два файла: ~/.ssh/rish_ed25519 и ~/.ssh/rish_ed25519.pub. Первый - приватный, второй - публичный. На сервер добавляют содержимое файла с расширением .pub.
Во время создания ключа ssh-keygen спросит passphrase. Можно просто нажать Enter и оставить ключ без дополнительного пароля. Можно задать пароль на сам ключ, но тогда его нужно будет помнить и вводить при использовании ключа.
Посмотреть публичный ключ можно так:
cat ~/.ssh/rish_ed25519.pub
Копируйте строку целиком: она начинается с ssh-ed25519, дальше идет длинная часть ключа, а в конце обычно комментарий, например ivan-macbook.

Как создать ключ через PuTTY

Вообще я не рекомендую использовать Putty как для подключения к серверу, так и для генерирования ключей – он просто не нужен, а еще хранит ключи в своем внутреннем формате из-за чего происходит вечная путаница. Но существует просто невероятное количество руководств в интернете, которые советуют Putty как "удобную" и "простую" программу для подключения к серверу.

Конечно что же она такой не является. Интерфейс очень странный и далек от интуитивно понятного, настройки хранит в реестре и плохо подходит для переноса между компьютерами.

Но уж что есть, то есть. Кто я такой, чтобы отговаривать вас от привычного инструмента?

Вместо Putty лучше использовать родной терминал Windows или на других компьютерах те терминалы, которые вам больше нравятся (на MacOS могу посоветовать iTerm2).

Если у вас putty еще не скачан, то вот официальный адрес для скачивания (да, я знаю что они могли бы и получше подобрать домен, но уж что есть то есть):

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

Скачайте подходящий для вашей архитектуры вариант.

После скачивания на вашем компьютере должны появиться несколько программ, включая сам PuTTY и PuTTYgen. Для манипулирования ключами (создание и преобразование из одного формата в другой) вам понадобится именно PuTTYgen.

Запустите ее.

Вначале обязательно выберите тип ключа внизу – EdDSA. Будет выбран параметр Ed25519 – именно он вам и нужен.

После этого можно начать создание ключа с помощью кнопки Generate. От вас потребуется случайным образом дергать мышкой в этом окне, чтобы при создании ключа использовались реальные случайные числа.

Через некоторое время ключ будет готов. Публичный ключ будет сразу показан и его можно выделить и скопировать в буфер обмена. На скриншоте как раз выделен ключ для копирования. Это публичный ключ, который предназначен для копирования на удаленный компьютер или сервер.
После этого можно будет записать ключ на диск. Поскольку родной формат PuTTY отличается от общепринятого OpenSSH, придется выбирать Export OpenSSH key.
При сохранении вам будут угрожать тем, что вы хотите сохранить приватный ключ без пароля. Не ведитесь на эти угрозы (можно сохранить файл без пароля).
Куда сохранять приватный ключ? В папку .ssh которая должна лежать у вас в папке пользователя (да именно так, с точкой в начале).
Приватный ключ выглядит примерно так. Теперь вы можете использовать этот файл для авторизации на сервере.

Как добавить ключ на сервер

Публичный ключ нужно добавить в файл authorized_keys на сервере. Для входа под root это обычно файл /root/.ssh/authorized_keys. Для пользователя сайта - /home/<user>/.ssh/authorized_keys.
На macOS/Linux, если команда доступна и парольный вход еще временно разрешен, можно воспользоваться ssh-copy-id:
ssh-copy-id -i ~/.ssh/rish_ed25519.pub root@SERVER_IP
Добавить ключ на сервер можно обычным копированием текста: откройте файл authorized_keys и вставьте туда публичный ключ. Публичный ключ должен занимать одну строку целиком: от ssh-ed25519 до комментария в конце. Важно не переносить строку ключа посередине и не добавлять лишние символы. Каждый ключ в authorized_keys пишется с новой строки. После последнего ключа тоже лучше нажать Enter, чтобы файл заканчивался переводом строки. Тогда, если позже кто-то добавит следующий ключ, он начнется с новой строки, а не приклеится к вашему ключу и не сломает обе записи.
На сервере удобнее редактировать файл authorized_keys через Midnight Commander. Подключитесь к серверу, запустите mc, найдите нужный файл в папке /root/.ssh и нажмите F4 для редактирования.
Вставьте публичный ключ отдельной строкой, нажмите Enter в конце файла, сохраните изменения через F2 и выйдите из редактора.
Как работать с Midnight Commander
После добавления ключа не закрывайте старое рабочее окно с сервером. Сначала откройте новое окно терминала и проверьте, что вход по ключу работает. Только после этого можно спокойно отключать парольный вход.

Как подключаться

Без файла config подключение выглядит так:
ssh -i ~/.ssh/rish_ed25519 root@SERVER_IP
Параметр -i указывает, какой приватный ключ использовать для подключения. В примере SSH берет ключ из файла ~/.ssh/rish_ed25519 и пытается войти на сервер под пользователем root.
Это нормально, но неудобно: нужно помнить IP, пользователя и путь к ключу. Когда серверов становится несколько, такие команды быстро превращаются в рутину.

Файл ~/.ssh/config

Файл ~/.ssh/config нужен, чтобы один раз описать подключение и потом входить короткой командой. Например, вместо длинной команды с IP и ключом вы пишете просто:
ssh my-rish-server
Пример записи в ~/.ssh/config:
Host my-rish-server
    HostName 203.0.113.10
    User root
    Port 22
    IdentityFile ~/.ssh/rish_ed25519
    IdentitiesOnly yes
  • Host - короткое имя, которое вы придумываете сами.
  • HostName - IP-адрес или домен сервера.
  • User - пользователь, под которым входите.
  • Port - порт SSH, обычно 22.
  • IdentityFile - путь к приватному ключу.
  • IdentitiesOnly yes - заставляет SSH использовать указанный ключ и не перебирать лишние ключи из агента.
После этого та же запись работает не только для ssh, но и для scp и sftp:
ssh my-rish-server
sftp my-rish-server
scp ./file.txt my-rish-server:/root/

RishTools делает это проще

Для тех, кто не хочет каждый раз вспоминать команды, пути и формат файла config, в сообществе RISH появились утилиты RishMacOSTools и RishWinTools. Они помогают создавать SSH-ключи и вести файл ~/.ssh/config без ручного редактирования каждой строки.
Идея простая: вы добавляете сервер в программе, указываете понятное имя, адрес, пользователя и ключ, а программа формирует нужную запись для подключения. После этого сервером удобнее пользоваться из терминала и других инструментов, которые умеют работать с SSH.
RishTools - это не обязательная часть RISH, а удобный помощник для ежедневной работы с ключами и SSH-config.
Открыть страницу RishTools

Почему мы используем SFTP вместо FTP

Классический FTP не подходит для современной работы с сервером. В классическом FTP логин, пароль и данные могут передаваться без шифрования, поэтому его нельзя считать безопасным способом работы с сервером. Поэтому RISH не строит рабочий процесс вокруг FTP.
Вместо него используйте SFTP. Несмотря на похожее название, это не "улучшенный FTP", а передача файлов поверх SSH. То есть используется тот же защищенный вход, те же пользователи и те же ключи.
Если SSH-подключение по ключу уже настроено, то SFTP обычно не требует отдельной парольной схемы. Вы подключаетесь к серверу по SFTP, выбираете нужного пользователя и используете тот же приватный ключ.
Коротко: FTP лучше не использовать. Для файлов на сервере используйте SFTP, потому что он работает через SSH и нормально сочетается с авторизацией по ключам.

Если не подключается

  • Проверьте, что на сервер добавлен именно публичный ключ, файл с расширением .pub.
  • Проверьте, что приватный ключ остался на вашем компьютере и путь к нему правильно указан в IdentityFile.
  • Проверьте пользователя: ключ для root не дает автоматический вход под другим пользователем.
  • Проверьте права: каталог .ssh обычно должен иметь режим 700, файл authorized_keys - 600.
  • Проверьте, что домашний каталог пользователя не доступен на запись посторонним пользователям.
  • Запустите подключение с подробным выводом: ssh -v my-rish-server. По выводу часто видно, какой ключ SSH пытается использовать.
Подробный разбор типичных ошибок входа, сообщений SSH и проблем с правами есть в отдельной статье:
У вас проблемы со входом?
Если сомневаетесь, оставьте текущее рабочее SSH-окно открытым и проверяйте новый вход в отдельном окне. Так вы не потеряете доступ к серверу из-за одной неправильной строки.
Телеграм чат RISH