Управление на SSH ключове и Keychain в Linux/WSL
Работата със SSH ключове е една от най-важните стъпки за осигуряване на сигурен достъп до сървъри и виртуални машини. Често, когато използваме инструменти като Keychain, можем да срещнем предупреждения за липсващи публични ключове или неправилно подадени файлове.
В тази статия ще разгледаме как да конфигурираме правилно SSH ключовете, как да създадем .pub файлове, ако липсват, както и как да прехвърлим цялата конфигурация към друга виртуалка.
Проверка на наличните ключове
Първо, проверяваме съдържанието на директорията ~/.ssh/:
ls -l ~/.ssh/
Примерен резултат:
-rw------- 1 user user 399 Aug 23 08:47 id_ed25519
-rw-r--r-- 1 user user 96 Jul 26 22:00 id_ed25519.pub
-rw------- 1 user user 2610 Jul 26 14:28 server_key_rsa
-rw-r--r-- 1 user user 742 Jul 26 14:27 id_rsa.pub
-rw------- 1 user user 5742 Aug 14 15:51 known_hosts
Тук виждаме:
- частни ключове (
id_ed25519,server_key_rsa) – те трябва да останат строго защитени (chmod 600). - публични ключове (
id_ed25519.pub,id_rsa.pub) – те се качват на сървъра. - known_hosts – съхранява отпечатъци на сървъри, към които вече сме се свързвали.
Какво да правим, ако липсва .pub файл?
Често се случва да имаме само частния ключ (например id_rsa или tablet.id_rsa), но да липсва .pub. В такъв случай можем лесно да го генерираме:
ssh-keygen -y -f ~/.ssh/tablet.id_rsa > ~/.ssh/tablet.id_rsa.pub
След това проверяваме:
cat ~/.ssh/tablet.id_rsa.pub
Прехвърляне на ключове към друга виртуалка
Най-лесният и бърз метод е чрез rsync или scp. Например:
rsync -avz ~/.ssh/ [email protected]:~/
или:
scp -r ~/.ssh/ [email protected]:~/
След прехвърлянето на ключовете, проверяваме правата:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
chmod 644 ~/.ssh/*.pub
chmod 644 ~/.ssh/config
chmod 644 ~/.ssh/known_hosts
Инсталиране и конфигуриране на Keychain
Keychain е удобен инструмент, който се грижи да зарежда SSH ключовете автоматично и да избягваме повторно въвеждане на парола/фраза.
Инсталация
В Ubuntu/WSL:
sudo apt install keychain -y
Конфигурация
Редактираме ~/.bashrc или ~/.zshrc и добавяме:
# Keychain конфигурация
eval $(keychain --eval --quiet id_ed25519 tablet.id_rsa)
Това казва на Keychain да зарежда двата ключа при всяко ново отваряне на терминала.
След промяна презареждаме:
source ~/.bashrc
Проверка
keychain -l
Ще видим списък с активните ключове. Ако всички .pub файлове са налични, няма да има предупреждения.
- В
.bashrcили.zshrcизползвай конкретни ключове:
# Стартира ssh-agent и запазва ключовете между сесиите
eval $(keychain --quiet --eval \
~/.ssh/007_rsa \
~/.ssh/id_ed25519 \
~/.ssh/tel.id_rsa
)
- Това ще добави само съществуващите private keys.
- Ако има предупрежденията за
id_rsaи липсващи.pubфайлове ще изчезнат.
Допълнителна идея – централизирано управление на ключове
Ако управляваме много виртуални машини, не е удобно ръчно да прехвърляме .ssh.
Тук идват няколко по-професионални решения:
- Ansible playbook – можем да опишем кои ключове да се разпределят и на кои сървъри. Един път пускаме скрипта и всичко е готово.
- Git + GPG криптиране – ключовете се пазят в частно Git хранилище, криптирани с GPG, и могат да се синхронизират лесно на нови машини.
- HashiCorp Vault или 1Password CLI – за корпоративна среда ключовете може да се съхраняват сигурно и да се извличат при нужда.
Съвети за сигурност
- Никога не изпращайте SSH ключове по e-mail или в чат.
- Давайте правилни права на
.ssh, за да не бъдат четени от други потребители. - Използвайте еднократни или ограничени ключове за тестови машини.
- Предпочитайте Ed25519 пред RSA – по-сигурен и по-бърз.
Заключение
С правилната конфигурация:
- няма да виждаме излишни предупреждения;
- можем лесно да прехвърляме ключове между сървъри;
- ще използваме Keychain за автоматично управление на SSH ключовете.
Това спестява време, прави работата по-сигурна и ни доближава максимално до удобството, с което се работи в корпоративни среди.
Благодарим ви за прочитането на статията! Ако намерихте информацията за полезна, можете да дарите посредством бутоните по-долу:
Donate ☕️ Дарете с PayPalDonate 💳 Дарете с Revolut
