SSH-agent va host tekshiruvi

SSH kalit autentifikatsiyasi maqolasida passphrase bilan himoyalangan kalit har safar ishlatilganda shu passphrase’ni so'rashi aytib o'tilgan edi, SSH konfiguratsiyasi maqolasida esa birinchi ulanishda chiqadigan host key so'rovi o'tkinchi tilga olingan edi — ikkalasi ham keyinga qoldirilgan edi. Bu maqola shu ikki mexanizmni chuqur ko'rib chiqadi: passphrase’ni qayta-qayta yozmaslik uchun ssh-agent va ulanayotgan serveringiz o'zini kim deb ko'rsatsa, haqiqatan o'sha ekanini tasdiqlash uchun host key tekshiruvi.

ssh-agent: passphrase’ni bir marta kiritish

Agar private key passphrase bilan himoyalangan bo'lsa, bu passphrase har bir ssh yoki scp chaqiruvida qayta so'raladi — bir nechta serverga ketma-ket ulanganda yoki skriptlarda bu noqulay. ssh-agent — private key’ni bir marta ochib, uni xotirada saqlaydigan va sessiyaning qolgan qismida passphrase’ni qayta so'ramasdan har bir SSH so'roviga xizmat qiladigan fon jarayoni.

Muhim tafsilot: boshqa dasturlar undan foydalanganda ham private key’ning o'zi agent’dan hech qachon chiqmaydi — ular faqat agent’dan "buni mening nomimdan imzola" deb so'raydi, kalitning o'zini esa hech qachon olmaydi.

Agent’ni ishga tushirish va kalit qo'shish

ssh-agent ko'p zamonaviy desktop muhitlarida avtomatik ishga tushadi. Serverda yoki minimal muhitda uni qo'lda ishga tushirish kerak bo'lishi mumkin:

eval "$(ssh-agent -s)"

Agent pid 4821

Kalitni agent’ga qo'shish:

ssh-add ~/.ssh/id_ed25519

Enter passphrase for /home/alice/.ssh/id_ed25519:
Identity added: /home/alice/.ssh/id_ed25519 (alice@laptop)

Passphrase aynan shu yerda bir marta so'raladi. Shu sessiyadagi keyingi har bir ssh alice@server chaqiruvi uni qayta so'ramaydi.

Agent’dagi kalitlarni ro'yxatlash va olib tashlash

ssh-add -l

256 SHA256:k3f9Xq...Qz8 alice@laptop (ED25519)

Agent’dagi barcha kalitlarni olib tashlash (masalan, ish stantsiyasini boshqa odamga topshirishdan oldin):

ssh-add -D

Host key tekshiruvi: server shaxsini tasdiqlash

SSH asoslari maqolasidagi birinchi ulanishda ko'rilgan so'rov aslida ikki tomonlama ishonch munosabatining faqat yarmi: passphrase va private key serverga sizning shaxsingizni isbotlaydi, host key esa sizga serverning shaxsini isbotlaydi.

Nega bu muhim: man-in-the-middle vaziyati

Tasavvur qiling, siz ssh [email protected] deb yozyapsiz, tarmoqdagi kimdir esa trafikni DNS yoki ARP darajasida qayta yo'naltirib, o'zini haqiqiy server sifatida ko'rsatyapti — bu man-in-the-middle hujumi. Agar SSH klienti server shaxsini umuman tekshirmasa, siz bilmagan holda login ma’lumotlaringizni yoki hech bo'lmaganda autentifikatsiya urinishini to'g'ridan-to'g'ri soxta serverga yuborgan bo'lardingiz.

Buning oldini olish uchun har bir SSH serverda doimiy host key juftligi bor (odatda /etc/ssh/ssh_host_ed25519_key kabi fayllarda saqlanadi). Birinchi ulanishda klient shu kalitning fingerprint'ini — qisqa, odam o'qiy oladigan hash’ini — ko'rsatadi va tasdiq so'raydi:

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

To'g'ri xavfsizlik amaliyoti — bu fingerprint’ni serverni boshqaradigan odam bilan alohida kanal orqali tasdiqlash: masalan, ichki chat xabari orqali yoki boshqa sessiyadan serverning o'zida ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub ni ishga tushirib. Amalda, ayniqsa ichki laboratoriyada yoki yangi yaratilgan VM’da, yes ko'pincha bu qo'shimcha qadamsiz qabul qilinadi — bu faqat ishonchli, izolyatsiyalangan tarmoqda haqiqatan yangi serverga ulanayotganingizga ishonchingiz komil bo'lgandagina maqbul xavf darajasi.

known_hosts: tasdiqlangan kalitlar arxivi

yes tasdiqlangach, fingerprint ~/.ssh/known_hosts da saqlanadi:

cat ~/.ssh/known_hosts

10.20.0.15 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGx3k9F7Lp...

Keyingi har bir ulanishda klient serverdan olingan kalitni shu yozuv bilan avtomatik solishtiradi. Ular mos kelsa, hech qanday so'rov chiqmaydi — ulanish jimgina davom etadi.

Odam ishtirokisiz avtomatlashtirishda yes ni qo'lda javob berib bo'lmaydi, tekshiruvni butunlay o'chirish (StrictHostKeyChecking no) esa MITM himoyasini yo'qqa chiqaradi. O'rta yo'l:

ssh -o StrictHostKeyChecking=accept-new alice@new-server

