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

SSH публичният ключ е криптографски идентификатор, съхраняван в ~/.ssh/authorized_keys на отдалечен сървър, който предоставя достъп на всеки клиент, притежаващ съответния частен ключ — без да се предава парола по мрежата. Качването на вашия публичен ключ на съществуващ VPS заменя или допълва удостоверяването с парола с асиметрична криптография, елиминирайки повърхността за атака, използвана от brute-force кампании и кампании за пълнене с идентификационни данни.

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

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

Преди да докоснете дори една команда, си струва да разберете криптографската механика. Когато се удостоверявате с двойка ключове, сървърът издава предизвикателство, криптирано с вашия публичен ключ. Само притежателят на съответния частен ключ може да дешифрира и подпише отговора. Никаква тайна никога не се предава — за разлика от удостоверяването с парола, при което самият идентификатор пътува по мрежата (дори ако е обвит в TLS).

Практическият извод: при всяка VPS Хостинг среда, изложена на публичния интернет, SSH ключовете не са незадължително затягане — те са базовото изискване.

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

• Съществуващ VPS, достъпен чрез SSH (в момента работи вход с парола или съществуващ ключ)
• Локална машина с Linux, macOS или Windows с OpenSSH или PuTTY
• Достатъчно привилегии на VPS за запис в домашната директория на целевия потребител
• Основни познания за терминал и текстов редактор като nano или vim

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

Ако вече имате двойка ключове в ~/.ssh/id_ed25519 или ~/.ssh/id_rsa, прескочете напред. В противен случай генерирайте такава сега.

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

Ed25519 е съвременният стандарт. Използвайте RSA 4096 само при свързване към наследени сървъри, които не поддържат Ed25519.

Генериране на двойка Ed25519 ключове:

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

Генериране на двойка RSA 4096 ключове (наследени системи):

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

По време на генерирането на ключа ще бъдете подканени за път за запис и незадължителна парола. Приемането на пътя по подразбиране (~/.ssh/id_ed25519) е подходящо за повечето потребители. Винаги задавайте парола — тя криптира частния ключ на диска с AES-256, така че откраднат лаптоп не означава автоматично компрометиран сървър.

Процесът създава два файла:

~/.ssh/id_ed25519 — вашият частен ключ. Никога не го споделяйте, никога не го копирайте на сървър, никога не го добавяйте към система за контрол на версиите.
~/.ssh/id_ed25519.pub — вашият публичен ключ. Безопасно е да го разпространявате свободно.

