Как да създадете SSH ключове с OpenSSH на macOS или Linux

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

SSH двойката ключове се състои от два математически свързани файла: частен ключ (съхраняван изключително на вашата локална машина, никога не се споделя) и публичен ключ (разгърнат на всеки сървър, до който трябва да имате достъп). Когато инициирате връзка, OpenSSH използва handshake с предизвикателство-отговор, за да провери дали вашият частен ключ съответства на публичния ключ на сървъра, предоставяйки достъп без искане на парола.

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

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

• Криптографска сила: 4096-битов RSA ключ или Ed25519 ключ е изчислително невъзможно да бъде разбит с груба сила с текущия хардуер.
• Никакъв секрет не се предава по мрежата: Частният ключ никога не напуска вашата машина. Протоколът за удостоверяване доказва притежанието без разкриване.
• Готовност за автоматизация: CI/CD конвейери, Ansible playbooks, rsync задачи и cron-базирани резервни копия изискват неинтерактивно удостоверяване. SSH ключовете правят това възможно без вграждане на пароли в обикновен текст в скриптове.
• Проследяемост: Всяка двойка ключове може да бъде уникално идентифицирана по нейния fingerprint, което улеснява отмяната на един компрометиран ключ без ротация на идентификационни данни навсякъде.
• Съвместимост с authorized_keys ACL: Можете да ограничите конкретен публичен ключ да изпълнява само една команда, да го обвържете с изходен IP или да предотвратите пренасочване на портове — контроли, които удостоверяването с парола не може да репликира.

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

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

Оригиналната документация на OpenSSH и повечето наследени уроци използват RSA по подразбиране. Областта се е развила. Ето прецизно сравнение на всеки алгоритъм, който ssh-keygen поддържа днес:

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

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

• Работна станция с macOS или Linux с инсталиран OpenSSH. И двете операционни системи се доставят с OpenSSH по подразбиране. Проверете с:

ssh -V

• Мрежов достъп до отдалечен сървър, където имате акаунт (root или непривилегирован).
• Основно познаване на терминал.

При Linux дистрибуции, доставяни с минимална инсталация (Alpine, някои Debian netinstall), инсталирайте клиентските инструменти с:

# Debian / Ubuntu
sudo apt install openssh-client

# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install openssh-clients

Стъпка 1: Отворете терминал

macOS: Натиснете Cmd + Space, въведете Terminal и натиснете Enter. Алтернативно, навигирайте до Applications > Utilities > Terminal. Напредналите потребители могат да използват iTerm2 или вградения терминал в VS Code.

Linux: Натиснете Ctrl + Alt + T в повечето десктоп среди или стартирайте емулатора на терминал на вашата дистрибуция от менюто с приложения.

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

Генериране на Ed25519 ключ (препоръчително)

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

Флагът -C добавя четим от човека коментар към публичния ключ. Използвайте вашия имейл адрес, hostname или описателен етикет като "deploy-key-prod" — той няма криптографска функция, но е безценен при одит на authorized_keys файлове, натрупали десетки записи.

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

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

Използвайте -b 4096 изрично. Историческото значение по подразбиране от 2048 bits е все още технически приемливо, но осигурява по-малък резерв срещу бъдещи напредъци в алгоритмите за факторизация. Никога не използвайте -b 1024 или -b 2048 за нови ключове, ако е налично 4096.

Генериране на именуван ключ за конкретен хост

При управление на множество сървъри или роли, използвайте отделни файлове с ключове вместо да използвате повторно един ключ навсякъде. Компрометиран ключ тогава засяга само системите, на които е бил разгърнат:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod_webserver -C "prod-webserver-2024"

Стъпка 3: Изберете местоположение за съхранение

След изпълнение на ssh-keygen, ще видите:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519):

Натиснете Enter, за да приемете стойността по подразбиране (~/.ssh/id_ed25519 за Ed25519, ~/.ssh/id_rsa за RSA), или въведете персонализиран път. Местоположението по подразбиране е подходящо за единичен ключ с общо предназначение. За ключове, специфични за роля, винаги посочвайте описателно файлово име, както е показано в предишната стъпка.

Критична бележка за разрешенията на файловете: Директорията ~/.ssh/ трябва да е с режим 700 и файловете с частни ключове трябва да са с режим 600. OpenSSH ще откаже да използва ключове с прекалено разрешителни права и ще отпечата предупреждение. Ако някога копирате ключове между машини, незабавно проверете разрешенията:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Стъпка 4: Задайте парола

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Паролата криптира файла с частния ключ на диска, използвайки AES-256-CBC (в съвременния OpenSSH). Ако нападател получи вашия файл с частен ключ — чрез откраднат лаптоп, компрометирано резервно копие или неправилно конфигуриран облачен snapshot — силната парола е последната линия на защита, която го предотвратява да го използва.

Кога да пропуснете паролата: Автоматизираните сервизни акаунти (конвейери за разгръщане, агенти за резервни копия), работещи без надзор, легитимно се нуждаят от ключове без парола. В такъв случай ограничете разрешенията на ключа от страна на сървъра, използвайки опции на authorized_keys (вижте разширения раздел по-долу) и съхранявайте частния ключ в мениджър на тайни, а не в споделена файлова система.

