EN Обрати сервер

Початок роботи

Ключі SSH: створити, встановити на сервер і вимкнути вхід за паролем

Оновлено 9 хв читання Read in English

Зміст статті

Для адміністратора, який поки що входить на Linux-сервер за паролем. У підсумку ви входитимете за ключем ed25519, а вхід за паролем по SSH буде вимкнено.

Що знадобиться#

  • Адреса сервера, ім’я користувача і пароль — ці доступи надсилає підтримка. У прикладах використано навчальні значення 203.0.113.10 і admin.
  • Клієнт OpenSSH на вашому комп’ютері. У macOS і Linux він уже є, у Windows 10 (з версії 1809) і Windows 11 — вбудований. Щоб перевірити, відкрийте PowerShell і виконайте ssh -V. Якщо такої команди немає, знайдіть у меню «Пуск» «Додаткові компоненти» (Optional features) і додайте «Клієнт OpenSSH» (OpenSSH Client).
  • Сервер із Debian або Ubuntu. В інших дистрибутивах кроки ті самі, але служба може називатися sshd. Якщо ви працюєте як root, команди можна виконувати без sudo.
  • Відкрита SSH-сесія на сервері, яку ви не закриватимете до останньої перевірки.

Ключ — це пара файлів. Закритий ключ лишається на вашому комп’ютері, його нікому не передають. Відкритий (.pub) можна вільно копіювати: його записують на сервері у файл ~/.ssh/authorized_keys.

Крок 1 Створіть ключ ed25519#

Команда однакова в PowerShell у Windows і в терміналі macOS та Linux. Виконуйте її на своєму комп’ютері, а не на сервері:

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

Параметр -C задає коментар, за яким ви впізнаєте ключ на сервері: вкажіть, чий він. Тип ключа вказуйте явно: OpenSSH до версії 9.5, який ще трапляється у Windows 10 і старіших випусках Linux, типово створює ключ RSA.

На запитання про файл натисніть Enter: ключ збережеться в ~/.ssh/id_ed25519 (у Windows — %USERPROFILE%\.ssh\id_ed25519). Якщо такий файл уже є, не перезаписуйте його — задайте інше ім’я параметром -f. Поруч з’явиться id_ed25519.pub — відкритий ключ: один рядок, що починається з ssh-ed25519.

Windows PowerShell може не розгорнути символ ~ у параметрах команд: якщо файл не знайдено, пишіть $env:USERPROFILE\.ssh\ замість ~/.ssh/.

Крок 2 Парольна фраза і ssh-agent#

На запит Enter passphrase введіть парольну фразу, не лишайте її порожньою. Вона шифрує закритий ключ на диску: якщо ноутбук вкрадуть або файл скопіюють, без фрази ключем не скористаються. Змінити фразу можна командою ssh-keygen -p -f ~/.ssh/id_ed25519.

Щоб не вводити фразу під час кожного підключення, додайте ключ до ssh-agent: він тримає розшифрований ключ у пам’яті.

Linux#

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

macOS#

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Фраза збережеться у В’язці (Keychain) macOS.

Windows#

Службу ssh-agent у Windows типово вимкнено. Один раз увімкніть її в PowerShell, запущеному від імені адміністратора:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Потім у звичайному вікні PowerShell:

ssh-add $env:USERPROFILE\.ssh\id_ed25519

Які ключі є в агенті, показує ssh-add -l.

Крок 3 Перенесіть відкритий ключ на сервер#

У macOS і Linux це робить ssh-copy-id: створює на сервері каталог ~/.ssh і файл authorized_keys, якщо їх ще немає, і дописує туди ключ.

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@203.0.113.10

У Windows цієї утиліти немає, тому зробіть те саме вручну з PowerShell:

$key = Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub"
ssh admin@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '$key' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

В обох випадках сервер востаннє запитає пароль.

Права на каталог і файл#

