ProtectHome va TOTP urug'i: VPN kirishi nima uchun muvaffaqiyatsiz bo'ladi

Autentifikator yangi olti xonali kodni ko'rsatadi, VPN uni rad etadi, va xuddi shu kodni o'z shellingizdan sinab ko'rsangiz, benuqson tasdiqlanadi. Shu farq butun hikoya. Ro'yxatdan o'tish sirini ocha olmaydigan PAM moduli noto'g'ri kodga o'xshab ko'rinadigan xatoni qaytaradi, va uy kataloglarini yashiradigan xizmat muhiti buning keng tarqalgan sababi. Har qanday ruxsatni yumshatishdan oldin uch holatdan qaysi birida ekaningizni aniqlang.

Bu uch muvaffaqiyatsizlikdan qaysi biri?

Birinchisi — modul umuman o'qiy olmaydigan sir. Ikkinchisi — o'qiy oladigan, lekin yangilay olmaydigan sir. Uchinchisi — haqiqatan noto'g'ri kod, odatda soatning siljishi yoki qayta ishlatilgan qiymat tufayli.

Ularni bitta muvaffaqiyatsiz urinish uchun xizmat jurnalini va tizim autentifikatsiya jurnalini o'qib ajrating, so'ng plagin qaysi PAM xizmatini yuklashini va o'sha xizmat qaysi modul satrini ishlatishini tasdiqlang. Umumiy autentifikatsiya xatosi xabari ularni ajratmaydi, muvaffaqiyatli qo'lda sinov ham ajratmaydi, chunki sizning shellingiz xizmat muhiti emas.

Faqat xizmat muvaffaqiyatsiz bo'lganda birlikning fayl tizimi ko'rinishi odatiy aybdor.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

A varianti: sirni uydan tashqariga ko'chirish

Xizmat /home katalogini yashirganda va siz bu himoyani saqlab qolishni afzal ko'rsangiz, sirni u ko'ra oladigan joyda saqlang. Modul secret= yo'lini va fayl operatsiyalarini bajaradigan user= hisobini qabul qiladi, bu markaziy omborga ko'plab identifikatsiyalarga xizmat qilish imkonini beradi.

Bu tartibli variant va eng ko'p ehtiyotkorlikni talab qiladi, chunki umumiy ombor bitta katalogni har bir hisobning xavfsizlik chegarasiga aylantiradi.

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

Unga ishonishdan oldin uch narsani tekshiring: hisob mavjud, modulning ish jarayoni unga o'ta oladi va fayllar cheklovchi rejimlar bilan unga tegishli. user= bilan birga ~ yoki uy o'zgaruvchisi yo'lini ishlatmang va yo'lni ishga tushirish uchun modulning egalik tekshiruvlarini o'chirmang. Parol bosqichini va stekning qolgan qismini buzilmagan holda saqlang.

B varianti: faylni qoldirib yo'l ochish

Agar sir foydalanuvchining uyida qolishi kerak bo'lsa, birlikka xostdagi barcha uylarni ochib bermasdan o'sha bitta katalogni o'z ichiga olgan ko'rinish kerak. drop-in sandbox qilingan uy ostiga tor doiradagi bind mount qo'shishi mumkin.

Bu foydalanuvchi bo'yicha egalikni model sifatida saqlaydi, lekin sandbox har o'zgarganda ko'rib chiqilishi kerak bo'lgan birlik o'zgarishi evaziga.

Ikki chegarani osonlikcha o'tkazib yuborish mumkin. Sandbox yashiradigan katalog ostiga qo'shilgan faqat o'qish yo'li uni ochib bermaydi, chunki ota-katalog u yerda yo'q. Va modul holatni yangilashi kerak bo'lsa, mount yoziladigan bo'lishi kerak, bu esa keyingi variantni o'yinga olib keladi. drop-in ni /usr/lib ostidagi paketlangan birlikni tahrirlash o'rniga alohida fayl sifatida yozing, paket yangilanishi uni jimgina bekor qilmasin.

C varianti: sandboxni saqlab, holat yozuvlarini tuzatish

Sirni o'qish autentifikatsiyaning yarmi xolos. Modul vaqt siljishi ma'lumotini, qayta ijro himoyasini yoki hisoblagichni qayta yozishi mumkin, va o'qish tekshiruvidan o'tgan fayl yozishda baribir muvaffaqiyatsiz bo'lishi mumkin.

Bu muvaffaqiyatsizlik keyingi urinishda yomon kod kabi ko'rinadi, bu urinishda emas, shuning uchun uni soat siljishi bilan aralashtirishadi.

Butun uyni yoziladigan qilish o'rniga unga o'zining yoziladigan katalogini bering va sir yo'lini o'sha yerga yo'naltiring. Katalog egasini, fayl tizimining bo'sh joyini va birlik boshqa joyda yozuvlarni cheklaydimi-yo'qmi tekshiring. So'ng ketma-ket ikkita kirishni sinab ko'ring, chunki ikkinchisi yozish yo'lini isbotlaydi, birinchisi faqat o'qishni.

O'zingiz sifatida emas, xizmat sifatida tekshiring

Har bir muhim tekshiruv birlikning sandboxida birlikning identifikatsiyasi bilan ishlashi kerak.

root sifatida muvaffaqiyatli bo'lgan buyruq fayl mavjudligini aytadi, boshqa hech narsa emas. Haqiqiy xizmat orqali kirish modul sirni o'qiy, ishlata va kerakli narsani qayta yoza olishini aytadi.

Nihoyat, talabni buzilmagan holda saqlang. Nol parol variantini qo'shish, faqat o'qish xatolarini qabul qilish yoki sandboxni olib tashlash — bularning barchasi siyosatni o'zgartirib simptomni yo'q qiladi. Kod taqdim etishga majbur foydalanuvchi sir mavjud bo'lmaganda ham rad etilishi kerak.