Покажете публичния ключ, за да можете да го копирате:
cat ~/.ssh/id_ed25519.pub
Изходът ще изглежда подобно на:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com
Копирайте целия едноредов низ, включително префикса на алгоритъма и коментара в края.
Стъпка 2: Влезте във вашия VPS
Свържете се с VPS, използвайки текущия метод за удостоверяване:
ssh root@your_vps_ip
Заменете your_vps_ip с действителния IPv4 или IPv6 адрес на вашия сървър. Ако управлявате акаунт на потребител, различен от root, заменете root с подходящото потребителско име. На Dedicated Servers, където може да имате множество потребителски акаунти, винаги предпочитайте да внедрявате ключове за потребител, различен от root, и да използвате sudo за ескалация на привилегии.
Стъпка 3: Подготовка на директорията .ssh
След като влезете, проверете или създайте директорията .ssh за целевия потребител:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
Разрешението 700 (rwx------) е задължително. OpenSSH тихо ще откаже да използва authorized_keys, ако директорията .ssh е записваема от групата или от всички. Това е една от най-честите причини удостоверяването с ключ да се провали след иначе правилна настройка.
Стъпка 4: Добавяне на публичния ключ към authorized_keys
Метод А: Ръчно поставяне (универсален)
Отворете или създайте файла authorized_keys:
nano ~/.ssh/authorized_keys
Поставете вашия публичен ключ на нов ред. Всеки ред в този файл представлява един оторизиран ключ. Запазете с Ctrl+X, след това Y, след това Enter.
Задайте правилните разрешения:
chmod 600 ~/.ssh/authorized_keys
Разрешението 600 (rw-------) гарантира, че само собственикът на файла може да го чете или записва. OpenSSH прилага това стриктно.
Метод Б: ssh-copy-id (препоръчан за бързина)
Ако вашата локална машина разполага с ssh-copy-id (стандартно на Linux и macOS), тази единична команда автоматично се грижи за създаването на директорията, добавянето на ключа и задаването на разрешенията:
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip
Ще бъдете подканени веднъж за текущата SSH парола. След това влизането с ключ е активно. Флагът -i изрично указва кой публичен ключ да се качи, предотвратявайки случайно качване на грешен ключ.
Метод В: Едноредова команда чрез cat и пренасочване (подходящ за скриптове)
Полезен в автоматизирани процеси или когато ssh-copy-id не е наличен:
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"
Този подход е безопасен по отношение на идемпотентност в смисъл, че добавя, а не презаписва, запазвайки всички съществуващи оторизирани ключове.
Стъпка 5: Проверка на правилната собственост на файловете
Често пренебрегван проблем: ако сте създали директорията .ssh или файла authorized_keys като root при настройване на акаунт на друг потребител, собствеността ще бъде грешна и SSH тихо ще отхвърли ключа.
Проверете собствеността:
ls -la ~/.ssh/
Изходът трябва да показва целевото потребителско име като собственик и група за директорията и файла:
drwx------ 2 alice alice 4096 Jan 15 10:00 .ssh
-rw------- 1 alice alice  571 Jan 15 10:00 .ssh/authorized_keys
Ако собствеността е неправилна, коригирайте я (изпълнете като root):
chown -R alice:alice /home/alice/.ssh
Стъпка 6: Тестване на влизането с SSH ключ
Излезте от текущата сесия:
exit
Свържете се отново с изрично указване на ключа, за да потвърдите настройката:
ssh -i ~/.ssh/id_ed25519 root@your_vps_ip
Ако влизането успее без подкана за парола (или подканва само за локалната парола на ключа), конфигурацията е правилна. Ако все още иска парола за сървъра, преминете към раздела за отстраняване на неизправности по-долу.
Стъпка 7: Затягане на конфигурацията на SSH демона
След като влизането с ключ е потвърдено като работещо, деактивирайте удостоверяването с парола, за да елиминирате напълно вектора за brute-force атака с парола.
Отворете конфигурационния файл на SSH демона:
nano /etc/ssh/sshd_config
Намерете и задайте следните директиви. Ако ред е коментиран с #, премахнете # и задайте стойността:
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes
Бележка относно PermitRootLogin prohibit-password: тази настройка позволява влизане като root изключително чрез ключ, блокирайки достъпа на root с парола, като същевременно разрешава сесии на root, удостоверени с ключ. За максимално затягане задайте стойност no и използвайте потребител, различен от root, с sudo.
При някои дистрибуции допълнителен конфигурационен файл може да замени вашите настройки. Проверете за замени:
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
Ако някой файл в тази директория задава PasswordAuthentication yes, редактирайте или премахнете го.
Проверете синтаксиса на конфигурацията преди рестартиране:
sshd -t
Чист изход (без грешки) означава, че е безопасно да презаредите. Приложете промените:
systemctl restart sshd
Критично предупреждение: Не затваряйте съществуващата SSH сесия, преди да отворите втори терминал и да потвърдите, че все още можете да влезете с вашия ключ. Рестартирането на sshd с неправилно конфигуриран файл или преди ключът ви да работи ще ви заключи. Повечето VPS контролни панели предоставят аварийна конзола (KVM/VNC достъп) за възстановяване, но е много по-добре да избегнете ситуацията изцяло.
Стъпка 8: Управление на множество ключове и сървъри с ~/.ssh/config
При управление на няколко сървъра — обичайно в среди за тестване/производство или при администриране на множество Dedicated Servers — конфигурационният файл на SSH клиента елиминира необходимостта от запомняне на IP адреси, потребителски имена и пътища до ключове.
Създайте или редактирайте ~/.ssh/config на вашата локална машина:
nano ~/.ssh/config
Примерна конфигурация за множество хостове:
Host production-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host staging-vps
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    Port 2222