След потвърждаване на паролата, OpenSSH извежда fingerprint на ключа и изображение с произволно изкуство:

Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123XYZexampleFingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        .o+.     |
...
+----[SHA256]-----+

Запишете fingerprint. Ще го използвате за проверка на самоличността на ключа при одит на сървъри.

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

Метод 1: ssh-copy-id (Най-бърз)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

Флагът -i изрично указва кой публичен ключ да се копира, предотвратявайки ssh-copy-id да качи всеки ключ от вашия агент. Ще бъдете подканени за паролата на сървъра веднъж. Инструментът обработва автоматично създаването на директория, добавянето към файл и задаването на разрешения.

Метод 2: Ръчно разгръщане (когато ssh-copy-id не е наличен)

Това е правилният подход, когато отдалечената система е Windows, мрежово устройство или контейнер без ssh-copy-id в пътя.

Първо, покажете вашия публичен ключ:

cat ~/.ssh/id_ed25519.pub

Копирайте целия изход — той е един ред, започващ с ssh-ed25519 (или ssh-rsa). След това влезте в сървъра и го добавете:

ssh user@your-server.com

След свързване:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-full-public-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Честа грешка: Използването на > вместо >> презаписва целия файл authorized_keys, блокирайки всеки друг ключ. Винаги използвайте >> за добавяне.

Метод 3: Пренасочване по SSH в една команда

Ако вече имате достъп с парола и искате да разгърнете без интерактивно влизане:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Стъпка 6: Тествайте връзката

ssh -i ~/.ssh/id_ed25519 user@your-server.com

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

ssh -vvv -i ~/.ssh/id_ed25519 user@your-server.com

Флагът -vvv отпечатва пълния журнал на договарянето, показвайки точно кой ключ е бил предложен, дали сървърът го е приел и къде е се е провалил handshake.

Стъпка 7: Конфигурирайте ~/.ssh/config за постоянни профили на хостове

Въвеждането на пълната ssh -i ~/.ssh/id_ed25519_prod_webserver user@203.0.113.45 всеки път е склонно към грешки и бавно. Конфигурационният файл на SSH клиента елиминира това:

nano ~/.ssh/config

Добавете блок за хост:

Host prod-web
    HostName 203.0.113.45
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod_webserver
    Port 2222
    ServerAliveInterval 60

Сега се свържете просто с:

ssh prod-web

Този модел се мащабира чисто до десетки сървъри и е от съществено значение за всеки инженер, управляващ инфраструктура в мащаб. Директивата ServerAliveInterval 60 изпраща пакет за поддържане на активността на всеки 60 секунди, предотвратявайки прекъсването на неактивни връзки от защитни стени — често разочарование при облачни доставчици.

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

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

Стартирайте агента и добавете ключ:

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

На macOS можете да запазите ключовете между рестартирания, като добавите следното към ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

Директивата UseKeychain yes се интегрира с macOS Keychain, съхранявайки паролата сигурно, така че да оцелее след рестартиране на системата.

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

ssh-add -l

Премахнете конкретен ключ от агента:

ssh-add -d ~/.ssh/id_ed25519

Разширено: Ограничаване на ключове в authorized_keys

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

command="/usr/bin/rsync --server ...",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... backup-key

Тези опции са особено ценни за ключове за разгръщане на dedicated сървъри, където един компрометиран CI/CD ключ не трябва да предоставя пълен достъп до обвивката.

Укрепване на SSH демона след разгръщане на ключове

След като удостоверяването с ключ работи, деактивирайте изцяло удостоверяването с парола на сървъра. Редактирайте /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Задайте следните директиви:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey

Презаредете демона без прекъсване на текущата ви сесия:

sudo systemctl reload sshd

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

За сървъри, работещи в среди с cPanel VPS, имайте предвид, че някои версии на cPanel управляват собствената си SSH конфигурация. Проверете дали промените в sshd_config се запазват след актуализации на cPanel, като проверите /etc/ssh/sshd_config.d/ за файлове с замествания.

Ротация и отмяна на SSH ключове

Ротацията на ключове е практика за хигиена на сигурността, която ограничава прозореца на излагане, ако ключ е безшумно компрометиран. Практичен график за ротация е на всеки 12 месеца за лични ключове и на всеки 90 дни за ключове на сервизни акаунти.

За отмяна на ключ: Премахнете неговия ред от ~/.ssh/authorized_keys на всеки сървър, където е бил разгърнат. Няма централен механизъм за отмяна в стандартния OpenSSH — ето защо поддържането на инвентар на местата, където е разгърнат всеки fingerprint на ключ, е важно.

За ротация на ключ:

1. Генерирайте нова двойка ключове.
2. Разгърнете новия публичен ключ на всички целеви сървъри.
3. Тествайте свързаността с новия ключ.
4. Премахнете стария публичен ключ от всички файлове authorized_keys.
5. Изтрийте или архивирайте стария частен ключ локално.

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

