Как да добавите SSH ключове към нов или съществуващ VPS

SSH ключовете са криптографски двойки ключове — публичен ключ, съхраняван на сървъра, и частен ключ, пазен на вашата локална машина — които удостоверяват вашата самоличност, без да предават парола по мрежата. При свързване сървърът издава криптографско предизвикателство, което само вашият частен ключ може да реши, предоставяйки достъп, ако отговорът е валиден. Този механизъм прави SSH удостоверяването с ключ принципно по-устойчиво на атаки с груба сила, пълнене с идентификационни данни и прихващане тип „човек по средата” в сравнение с всяка схема, базирана на пароли.

Това ръководство обхваща целия процес на генериране, внедряване и укрепване на SSH удостоверяването с ключ на нови и съществуващи VPS инстанции — включително гранични случаи, проблеми с разрешенията и управление на множество ключове, които повечето уроци напълно пропускат.

Защо SSH ключовете са архитектурно превъзходни над паролите

Удостоверяването с парола изпраща тайна (или нейния хеш) по мрежата и разчита на сървъра да съхранява проверимо удостоверение. SSH удостоверяването с публичен ключ никога не излага частния ключ — нито по време на генериране, нито по време на влизане, никога. Частният ключ никога не напуска вашата локална машина.

Освен чистата сигурност, SSH ключовете отключват оперативни възможности, които паролите не могат да осигурят:

• Автоматизация без надзор — CI/CD конвейери, Ansible наръчници и задачи rsync, управлявани от cron, изискват неинтерактивно удостоверяване. Паролите напълно нарушават това.
• Детайлен контрол на достъпа — Всеки запис authorized_keys може да носи ограничения command=, from= и no-pty, ограничавайки точно какво е позволено да прави даден ключ.
• Проследяемост — Отделните ключове могат да бъдат отменени, без да се сменя споделена парола и да се нарушава работата на всеки друг потребител или скрипт.
• Устойчивост на фишинг — Няма парола, която да бъде открадната чрез фалшива страница за влизане.

Предварителни изисквания

Преди да продължите, потвърдете следното:

• Имате работещ VPS или сте в процес на осигуряване на такъв.
• Вашата локална машина работи с Linux, macOS или Windows с инсталиран OpenSSH (Windows 10/11 включва OpenSSH по подразбиране; проверете с ssh -V).
• Имате root или sudo достъп до целевия сървър.
• Разбирате, че загубата на вашия частен ключ без алтернативен метод за влизане (конзолен достъп, ключ за възстановяване) може да ви заключи завинаги.

Избор на правилния алгоритъм за ключ

Оригиналната команда ssh-keygen -t rsa -b 4096 е надеждна, но не е единствената опция. Разбирането на компромисите ви помага да направите правилния избор за вашата среда.

Ed25519 е препоръчителният алгоритъм за всеки сървър, работещ с OpenSSH 6.5 или по-нова версия (издадена през 2014 г.). Използвайте RSA 4096 само при свързване към наследени системи, които не поддържат ключове с елиптична крива.

Част 1: Добавяне на SSH ключове към нов VPS

Много панели за управление на хостинг ви позволяват да инжектирате публичен ключ по време на осигуряването, преди инстанцията изобщо да се стартира. Това е най-чистият подход — ключът е вграден в образа и е възможно удостоверяването с парола никога да не се налага да бъде активирано.

Стъпка 1: Генерирайте вашата двойка SSH ключове

Отворете терминал на вашата локална машина. Генерирайте двойка Ed25519 ключове:

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

Ако имате нужда от RSA по причини за съвместимост:

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

Когато бъдете подканени за местоположение на файл, натиснете Enter, за да приемете стойността по подразбиране (~/.ssh/id_ed25519 или ~/.ssh/id_rsa). Когато бъдете подканени за парафраза, задайте такава — тя криптира частния ключ на диска, така че дори ако лаптопът ви бъде откраднат, ключът е безполезен без парафразата. Вашият SSH агент (ssh-agent) ще кешира декриптирания ключ в паметта, така че ще въвеждате парафразата само веднъж на сесия.

Проверете генерираните файлове:

ls -la ~/.ssh/

Ще видите:

• id_ed25519 — вашият частен ключ (разрешенията трябва да бъдат 600; никога не споделяйте този файл)
• id_ed25519.pub — вашият публичен ключ (безопасен за копиране навсякъде)

Покажете публичния ключ, за да го копирате:

cat ~/.ssh/id_ed25519.pub

Изходът изглежда така:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

Копирайте целия този низ — ще го поставите в панела за хостинг.

Стъпка 2: Добавете публичния ключ по време на осигуряването на VPS