Host legacy-server
    HostName 203.0.113.30
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    PubkeyAcceptedKeyTypes +ssh-rsa
Задайте правилните разрешения за конфигурационния файл:
chmod 600 ~/.ssh/config
Вече можете да се свързвате с удобни псевдоними:
ssh production-vps
ssh staging-vps
Директивата PubkeyAcceptedKeyTypes +ssh-rsa в наследения запис е важна: по-новите OpenSSH клиенти (8.8+) деактивират RSA-SHA1 по подразбиране. Без това замяна, връзките към по-стари сървъри ще се провалят с неясна грешка „no matching host key type”.
Отстраняване на неизправности: Защо удостоверяването с SSH ключ се проваля
Дори при правилна настройка, няколко фактора на средата могат да накарат удостоверяването с ключ тихо да се върне към подкани за парола:
Грешни разрешения за .ssh или authorized_keys:
Изпълнете ls -la ~/.ssh/ на сървъра. Директорията трябва да е 700, а файлът трябва да е 600. По-слаби разрешения карат OpenSSH да игнорира файла.
Несъответствие на SELinux или AppArmor контекст:
На RHEL/CentOS/AlmaLinux системи с активен SELinux, файлът authorized_keys може да има грешен контекст за сигурност. Възстановете го с:
restorecon -Rv ~/.ssh
Грешна домашна директория на потребителя:
Ако домашната директория на потребителя не е записваема само от собственика, SSH ще откаже удостоверяването с ключ. Проверете с:
ls -ld ~
Самата домашна директория не трябва да е записваема от групата или от всички.
Директивата AuthorizedKeysFile сочи другаде:
Някои дистрибуции конфигурират AuthorizedKeysFile да използва нестандартен път (напр. /etc/ssh/authorized_keys/%u). Проверете активната настройка:
sshd -T | grep authorizedkeysfile
Множество ключове и конфликти с ssh-agent:
Ако ssh-agent работи с няколко заредени ключа, сървърът може да откаже връзката след твърде много неуспешни опити с ключ, преди да изпробва правилния. Използвайте -i, за да укажете ключа изрично, или конфигурирайте IdentitiesOnly yes в ~/.ssh/config.
Защитна стена или fail2ban блокира вашия IP:
Ако преди това сте имали множество неуспешни опити за влизане, fail2ban или правилата на ufw/iptables може временно да са забранили вашия IP. Проверете с:
fail2ban-client status sshd
Ротация и отмяна на SSH ключове
Ротацията на ключове е практика за хигиена на сигурността, която често се пренебрегва. За да отмените конкретен ключ, отворете ~/.ssh/authorized_keys на сървъра и изтрийте съответния ред. Всеки ред е един ключ — премахването му незабавно отменя достъпа за притежателя на този частен ключ, без да засяга другите оторизирани ключове.
За целите на одита използвайте различни коментари за всеки ключ (частта след материала на ключа, напр. alice@workstation-2024), за да можете да идентифицирате кой ключ принадлежи на кое лице или устройство. Когато служител напусне или устройство бъде извадено от употреба, намерете ключа му по коментар и го премахнете.
За да ротирате собствения си ключ, генерирайте нова двойка, добавете новия публичен ключ към authorized_keys, проверете дали влизането работи с новия ключ, след което премахнете стария запис на ключа.
Практически контролен списък

Генерирайте Ed25519 ключове по подразбиране; използвайте RSA 4096 само за съвместимост с наследени сървъри
Винаги защитавайте частния си ключ със силна парола
Използвайте ssh-copy-id за бързо и безгрешно внедряване на ключове, когато е възможно
Проверете дали разрешенията на директорията .ssh са 700 и authorized_keys е 600

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

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

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

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

Ще бъдете заключени от SSH. Възстановяването изисква използване на извънлентов конзолен достъп на вашия хостинг доставчик (KVM/VNC), който е наличен чрез повечето контролни панели за VPS Хостинг. От конзолата отново активирайте PasswordAuthentication yes в /etc/ssh/sshd_config, рестартирайте sshd и качете нов ключ. Ето защо тестването на влизането с ключ преди деактивиране на паролите е задължително.

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

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

Трябва ли да използвам една и съща двойка SSH ключове за всеки сървър, който управлявам?

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

Качването на SSH ключ засяга ли моите SSL сертификати или конфигурацията на уеб сървъра?

Не. SSH ключовете управляват терминалния достъп до операционната система и са напълно отделни от TLS/SSL сертификатите, използвани от уеб сървърите (Apache, Nginx) за HTTPS. Те използват различни портове (22 срещу 443), различни формати на ключове и различни вериги на доверие. Промяната на едното няма никакъв ефект върху другото.