Прехвърляне на ключове между машини

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

Копирайте частния ключ сигурно, използвайки scp или rsync по SSH:

scp ~/.ssh/id_ed25519 newmachine.local:~/.ssh/id_ed25519

Алтернативно, използвайте криптирано USB устройство или мениджър на пароли, поддържащ съхранение на SSH ключове (1Password, Bitwarden и HashiCorp Vault всички поддържат това). Никога не изпращайте частни ключове по имейл или ги съхранявайте в некриптирано облачно хранилище.

След прехвърлянето незабавно проверете разрешенията на новата машина:

chmod 600 ~/.ssh/id_ed25519

Проверка на fingerprint на хост ключа на сървъра

При първото свързване към сървър, OpenSSH представя fingerprint на хост ключа на сървъра и ви моли да го потвърдите:

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexample.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Никога не въвеждайте yes сляпо. Получете очаквания fingerprint чрез извънлентов канал — контролния панел на вашия хостинг доставчик, колега, конфигурирал сървъра, или конзолния изход на сървъра. Тази стъпка предотвратява атаки тип man-in-the-middle. За среди с споделен хостинг, очакваният fingerprint обикновено е посочен в контролния панел под настройките за SSH достъп.

След приемане, fingerprint се съхранява в ~/.ssh/known_hosts. Ако fingerprint се промени неочаквано при последваща връзка, OpenSSH ще откаже да се свърже и ще покаже предупреждение — третирайте това като сериозно събитие за сигурност, изискващо разследване преди продължаване.

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

Използвайте този контролен списък, преди да считате настройката на SSH ключовете си готова за производство:

• [ ] Алгоритъмът на ключа е Ed25519 (или RSA 4096 за съвместимост с наследени системи) — DSA и ECDSA 256 не са приемливи за нови разгръщания
• [ ] Разрешенията на файла с частния ключ са 600; разрешенията на директорията ~/.ssh/ са 700
• [ ] Силна парола е зададена на всички интерактивни потребителски ключове
• [ ] Ключовете на сервизни акаунти без пароли са ограничени чрез опции на authorized_keys (command=, from=, no-pty)
• [ ] PasswordAuthentication no е зададен в /etc/ssh/sshd_config на всички сървъри
• [ ] PermitRootLogin prohibit-password или PermitRootLogin no е наложен
• [ ] Fingerprint на хост ключовете на сървъра са проверени извънлентово
• [ ] Съществува инвентар на ключовете, свързващ всеки fingerprint със сървърите, където е разгърнат
• [ ] Графикът за ротация на ключове е дефиниран и планиран в календара
• [ ] Блоковете за хост в ~/.ssh/config са конфигурирани, за да се избегне ръчното използване на флага -i
• [ ] SSH агентът се използва, за да се избегне повторното въвеждане на паролата по време на работни сесии
• [ ] Записите в known_hosts се преглеждат периодично за остарели или неочаквани записи

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

Каква е разликата между Ed25519 и RSA SSH ключове?

Ed25519 използва криптография с елиптични криви с фиксиран 256-bit ключ, осигуряващ приблизително 128 бита сигурност, подписва операции по-бързо от RSA и произвежда по-кратки ключови низове. RSA при 4096 bits осигурява сравнима сигурност, но е по-бавен и генерира по-голям ключов материал. Използвайте Ed25519 за всички нови ключове, освен ако не трябва да се свързвате към система, работеща с OpenSSH по-стара от версия 6.5.

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

Да, технически. Въпреки това, най-добрата практика е да използвате отделни двойки ключове за всяка роля или среда (достъп от лична работна станция, разгръщане чрез CI/CD, поддръжка на база данни). Това ограничава въздействието на един компрометиран ключ и прави отмяната лесна без нарушаване на несвързани системи.

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

Губите способността да се удостоверявате с тази двойка ключове. Публичният ключ на сървъра става безполезен. Трябва да получите достъп до сървъра чрез алтернативен метод — конзолен достъп, вторичен ключ или спешен достъп на вашия хостинг доставчик — след което да премахнете осиротелия публичен ключ от authorized_keys и да разгърнете нова двойка ключове.

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

Най-честите причини са: неправилни разрешения на ~/.ssh/ (трябва да е 700) или ~/.ssh/authorized_keys (трябва да е 600) на сървъра; домашната директория сама по себе си е записваема от всички; SELinux или AppArmor блокира достъпа до директорията .ssh; или PubkeyAuthentication no е зададен в /etc/ssh/sshd_config. Изпълнете ssh -vvv, за да идентифицирате точно кой метод за удостоверяване се опитва и се отхвърля.

Как да премахна SSH ключ от сървър, до който вече нямам достъп?

Ако нямате друг метод за удостоверяване, свържете се с екипа за поддръжка на вашия хостинг доставчик или използвайте извънлентов конзолен достъп (наличен за клиенти на VPS и dedicated сървър), за да влезете и да редактирате ~/.ssh/authorized_keys директно. Ето защо поддържането на идентификационни данни за конзолен достъп отделно от SSH ключовете е неотменимо оперативно изискване.