Влезте в панела за управление на хостинга. По време на работния процес за създаване на VPS:

1. Изберете вашата операционна система (Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9 и др.).
2. Намерете секцията SSH ключ или Удостоверяване.
3. Поставете пълното съдържание на id_ed25519.pub в предоставеното поле.
4. Завършете останалата конфигурация (план, регион, хостово име).

След като VPS се стартира, системата за осигуряване записва вашия публичен ключ в /root/.ssh/authorized_keys автоматично. Не се изисква влизане с парола.

Стъпка 3: Свържете се с новоосигурения VPS

ssh root@your_vps_ip

Ако сте използвали нестандартно име на файл за ключ, посочете го изрично:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Успешна връзка без подкана за парола потвърждава, че ключът е инжектиран правилно. Ако сте задали парафраза, вашият SSH агент или подкана за парафраза ще се справи с нея локално.

Част 2: Добавяне на SSH ключове към съществуващ VPS

Ако вашият VPS вече работи с удостоверяване с парола, трябва ръчно да внедрите публичния ключ. Това е двуфазен процес: копирайте ключа, след което по желание укрепете SSH демона.

Стъпка 1: Генерирайте двойка ключове (ако нямате такава)

Следвайте същия процес като Стъпка 1 в Част 1 по-горе. Ако вече имате двойка ключове, извлечете вашия публичен ключ:

cat ~/.ssh/id_ed25519.pub

Стъпка 2: Копирайте публичния ключ на сървъра

Метод А — ssh-copy-id (Препоръчителен)

Помощната програма ssh-copy-id обработва автоматично създаването на директории, добавянето към файлове и задаването на разрешения:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip

Въведете паролата си при подкана. Инструментът добавя ключа към ~/.ssh/authorized_keys на отдалечения сървър и задава правилните разрешения. Това е най-безопасният метод, тъй като предотвратява случайно презаписване на съществуващи ключове.

Метод Б — Ръчно внедряване

Използвайте това, когато ssh-copy-id не е наличен (напр. в някои среди на Windows или ограничени мрежи):

cat ~/.ssh/id_ed25519.pub | ssh root@your_vps_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Този единичен конвейер е по-безопасен от отварянето на текстов редактор на отдалечения сървър, тъй като добавя, а не презаписва.

Метод В — Ръчно чрез текстов редактор (Резервен вариант)

Влезте в сървъра с вашата парола:

ssh root@your_vps_ip

Създайте директорията .ssh, ако не съществува:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Отворете authorized_keys в текстов редактор:

nano ~/.ssh/authorized_keys

Поставете вашия публичен ключ на нов ред. Запазете с Ctrl+X, след това Y, след това Enter. Задайте разрешения:

chmod 600 ~/.ssh/authorized_keys

Излезте от сесията:

exit

Стъпка 3: Проверете влизането с ключ

Тествайте връзката преди да правите каквито и да е допълнителни промени в SSH демона. Отворете нов прозорец на терминала (не затваряйте съществуващата си сесия все още):

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Ако се свържете без подкана за парола, ключът работи. Продължете към стъпките за укрепване по-долу само след потвърждаване на това.

Критичен проблем: Ако деактивирате удостоверяването с парола, преди да проверите достъпа с ключ, и внедряването на ключа е неуспешно по каквато и да е причина, ще се заключите. Винаги тествайте първо.

Стъпка 4: Укрепете конфигурацията на SSH демона

След като достъпът с ключ е потвърден, отворете конфигурационния файл на SSH демона:

nano /etc/ssh/sshd_config

Приложете следните настройки:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes

Ключови бележки относно тези директиви:

• PermitRootLogin prohibit-password позволява влизане на root чрез ключ, но блокира влизането на root с парола — по-добър среден вариант от PermitRootLogin no, когато все още настройвате non-root sudo потребител.
• ChallengeResponseAuthentication no деактивира клавиатурно-интерактивното удостоверяване, което може да заобиколи PasswordAuthentication no при някои PAM конфигурации.
• При Ubuntu 22.04+, файлът /etc/ssh/sshd_config.d/50-cloud-init.conf може да замени вашите настройки. Проверете и редактирайте го при необходимост.

Проверете синтаксиса на конфигурацията преди рестартиране:

sshd -t

Ако не са докладвани грешки, рестартирайте SSH услугата:

systemctl restart sshd

На системи, използващи ssh.service вместо sshd.service:

systemctl restart ssh

Управление на множество SSH ключове и потребители

Реалните среди рядко включват един ключ и един потребител. Ето как да се справите с по-сложни сценарии.

Добавяне на ключове за множество потребители