accept-new host key’ni birinchi marta ko'rganda unga ishonadi va yozib qo'yadi (shuning uchun yangi yaratilgan VM so'rovsiz ulanadi), lekin avval yozib qo'yilgan kalit keyinchalik o'zgarsa, ulanishni baribir rad etadi — quyidagi kalit o'zgargani haqidagi ogohlantirish beradigan himoyani aynan saqlab qoladi.

Host key o'zgargandagi ogohlantirish

Agar server qayta o'rnatilgan bo'lsa, uning host key’lari almashtirilgan bo'lsa yoki — eng jiddiy holat — haqiqiy MITM hujumi davom etayotgan bo'lsa, quyidagi ogohlantirish chiqadi:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
...
Offending ED25519 key in /home/alice/.ssh/known_hosts:12
  remove with:
  ssh-keygen -f "/home/alice/.ssh/known_hosts" -R "10.20.0.15"
Host key verification failed.

Sabab tasdiqlangach (masalan, serverni ataylab qayta o'rnatish), eskirgan yozuvni olib tashlash:

ssh-keygen -f ~/.ssh/known_hosts -R "10.20.0.15"

Bu ogohlantirishning o'zi tavsiya qilgan o'sha buyruq — faylni qo'lda tahrirlashdan xavfsizroq, chunki u faqat mos keladigan yozuvni to'g'ri formatda olib tashlaydi.

Agent forwarding: qulaylik va uning xavfi

Ba’zan ichki serverga bastion host orqali ulanasiz va u yerdan o'zi ham kalit talab qiladigan boshqa amalni — yana bir serverga yoki Git repozitoriysiga ulanishni — bajarishingiz kerak bo'ladi. Agent forwarding (-A flag'i) private key’ning o'zi hech qayerga nusxalanmagan holda lokal agent’ingizni masofaviy serverga "uzatadi":

ssh -A alice@bastion-server

Amaliy vaziyat: passphrase bilan himoyalangan kalitdan sessiyada qulay foydalanish

Muammo: kun davomida bir nechta serverga ketma-ket ulanish kerak, lekin har safar passphrase’ni qayta kiritish vaqtni behuda sarflaydi.

1-qadam — joriy holatni tekshirish:

ssh-add -l

The agent has no identities.

2-qadam — kalitni agent’ga qo'shish:

ssh-add ~/.ssh/id_ed25519

3-qadam — natijani tasdiqlash:

ssh-add -l

4-qadam — bir nechta serverga ketma-ket ulanib, passphrase endi so'ralmayotganini tasdiqlash:

ssh prod-web "uptime"
ssh staging-db "uptime"

5-qadam — sessiya tugagach agent’ni tozalash (ayniqsa umumiy yoki vaqtinchalik mashinada):

ssh-add -D

6-qadam — natija: passphrase kun davomida bir marta kiritildi, keyingi har bir ulanish avtomatik autentifikatsiyadan o'tdi va sessiya oxirida kalit xotiradan tozalandi.

Keng tarqalgan xatolar

Sababini bilmasdan host key ogohlantirishini tasdiqlash

Bu SSH’da qochish kerak bo'lgan eng jiddiy xavfsizlik odatlaridan biri. Ogohlantirish chiqqanda avval sababni aniqlang, so'ng known_hosts yozuvini tozalang.

Har bir yangi sessiyada ssh-agent ni qayta ishga tushirishni unutish

Yangi terminal sessiyasini ochish ba’zan yangi, bo'sh agent muhitini ishga tushiradi va avval qo'shilgan kalitlar "yo'qolib qolgandek" ko'rinadi. Hozir nima yuklanganini har doim ssh-add -l bilan tekshiring.

Ishonchsiz serverda agent forwarding'ni yoqish

Yuqorida tushuntirilganidek, bu amalda boshqa serverga private key’ingizni hech qachon ushlab turmasdan "ishlatish" imkonini beradi. -A faqat ishonch aniq va yaxshi tushunilgan joyda ishlatilishi kerak.

Butun known_hosts faylini o'chirish

Bitta yomon yozuvni tuzatish o'rniga butun faylni o'chirish avval ishonilgan har bir server uchun qayta tekshirishga majbur qiladi — bu MITM himoyasining butun ma’nosini yo'qqa chiqaradi. Faqat muayyan muammoli yozuvni ssh-keygen -R bilan olib tashlang.

Mashqlar

1. Passphrase bilan himoyalangan sinov kalitini yarating, uni ssh-agent ga qo'shing va ssh-add -l bilan ro'yxatda turganini tasdiqlang.
2. ~/.ssh/known_hosts dan bitta yozuvni oling va uning uch qismini (host, kalit turi, kalit qiymati) tushuntiring.
3. Laboratoriya serveringizning host key fingerprint’ini serverning o'zida ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub bilan chiqaring va uni klientning ssh -v chiqishida ko'rsatilgan fingerprint bilan qo'lda solishtiring.
4. Sinov maqsadida known_hosts yozuvidagi bitta belgini ataylab o'zgartiring, ulanishga urinib, "REMOTE HOST IDENTIFICATION HAS CHANGED" ogohlantirishini kuzating, so'ng uni ssh-keygen -R bilan tuzating.

Mashqni bajardim deyish uchun: 4-mashqda ssh-keygen -R ni ishga tushirgandan keyin o'sha hostga oddiy ulanish yana muvaffaqiyatli bo'lishi va yangi host key tasdig'ini so'rashi kerak — agar u muvaffaqiyatsiz bo'lsa yoki umuman so'rov chiqmasa, ehtimol noto'g'ri yozuv olib tashlangan.

Manbalar

• man7.org: ssh-agent(1)
• man7.org: ssh-add(1)
• man7.org: ssh-keygen(1)
• man7.org: sshd(8) — SSH_KNOWN_HOSTS FILE FORMAT
• OpenSSH Wikibook — Cookbook: SSH agent forwarding