Сервер ігнорує authorized_keys, якщо цей файл, каталог ~/.ssh або домашній каталог доступні для запису іншим користувачам чи належать не вам (параметр StrictModes, типово ввімкнений). Виправте й перевірте права на сервері:

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

В усіх трьох рядках власником має бути ваш користувач. Якщо каталог створено через sudo і він належить root, виправте: sudo chown -R admin:admin /home/admin/.ssh.

Крок 4 Опишіть сервер у ~/.ssh/config#

Щоб не запам’ятовувати адреси й імена, створіть на своєму комп’ютері файл ~/.ssh/config (у Windows — %USERPROFILE%\.ssh\config, без розширення .txt):

Host srv-pl
    HostName 203.0.113.10
    User admin
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Тепер досить набрати ssh srv-pl. Рядок IdentitiesOnly yes змушує клієнт пропонувати серверу лише вказаний ключ — це важливо, коли ключів кілька. У macOS додайте в кінець файлу блок Host * з рядками AddKeysToAgent yes і UseKeychain yes, щоб фраза бралася з В’язки. У Linux і Windows параметра UseKeychain немає — там цей рядок не додавайте.

Крок 5 Перевірте вхід за ключем у новій сесії#

Не закривайте поточну сесію. Відкрийте нове вікно термінала й підключіться так, щоб клієнт не міг перейти на пароль:

ssh -o PreferredAuthentications=publickey srv-pl

Якщо ви опинилися на сервері, ключ працює. Запит Enter passphrase for key стосується парольної фрази ключа — так і має бути. А запит admin@203.0.113.10's password: з цим параметром з’явитися не повинен. Відповідь Permission denied означає, що сервер не прийняв ключ: знайдіть причину (розділ «Типові помилки») і не переходьте до наступного кроку.

Крок 6 Вимкніть вхід за паролем#

Увага. Помилка на цьому кроці може залишити вас без доступу до сервера. Спершу переконайтеся, що вхід за ключем на кроці 5 спрацював, і прочитайте порядок відкату наприкінці цього кроку. Не закривайте поточну сесію, доки не пройдете розділ «Як перевірити результат».

  1. Подивіться, де ці параметри вже задано:

    grep -n '^Include' /etc/ssh/sshd_config