Всеки потребителски акаунт има свой собствен файл ~/.ssh/authorized_keys. За да добавите ключ за non-root потребител с име deploy:

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
echo "ssh-ed25519 AAAAC3... deploy@ci-server" >> /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Стъпката chown се пропуска често и причинява неуспехи при удостоверяване — SELinux и OpenSSH проверяват, че файлът authorized_keys е собственост на удостоверяващия се потребител.

Ограничаване на това, което може да прави един ключ

Можете да поставите префикс с опции пред всеки ред в authorized_keys, за да ограничите неговите възможности. Това е особено полезно за ключове за внедряване или автоматизация на резервни копия:

command="/usr/bin/rsync --server --daemon .",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3... backup@monitoring

Този ключ може да изпълнява само rsync в режим на демон — нищо друго.

Използване на ~/.ssh/config за по-чисти връзки

Вместо да въвеждате дълги команди ssh, дефинирайте псевдоними на хостове на вашата локална машина:

Host myserver
    HostName 203.0.113.45
    User root
    IdentityFile ~/.ssh/id_ed25519
    Port 22

След запазване на това в ~/.ssh/config, свържете се просто с:

ssh myserver

Използване на ssh-agent за кеширане на парафрази

Ако вашият частен ключ има парафраза (трябва да има), добавете го към агента, за да не бъдете подканяни многократно:

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

На macOS, добавете --apple-use-keychain, за да запазите между рестартирания:

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

Чести проблеми и отстраняване на неизправности

Проблем: Все още се иска парола след добавяне на ключа

Стартирайте връзката с подробен изход за диагностика:

ssh -vvv root@your_vps_ip

Търсете редове като Offering public key и Server accepts key. Ако ключът е предложен, но отхвърлен, проблемът почти винаги е в разрешенията на файловете на сървъра.

Проверете разрешенията на сървъра:

ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

Необходими разрешения:

• ~/.ssh/ — 700 (drwx——)
• ~/.ssh/authorized_keys — 600 (-rw——-)
• Домашна директория ~/ — не трябва да е записваема от всички (755 или 750)

Проблем: SELinux блокира удостоверяването на RHEL/Rocky/AlmaLinux

restorecon -Rv ~/.ssh

Проблем: Файлът authorized_keys има Windows окончания на редове (CRLF)

Ако сте редактирали файла на Windows и сте го прехвърлили, окончанията на редовете може да са повредени. Поправете с:

sed -i 's/r//' ~/.ssh/authorized_keys

Проблем: Предлага се грешен ключ

Ако имате множество ключове, посочете правилния изрично:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Или го конфигурирайте в ~/.ssh/config, както е показано по-горе.

SSH ключове в контекста на вашата хостинг инфраструктура

SSH удостоверяването с ключ не е само проблем на един сървър — то се мащабира в цялата ви инфраструктура. Ако управлявате флот от dedicated сървъри, централизиран подход с инструменти като Ansible, Puppet или мениджър на тайни (HashiCorp Vault, AWS Secrets Manager) за разпространение и ротация на оторизирани ключове е от съществено значение.

За екипи, изпълняващи уеб приложения на VPS с cPanel, интерфейсът SSH достъп на cPanel в секцията за сигурност предоставя GUI за генериране и управление на двойки ключове — полезен за разработчици, които не са удобни с командния ред, но все пак се нуждаят от сигурен достъп.

Ако изпълнявате GPU-интензивни натоварвания на GPU хостинг инфраструктура, SSH удостоверяването с ключ е особено критично, тъй като тези инстанции често изпълняват дълготрайни, неналюдавани задачи. Компрометирано удостоверение на GPU сървър може да доведе до значителни неоторизирани разходи за изчисления в допълнение към излагането на данни.

Съчетаването на SSH укрепване с валиден SSL сертификат за всякакви уеб-ориентирани услуги, работещи на същия сървър, затваря едновременно двата най-чести вектора на атака — неудостоверен достъп до обвивката и некриптиран HTTP трафик.

За проекти, използващи споделен уеб хостинг, които също се нуждаят от SSH достъп, проверете дали вашият доставчик поддържа инжектиране на SSH ключ чрез панела за хостинг, тъй като споделените среди често ограничават SSH до конкретни потребители с ограничен достъп до обвивката.

Ротация на ключове и дългосрочно управление на ключове

SSH ключовете не изтичат автоматично. Без политика за ротация, ключ, компрометиран преди години, може все още да предоставя достъп. Установете следните практики:

