Ishonchsiz VPN-da SSH parolingizni aslida kim ko'radi?
VPN orqali parol kiritishdan oldin identifikatsiya tekshiruvlarini bajaring, so'ng server identifikatorini, foydalanuvchi autentifikatsiyasini va oxirgi nuqta ishonchini uchta qarorga ajrating.
SSH sessiyasini o'zingiz boshqarmaydigan VPN orqali o'tkazing, va parol baribir SSH serveriga tegishli, oradagi tarmoqqa emas. Agar tasdiqlangan hostga transport to'g'ri himoyalangan bo'lsa, o'sha yo'ldagi passiv kuzatuvchi parolni o'qish mumkin bo'lgan shaklda olmaydi. Lekin bitta shartni o'zgartiring, javob ham o'zgaradi: tasdiqlanmagan host, zaiflashtirilgan shifrlar ro'yxati yoki buzilgan ish stantsiyasi har xil natija beradi. Quyidagi tekshiruvlarni tartib bilan bajaring va har birini to'xtash sharti deb biling.
Biror narsa yozishdan oldin qabul qiluvchini nomlang
Parol maydoni autentifikatsiya xabari ichida sayohat qiladi, bu xabar esa shifrlangan transport ichida sayohat qiladi. Maxfiylik transport xususiyati, ya'ni u himoya kelishilganiga va u siz ko'zlagan host bilan kelishilganiga bog'liq. Odamlar aynan shu ikkinchi yarmini tashlab ketishadi. Yolg'onchiga shifrlangan aloqa bir vaqtning o'zida ham maxfiy, ham foydasiz. VPN-ga kirish SSH hosti haqida hech narsani isbotlamaydi, provayderning obro'si esa kalit tekshiruvini almashtirmaydi.
Ikki yo'nalishni xayolingizda alohida saqlang. Host kaliti qaysi serverga yetganingizni javob beradi. Parol yoki kalit autentifikatsiyasi server qaysi foydalanuvchini qabul qilishini javob beradi. Ikkinchisini yaxshilash birinchisini hech qachon tuzatmaydi.
Host identifikatorini, yozuvni va kelishuvni tekshiring
Mijozda sizda allaqachon bor yozuvdan boshlang. Ishonchli manba bilan solishtirilgan e'lon qilingan barmoq izi va hali ham mos keladigan known_hosts yozuvi autentifikatsiya boshlanishidan oldin muhim bo'lgan yagona dalilni beradi.
ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net
Server tomonida e'lon qilmoqchi bo'lgan barmoq izlarini xotiradan ko'chirish o'rniga chop eting. Ularni kanaldan tashqarida tarqatish butun masalaning mazmuni; host nomi bilan bir xil suhbat kanalidan yopishtirilgan barmoq izi ikkalasi ham bir joydan kelganini isbotlaydi.
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'
Kelishilgan algoritmlar ikki tomonning kesishmasidan keladi. Agar mijoz konfiguratsiyasi eski qurilmaga yetish uchun eskirgan kalit almashinuvini qadab qo'ysa, bu tanlov u gaplashadigan har bir hostga tegishli, shuning uchun uni global emas, o'sha host bilan cheklang.
Server haqiqatda qabul qiladigan usullarni o'qing
Server qaysi autentifikatsiya usullariga ruxsat berishini bilish parol nima uchun kerakligini aytadi. Faqat ochiq kalitlarni qabul qiladigan hostda himoya qiladigan parol almashinuvi yo'q, va hali ham parollarni qabul qiladigan host meros qolgan standart o'rniga ongli qarorga loyiq.
sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'
Foydalanuvchini kalit autentifikatsiyasiga o'tkazish o'sha foydalanuvchining parolini o'sha almashinuvdan chiqaradi. Bu buzilgan ish stantsiyasini xavfsiz qilmaydi va ishonchsiz masofaviy sessiyani zararsiz qilmaydi. Bular turli nazoratga ega turli xavflar. Agent uzatish haqida ham qaror qiling. Agentni ishonchsiz hostga uzatish o'sha hostga sessiya davom etguncha kalitlaringizdan foydalanish imkonini beradi va bu hammasi boshlangan parol savolidan kattaroq ta'sir.
Host kaliti ogohlantirishini hodisa qadami sifatida ko'rib chiqing
Mijoz host identifikatsiyasi o'zgargani haqida ogohlantirganda, to'xtang va xuddi shu tarmoq yo'lidan o'tmaydigan kanal orqali tekshiring. Barmoq izini server konsoli yoki uni qayta qurgan operator bilan solishtiring. Ogohlantirishni jim qilish uchun eski yozuvni o'chirish rad qilish kerak bo'lgan yagona amaldir. U dalilni tashlab yuboradi va ehtimoliy tutib qolishni oddiy kirishga aylantiradi.
Agar host qonuniy ravishda qayta qurilgan bo'lsa, eskirgan yozuvni faqat yangi barmoq izi tasdiqlangandan keyin olib tashlang, so'ng qayta ulanib kelishuvni yana tekshiring. O'zgarishni sana va sabab bilan yozib qo'ying, chunki keyingi odam ham xuddi shu ogohlantirishni ko'radi va u hal qilinganini bilishi kerak.
Bu qo'llanma nimani qamrab olmaydi
Trafikni kuzatayotgan VPN operatori sizning mashinangizdagi mahalliy imtiyozlarga ega dastur bilan bir xil emas. Oxirgi nuqtaning buzilishi, dushman brauzer kengaytmasi yoki klaviatura qayd etuvchisi SSH kelisha oladigan hamma narsadan pastda turadi va hech qanday tunnel buni o'zgartirmaydi. Agar ish stantsiyasi shubhali bo'lsa, boshqa chiqish orqali qayta ulanib maxfiylikni sinash o'rniga hodisa tartibiga amal qiling. Qayta ulanish tarmoq yo'li o'zgarganini isbotlaydi va oxirgi nuqta haqida hech narsani emas.
Oddiy holat bilan yakunlang: tasdiqlangan host, himoyalangan transport, ongli ravishda tanlangan autentifikatsiya usuli va keraksiz hech qanday uzatish yo'q. Aynan shu birikma sarlavhadagi savolga javob va bu bitta emas, to'rtta qaror.