sudo grep -rniE 'passwordauthentication|kbdinteractiveauthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

    Перша команда має показати рядок Include /etc/ssh/sshd_config.d/*.conf на початку файлу. Якщо його немає, sshd не читає каталог sshd_config.d: тоді впишіть обидва рядки з пункту 2 на самий початок sshd_config, а для відкату видаліть їх звідти. Друга команда в Ubuntu часто знаходить файл 50-cloud-init.conf з рядком PasswordAuthentication yes: його створює cloud-init під час першого запуску системи. Рядки, що починаються з #, — коментарі.

  2. Створіть власний файл із номером, меншим за 50:

    sudo tee /etc/ssh/sshd_config.d/10-password-off.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF

    Номер важливий. Для кожного параметра sshd бере перше знайдене значення, а файли з sshd_config.d читає за алфавітом і раніше, ніж решту основного файлу. Тому 10-password-off.conf переважить 50-cloud-init.conf, а файл 99-… чи рядок нижче в самому sshd_config — ні. Файл cloud-init не редагуйте: cloud-init може перезаписати його під час повторної ініціалізації системи.

  3. Перевірте синтаксис і підсумкові значення:

    sudo sshd -t
sudo sshd -T | grep -Ei '^(pubkey|password|kbdinteractive)authentication'

    Перша команда в разі успіху нічого не виводить. Друга має показати pubkeyauthentication yes, passwordauthentication no і kbdinteractiveauthentication no. Якщо для пароля досі yes, якийсь файл стоїть за алфавітом раніше за ваш — знайдіть його другою командою з пункту 1.

  4. Перезапустіть службу. У Debian і Ubuntu вона називається ssh:

    sudo systemctl restart ssh

    Відкритих сесій перезапуск не розриває. В Ubuntu, починаючи з 22.10 (тобто і в 24.04 LTS, і в 26.04 LTS), порт слухає systemd через ssh.socket, а sshd запускається з першим підключенням. Для параметрів автентифікації досить restart ssh; ssh.socket перезапускають (після systemctl daemon-reload) лише тоді, коли змінюють порт чи адресу.

Відкат. Якщо нова сесія не відкривається, у старій виконайте:

sudo rm /etc/ssh/sshd_config.d/10-password-off.conf
sudo sshd -t && sudo systemctl restart ssh

Як перевірити результат#

У новому вікні термінала на своєму комп’ютері виконайте по черзі дві команди:

ssh srv-pl
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive admin@203.0.113.10

Перша має впустити вас за ключем; вийдіть командою exit і виконайте другу. Вона має завершитися повідомленням Permission denied (publickey) без запиту пароля. Лише після цього закривайте стару сесію. Пароль облікового запису збережіть: він і далі потрібен для sudo та входу через консоль.

Окремий ключ кожному адміністратору#

  • Кожен адміністратор створює пару на своєму комп’ютері й передає лише файл .pub. Один закритий ключ на всіх — це спільний пароль, який не можна відкликати в однієї людини.
  • Найкраще дати кожному окремий обліковий запис. Якщо запис спільний, кожен ключ — окремий рядок у файлі authorized_keys зі зрозумілим коментарем.
  • Список ключів із відбитками й коментарями показує ssh-keygen -lf ~/.ssh/authorized_keys. Де на сервері є ключі: sudo sh -c 'ls -l /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys'.
  • Щоб відкликати ключ, видаліть його рядок з authorized_keys на кожному сервері й у кожному обліковому записі, де він був. Нові підключення з цим ключем сервер відхиляє одразу, перезапуск не потрібен. Уже відкриті сесії не розриваються — перевірте їх командою who.

Якщо ключ втрачено#

Тримайте на сервері щонайменше два ключі: другого адміністратора або резервний, який зберігається окремо від робочого комп’ютера. Тоді після втрати ноутбука досить увійти з іншим ключем, видалити рядок втраченого й додати новий. Парольна фраза на втраченому ключі дає на це час.

Якщо робочих ключів не лишилося, увійти по SSH не вдасться: вхід за паролем вимкнено. Зверніться до технічної підтримки, вона працює цілодобово: телефон +38 044 206 08 08, пошта info@united.net.ua. Віддалена консоль доступна за запитом через підтримку: у ній ви входите з паролем облікового запису (налаштування sshd на консоль не впливають) і додаєте новий ключ. На серверах лінійки Лайт віддаленої консолі немає: тоді підтримка за запитом перезавантажує сервер у режим відновлення — тимчасову систему з доступом по SSH, у якій ви монтуєте диск і додаєте ключ.

Типові помилки#

Неправильні права або власник
Ключ скопійовано, але сервер усе одно просить пароль або відповідає Permission denied. Команда sudo journalctl -u ssh -n 20 на сервері покаже Authentication refused: bad ownership or modes. Повторіть команди з розділу «Права на каталог і файл».
Ключ не той
Клієнт пропонує інший ключ, або відкритий ключ додано не тому користувачеві (наприклад, root замість admin). Команда ssh -v srv-pl показує, які ключі пропонує клієнт. Порівняйте відбиток ssh-keygen -lf ~/.ssh/id_ed25519.pub на комп’ютері з виводом ssh-keygen -lf ~/.ssh/authorized_keys на сервері. Від повідомлення Too many authentication failures рятує IdentitiesOnly yes.
Сесію закрили до перевірки
Найдорожча помилка: виправити конфігурацію вже немає звідки. Лишається консоль за запитом через підтримку.
Ubuntu досі приймає паролі
Параметр вписано в основний sshd_config або у файл 99-…, і 50-cloud-init.conf спрацьовує раніше. Перевірте вивід sudo sshd -T.

Що далі#