• Ротирайте ключовете ежегодно или незабавно при съмнение за компрометиране.
• Одитирайте файловете authorized_keys на всички сървъри редовно. Премахнете ключове, принадлежащи на бивши служители или извадени от употреба услуги.
• Използвайте отделни ключове за всяко устройство — не копирайте един и същ частен ключ на множество лаптопи или сървъри. Ако едно устройство бъде изгубено, отменяте само този ключ.
• Използвайте отделни ключове за всяка роля — вашият ключ за личен достъп, ключът за внедряване на CI/CD и ключът за автоматизация на резервни копия трябва да бъдат различни.
• Документирайте собствеността на ключовете — поддържайте регистър, свързващ отпечатъка на всеки публичен ключ с неговия собственик, предназначение и дата на изтичане.

За да покажете отпечатъка на ключ за одит:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Контролен списък за технически решения

Използвайте тази матрица преди финализиране на вашата SSH ключова настройка:

• Алгоритъм: Използвайте Ed25519, освен ако не се свързвате към системи по-стари от OpenSSH 6.5; използвайте RSA 4096 като резервен вариант.
• Парафраза: Винаги задавайте такава за частни ключове, използвани от хора; ключовете за услуги, използвани от автоматизация, могат да я пропуснат, ако се съхраняват в мениджър на тайни.
• Метод на внедряване: Използвайте ssh-copy-id за интерактивни настройки; използвайте управление на конфигурацията (Ansible, Puppet) за внедрявания на флот.
• Проверка на разрешенията: Потвърдете 700 на ~/.ssh/, 600 на authorized_keys и правилна собственост преди деактивиране на удостоверяването с парола.
• Тествайте преди заключване: Винаги проверявайте влизането с ключ в отделна терминална сесия преди задаване на PasswordAuthentication no.
• Проверка на конфигурацията на демона: Стартирайте sshd -t преди рестартиране на SSH услугата, за да уловите синтактични грешки.
• Деактивиране на удостоверяването с парола: Задайте PasswordAuthentication no и ChallengeResponseAuthentication no заедно — едното само по себе си е недостатъчно на системи с активиран PAM.
• Политика за влизане на root: Предпочитайте PermitRootLogin prohibit-password пред PermitRootLogin yes; мигрирайте към non-root sudo потребител и задайте PermitRootLogin no като финалното укрепено състояние.
• Ротация на ключове: Планирайте годишна ротация; отменяйте незабавно при загуба на устройство или промяна на персонала.
• Одит: Периодично стартирайте grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys, за да прегледате всички оторизирани ключове в системата.

Често задавани въпроси

Мога ли да добавя множество SSH ключове към един и същ сървър?

Да. Всеки ред в ~/.ssh/authorized_keys представлява един оторизиран публичен ключ. Можете да добавите толкова ключове, колкото са необходими — по един на ред. Това позволява на множество администратори или множество устройства да се удостоверяват независимо, и можете да отмените всеки отделен ключ, като изтриете реда му, без да засягате другите.

Какво се случва, ако загубя частния си ключ след деактивиране на удостоверяването с парола?

Ще бъдете заключени от SSH. Възстановяването изисква достъп до сървъра чрез извънлентов метод: уеб конзолата на вашия хостинг доставчик, VNC или среда за стартиране при спасяване/възстановяване. Оттам можете да активирате отново удостоверяването с парола или да добавите нов публичен ключ. Ето защо е от съществено значение да пазите идентификационните данни за достъп до конзолата сигурни и отделни.

Поддържа ли се Ed25519 на всички сървъри?

Ed25519 изисква OpenSSH 6.5 или по-нова версия, издадена през януари 2014 г. Всеки сървър, работещ с модерна Linux дистрибуция (Ubuntu 18.04+, Debian 9+, CentOS 7+, Rocky Linux 8+), го поддържа. Единственият сценарий, изискващ RSA, е свързването към наистина наследени системи или вградени устройства с остарели OpenSSH компилации.

Добавянето на SSH ключ автоматично ли деактивира влизането с парола?

Не. Добавянето на ключ към authorized_keys активира влизането с ключ, но не деактивира удостоверяването с парола. Трябва изрично да зададете PasswordAuthentication no в /etc/ssh/sshd_config и да рестартирате SSH демона, за да наложите достъп само с ключ.

Мога ли да използвам една и съща двойка SSH ключове за множество сървъри?

Технически да, но не се препоръчва за производствени среди. Използването на един ключ за много сървъри означава, че компрометирането на един частен ключ предоставя достъп до всички тях. По-добрата практика е да използвате ключове за всяко устройство (по един ключ за всяка работна станция или лаптоп), така че загубата на устройство изисква отмяна само на този ключ в целия ви флот от сървъри, а не едновременна замяна на ключове навсякъде.