Reklam
Sunucuda sadece anahtarla (key-only) SSH girişini ayarladıktan sonra, genellikle akla ilk gelen öneri iki faktörlü doğrulamadır (2FA): yani özel anahtara (private key) ek olarak telefonunuzdaki bir uygulamadan TOTP kodu istemek. Her zaman çok mantıklı bir sonraki adım olarak sunulur. Daha fazla faktör, daha fazla güvenlik demektir. Bu doğru, ancak bunun tam olarak hangi tehdide karşı bir önlem olduğunu netleştirmemiz gerekiyor. Çünkü bu ekstra uğraşın nerede değip nerede değmeyeceğini belirleyen şey tam olarak budur.
Gerçekte neye karşı korur?
Sadece anahtarla giriş yapılan bir SSH konfigürasyonunda zaten parola yoktur. Parola olmadığı için de tahmin edilme, sızdırılma veya oltalama (phishing) yoluyla çalınma riski sıfırlanmıştır. SSH 2FA'in sağladığı ek koruma, tamamen özel anahtarınızın bizzat ele geçirilmesine karşıdır: dizüstü bilgisayarınızın çalınması, şifrelenmemiş bir yedekten kopyalanması veya bilgisayarınıza sızılması gibi. Böyle bir senaryoda anahtar tek başına işe yaramaz; saldırganın telefonunuzdaki TOTP koduna da ihtiyacı olacaktır.
Dizüstü bilgisayarlar çalınabilir. Yedeklemeler yanlış yapılandırılabilir. "Zaten anahtarım şifreli bir diskte duruyor" argümanı, ancak disk gerçekten şifreliyse ve bilgisayarınız o an kilitliyse geçerlidir. Yani bu gerçek bir senaryodur. Ancak çok spesifik bir senaryodur, genel bir "SSH güvenlik" yaması değildir. Anahtar tabanlı doğrulama, genel tehdit modelini zaten fazlasıyla iyi yönetir.
Kurulumu nasıl yapılır?
Linux üzerinde SSH'a TOTP eklemenin standart yolu pam_google_authenticator kullanmaktır:
apt install libpam-google-authenticator
google-authenticator
Bu işlem size bir gizli anahtar (ve bir QR kod) ile birlikte yedek kodlar üretir. Daha sonra PAM ve SSH'a bu kodu sormasını söylemeniz gerekir:
# /etc/pam.d/sshd
auth required pam_google_authenticator.so
# /etc/ssh/sshd_config
AuthenticationMethods publickey,keyboard-interactive
KbdInteractiveAuthentication yes
Buradaki kritik satır AuthenticationMethods publickey,keyboard-interactive kısmıdır. Bu ayar, sunucunun hem anahtarı hem de TOTP kodunu aynı anda istemesini zorunlu kılar. Eğer bunu yanlış ayarlarsanız (örneğin bu satırı eklemezseniz), sunucu ikisinden birini tek başına kabul edebilir ve tüm bu çabayı çöpe atabilirsiniz. Bu ayarı yapıp SSH servisini yeniden başlattıktan sonra, asla mevcut oturumunuzu kapatmayın; önce ikinci bir terminal açıp çalışıp çalışmadığını test edin.
Her şeyi bozduğu yerler
Bu ekstra güvenlik katmanının yarattığı sürtünme iki noktada kendini gösterir. Birincisi, insan girişleri. Artık her interaktif SSH oturumunda telefonunuza ihtiyacınız var. Günde onlarca kez sunucuya girip çıkıyorsanız sinir bozucu olabilir ama idare edilebilir.
İkincisi—ve çok daha kritik olanı—otomasyonu bozar. SSH üzerinden kod dağıtan (deploy) bir CI/CD boru hattı (pipeline), bir Ansible playbook'u veya uzak bir sunucuya rsync ile yedek atan bir cron job düşünün: bunların hiçbirinin başında oturup o 6 haneli kodu girecek bir insan yoktur. AuthenticationMethods publickey,keyboard-interactive kuralını sunucu genelinde uygularsanız, tüm bu otomasyonları anında kırarsınız. Ve genelde bunu, zamanlanmış bir sonraki görev sessiz sedasız patlayana kadar fark etmezsiniz.
Doğru orta yol
2FA'i her şeye körü körüne uygulamak yerine, yalnızca insanların interaktif olarak girdiği kullanıcılara uygulayın. Otomasyonların ise 2FA zorunluluğunu aşan, izole edilmiş ve kısıtlanmış servis hesapları kullanmasını sağlayın. Zaten bu otomasyon hesapları başka yöntemlerle de kısıtlanmış olmalıdır (örneğin authorized_keys içinde forced command kullanarak veya anahtarı sadece belirli bir scripti çalıştırabilecek şekilde daraltarak).
# /etc/ssh/sshd_config
Match User deploy,admin
AuthenticationMethods publickey,keyboard-interactive
Match User ci-deploy
AuthenticationMethods publickey
Bu yöntemle, sunucuda serbestçe komut koşturabilen insan hesapları ekstra güvenlik katmanına sahip olurken, zaten bir TOTP kodu giremeyecek olan ve özel anahtarları bilgisayarlarda değil CI araçlarının gizli (secret) kasalarında duran dar kapsamlı otomasyon hesapları sorunsuzca çalışmaya devam eder.
Kararım
Eğer bir sunucuya sadece otomasyonlar bağlanıyorsa ve hiçbir insanın interaktif girişi yoksa, SSH 2FA pek bir şey katmaz. Çözmeye çalıştığı tehdit modeli (çalınmış bir anahtar) bu senaryoya uymaz.
Ancak insanların doğrudan giriş yapıp komut çalıştırdığı sunucularda—özellikle gerçek verilerin olduğu canlı ortamlarda (production)—dizüstü bilgisayarın çalınması gayet olası bir senaryodur. Giriş yaparken TOTP kodu girme zahmeti, otomasyonları bozmamak şartıyla (yani Match User ile doğru şekilde sınırlandırıldığı sürece) kesinlikle buna değer.
Reklam